- Test - lists.nanog.org

Livingston & BGP & multicast USENET (was blah blah blah)
by smd＠clock.org 11 Jun '97

11 Jun '97

bmanning(a)ISI.EDU writes: > Livingston has serious problems with its BGP code and > has since it was first available (going on six > months now) I don't suppose you'd care to elucidate? I'd be curious about how many updates/second this box can handle while forwarding across all interfaces at line rate, and how quickly from the receipt of an update switching to another path the forwarding engine begins sending traffic along that path, and how many christmas-tree packets flowing at line rates to a series of changing destinations are lost or mis-forwarded. Of course I tend to be interested in environments where traffic is already enormously aggregated, where all or nearly all the available bandwidth is being used, where dozens of BGP updates/second is commonplace, and where occasionally there will be "flutter" that causes large numbers of prefixes to attract data down oscillating paths. These are difficult conditions for any router, and unfortunately nobody seems to have a public benchmark which tests for them, other than the "it works/it doesn't" in the middle of large pieces of the Internet. I would be interested in actual "it works/it doesn't" commentary (and possible explanation of "it doesn't", if that's the case) involving this particular router from some sizeable ISP or other. Learning from vendor mistakes is of use to many of us. > > Will IP multicast help with the usenet stuff? > > Tangental question. Kurt Lidl and company's excellent MUSE paper, presented at USENIX in Winter 1994 details early attempts to distribute news via the MBONE. Unfortunately the MBONE is not IP multicast in any serviceable or saleable sense, and that and the work involved in making it difficult to forge multicast USENET news tends to make the distribution of news slower and less reliable than the parallel interactive unicast scheme. On the other hand, as there has been a great deal of work on eliminating multiple MBONE tunnels across providers, this both could be less true and less important for people who are concerned about the number of copies of articles moving across their networks. On yet another hand, it might make sense for "proper" multicast facilities to be deployed as supportable products before jumping into doing MUSE or something like it in a serious way. On yet another hand, satellite dissemination of news, both with pagesat-style distribution and sniffing at satellite point-to-point transmissions using amusing tcpdump scripts or programs directly using the berkeley packet filter, have been happening for some time. On the final hand, NNTP distribution is much less broken than Web distribution, and the latter distribution problem probably deserves to be attacked first. Oh yah, out of curiosity, what native multicast support is in the Livingston box, and what does it use for routing? PIM? DVMRP? CBT? Sean.

2 1

Multicast USENET News paper citation
by rja＠corp.home.net 10 Jun '97

10 Jun '97

(My apologies for following up on myself.) Someone suggested in private email that I should provide a full reference for the prior art on USENET/IP-Multicast back to the NANOG list. Here it is. However, this thread probably should migrate to some other (more appropriate) place like the mboned list and off of NANOG... Ran rja(a)home.net ---------------------------------------------------------------------- Author: Kurt J. Lidl Author: Josh Osborne Author: Joe Malcolm Title: Drinking from the Firehose: Multicast USENET News Pages: 33-45 Publisher: USENIX Proceedings: USENIX Conference Proceedings Date: Winter 1994 Location: San Francisco, CA Institution: UUNET Technologies, Inc. Abstract: News transport and spooling systems of the last several years have concentrated on decreasing the resource load on news servers. One beneficial side effect has been the average decrease in time that a news system spends on a given article. This paper describes a novel USENET news transport protocol, which we call Muse. The two major motivations behind Muse are to reduce the average propagation delays of articles on USENET and to further reduce the resource load on a centralized news server. Muse runs on top of the experimental Internet multicast backbone, commonly referred to as the Mbone. Major design and implementation issues are discussed. Security concerns of multicast news are discussed and our solution is examined. The problems of scaling news distribution to thousands of hosts are also addressed. ----------------------------------------------------------------------

1 0

Re: multicast USENET
by rja＠corp.home.net 10 Jun '97

10 Jun '97

On Jun 10 12:21, Aleph One wrote: % If anyone is really interested in writing a good reliable multicast % new protocol I suggest you read this internet draft: % % Title : The Multicast Dissemination Protocol (MDP) Framework % Author(s) : J. Macker, W. Dang % Filename : draft-macker-mdp-framework-02.txt % Pages : 14 % Date : 06/06/1997 Joe Macker happens to have freely distributable source code. Folks interested in MDP and IMM (not INN) might want to goto this URL: http://tonnant.itd.nrl.navy.mil/ipresearch/rm.html Folks seriously working on reliable multicast protocol design should look into the IRTF Reliable Multicast Research Group... All IMHO, Ran rja(a)home.net

1 0

Re: NSP ... New Information
by Eric Germann 10 Jun '97

10 Jun '97

The really annoying part of the whole "/19 or you are screwed" policy with respect to routability is the hoops the little guy has to go through to get address space. As has been quoted here earlier in this thread, Internic claims you need 100% utilization off the bat. However, none of the big guys seem to play by the rules for rational allocations. I have a client connected to MCI. They have five divisions on one campus. They have been allocated 5 class C's by MCI. They need exactly four addresses, one for the mailgate, one for the proxy, one for the Web server and one for the the router for each division. So their utilization is 4/256 or 1.5625%. Responsible allocation? I have a colleague who wanted dial on demand LAN routing. PSI offers it. He has a 2 node + router LAN. One for the router and one for each PC. Guess what he gets? A Class C. 3/256 or 1.17% utilization. Their reasoning, and I quote: "Its just easier for us to set up that way." Why doesn't Internic go back and pick on the big guys and start yanking their addresses. <underline>I'm all for conservation, universally applied.</underline> Ironic that the big guys waste the space and then filter the routes of the little guys who give their first three children to Internic to get PIA, isn't it. At 11:19 AM 6/10/97 -0400, Paul Ferguson wrote: >At 09:22 AM 06/10/97 -0500, Phil Howard wrote: > >> >>Right. But people see it as such a problem because the routing policies >>are IP space derived. When people are told they need a /19 to be routable, >>then they begin to go backwards on solving the IP space problem and resume >>wasting it (but hiding the waste to look like its used). >> > >But this is somewhat of a misnomer. It is not an issue of being >'routable' v. 'non-routable', but rather, one of whether you can >be aggregated into a larger prefix. This practice encourages >aggregation -- it is commonly agreed that Aggregation is Good (tm). > >The routability issue comes into play when: > > o You are specifically referring to routes being propagated by > a service provider who uses prefix-length filters, AND > > o You cannot be aggregated into a large enough advertised CIDR > block to conform to these types of filters. > > >>When the need to justify space usage occurred, along with it came some ideas >>on actually how to do that. And I see that working. We were projected to >>run totally out of space by now, and since we have not, I assume it did work >>pretty well. >> > >BGP4, CIDR, or Die. > >>But the real problem is routing policies that are encouraging people to go >>back to wasting space. By using the network size as the criteria for doing >>route filtering, the smaller guys get screwed and they see their solution >>as inflating their network. This practice needs to be stopped or a better >>solution needs to come out of it. >> > >One might suggest that some of the prefix length filter could be >replaced by more aggressive dampening policies. > >- paul > > >

1 0

Re: Livingston & BGP & multicast USENET (was blah blah blah)
by Eric Germann 10 Jun '97

10 Jun '97

At 11:21 PM 6/9/97 -0400, Sean M. Doran wrote: [snip] >> > Will IP multicast help with the usenet stuff? >> >> Tangental question. > >Kurt Lidl and company's excellent MUSE paper, presented at >USENIX in Winter 1994 details early attempts to distribute >news via the MBONE. > > [snip] >On the final hand, NNTP distribution is much less broken >than Web distribution, and the latter distribution problem >probably deserves to be attacked first. > Just released yesterday: A Protocol for the Transmission of Net News Articles over IP multicast. ftp://ds.internic.net/internet-drafts/draft-rfced-exp-rupp-01.txt Eric

2 1

Re: NSP ... New Information
by Larry Vaden 10 Jun '97

10 Jun '97

At 07:10 AM 6/9/97 -0700, Bill Manning wrote: >> >> At 09:47 PM 6/8/97 PDT, Randy Bush wrote: >> >Folk are trying to keep core routers >> >from falling over. >> >> To repeat an earlier unanswered question, what and whose legacy hardware >> and software is causing the problem? > >proteon, ibm, cisco, bay, 3com to name a few, >and, to my limited understanding, every implementation >of an IP stack. Of course if you are willing to slow down >everything and commit to a global network that runs at >no greater than 64Kb. (and get everyone else to do the same) >then you might be able to get by with the next generation of >hardware. > >--bill One of the newbies (Livingston) has BGP in alpha using < 8MB for a full view and a 486 processor without stress. While this won't make a core router, it seems to offer something to consider, even learn from. One of my projects 25 years ago was to reduce the time to calculate the square root on a Seymour Cray machine by a factor of 20 to avoid spending $8 million on a second machine. The revised square root code performed in about the same time scale as the machine's hardware divide function. The clue came from one of the national laboratories and was published in Nuclear Science Abstracts. It took about 6 weeks to do the code and 18 months for the solution to be politically accepted. The original vendor does not always produce sacrosanct stuff. We just went through the process of acquiring our first significant router; one of our main concerns was a router which would allow school districts, libraries and hospitals to benefit from Texas HB2128, which offers distance insensitive T1s and DS3s and was co-authored by our telecomm lobbyist, W. Scott McCollough in Austin. I was somewhat dismayed at the memory limitations of current stuff compared to what I was hearing about the memory requirements. Jonah has more memory on his texas.net usenet news server than you can put on many core routers. Is there anyone working on alternative implementations of software which could possibly solve some of the problems using extant hardware? Will IP multicast help with the usenet stuff? Do we want to continue seeing cams at universities display the local tower while the institution doesn't meet RFC2050 guidelines with respect to utilization of their Class B while the rural areas can't get /19s to support diversity and redundancy? Does Congress need to pass "must carry" legislation similar to the "any willing provider" medical legislation? IMHO, it would be better that some old dogmas and implementations die and be replaced with efficient, robust code and a rather less limiting view of the future. Larry Vaden, founder and CEO help-desk 903-813-4500 Internet Texoma, Inc. <http://www.texoma.net> direct 903-870-0365 bringing the real Internet to rural Texomaland fax 903-868-8551 Member ISP/C, TISPA and USIPA pager 903-867-6571

13 20

So, Network Solutions is a spam site!
by Curt Howland 10 Jun '97

10 Jun '97

Good morning, fellow ops. I guess maybe I shouldn't be so suprised that Network Solutions is a spam site. I wonder when they'll be added to the Vixie filter list? Curt- ----- Begin Included Message ----- >From rereg(a)ops.internic.net Mon Jun 9 20:28:26 1997 Return-Path: <rereg(a)ops.internic.net> Date: Mon, 9 Jun 1997 23:27:56 -0400 (EDT) To: sean_kendall(a)spectrian.com, postmaster(a)conxion.net Reply-To: hostmaster(a)internic.net >From: rereg(a)internic.net Subject: [NIC-970609.13246] Modify Registration ... Precedence: Bulk X-MTS-Ticket: 970609.13246 X-MTS-LoopDetect: InterNIC_Registration_Services Content-Length: 21994 ---- Domain Name Registration Renewal Notice ---- Your Anniversary Date is: 07-Aug ... #################################################################### SPECIAL Network Solutions, Inc. Announcement ACTIVATE YOUR WEB SERVER'S SECURITY FEATURE WITH A DIGITAL ID FROM VERISIGN A Digital ID (SM) from VeriSign will enable your site to provide secure (SSL) commerce solutions for customer communications. Enroll before July 31, 1997 and you will also recieve a personal $30 gift certificate to be used at the popular Virtual Vineyards web site! You will be able to use the certificate to purchase a variety of items ranging from special coffees, cheeses and beverages! INTERESTED? Visit https://srs.internic.net for more information. WANT A TEST DRIVE? Try the VeriSign Free Evaluation Digital ID at the same web site. #################################################################### ... ----- End Included Message -----

1 0

re: NSP...New Information
by Allan Chong 10 Jun '97

10 Jun '97

Joel Gallun wrote: > > You can dismiss this problem by saying the apps are broken (which they > are), but the simple fact is our customers want to use these apps. > > I'd recommend DHCP. In communities where we've used it, it has worked > fine and not caused any of the problems that NAT does. > You could assign static addresses for the customers that request it. You'd retain most of the benefits of NAT. NAT is really well worth it in _some_ cases. We cut a 30 site WAN/LAN from one internet provider to another in 5 minutes. One of my clients had another problem with NAT. Seems that Cisco's NAT implementation translates DNS addresses in the payload when it is a plain query, and doesn't when it is a zone transfer. Meant that we couldn't have secondaries on the outside of the NAT. Also, their NAT implementation was absent for the 3600 in 11.2.4 and 11.2.5 (despite all documentation to the contrary). In typical cisco fashion, they lent us a 4700, so I'm not in any hurry to get it fixed. -- Allan Chong allan(a)alum.mit.edu "When I die, I want to go peacefully like my Grandfather did---in his sleep. Not yelling and screaming --like the passengers in his car."

1 0

router monitor/configuration tool (fwd)
by Dave Scrivens 10 Jun '97

10 Jun '97

I was interested if anyone has actually seen or heard anything about this ? There seems to be enough interest about such products... & it seems to be pretty hot stuff if MCI chose it to do QOS & monitoring of there ATM Links & other Network components..... Any replys ? thanks, Dave Scrivens iSTAR Internet email: dave.scrivens(a)istar.ca > > > > I was wondering about this myself, has anyone seen the Linmor NMS system. > > This system has been chosen by MCI after extensive evaluation of existing > Network Management Systems to manage there ATM Hyperstream Network. > > This Network Management Provides several other interesting functions such > as Object Oriented Class for an object. It also has a Web Page which can > list all objects & the traffic statistics for each link. > > As well it can do the below. From it a QOS of service report can be generated > indicating the health of of your Network. Reports on the Uptine of your BGP > routing process as well as OSPF & EIGRP can be generated. > > It also has the ability to Monitor Unix machines & " Mission " critical processes > such as NAMED or mail & News processes. You can actually get an indication > that the memory on the Unix box is low & that is the problem. > > & Unlike HP Openview, Autodiscovery works very nicely on a large Network. > > Instead of crashing your Network, you get a pretty nice map infront of you. > > It is also a distributed system architecture where you can have multiple > Data Collectors spread out through your Network talking to each other, > exchaning information about the Health of the Network. & you can function > in Hot Standby mode where if one of your Data Collectors goes down, another > will take up the load. > > I have seen a SPARC IPC manage over 1500 Network Router Objects including > including Cisco 7000's & Cisco 7513's. So even though this is alot for a > little SPARC Server, it worked pretty good. It is not highly recommeneded > to run your Network like this but as a test .... > > You can also run reports on your Network & figure out where your facilities > such as the Memory on Core & Border Routers need to be upgraded or where > you are running out of bandwidth & need to add more. > > As well, remote site customer management where the customer can be given an > account to actually monitor his connection with his provider, from his > provider, works good. A check for the customer to ensure that he is getting > good service from his provider. > > & since you can get remote site access, you can actually get a Network Management > Station from another site. > > > This is a Really neat product, atleast from what I have seen. Has anyone else > encountered it ? > > Anyway check it out ..... WWW.LINMOR.COM > > They have some really neat stuff.. > > thanks, > > Dave Scrivens, > iSTAR Internet. > > > > > based on a recent email about bgp peer monitoring and others over the > > last few months, we thought this would be a good time to release a tool > > called rtrmon (router monitor) that we've been working on with vixie > > enterprises. > > > > please see: www.vix.com/rtrmon > > > > vixie enterprises provided the development expertise and based the design > > on the needs of genuity initially. it's fairly generic and extensible. > > currently it: > > > > - monitors bgp sessions and reports failures > > - monitors cpu usage and reports failures > > - monitors ospf neighbors > > - downloads, diffs, and archives cisco configs > > > > it's all cisco oriented as that's our primary platform. we'll start a > > mailing list soon for discussion (next week) but in the short interrim > > please send mail to myself or danny mcpherson (danny(a)genuity.net) for > > questions or problems. we'll have this hosted on our own web site(s) > > sometime next week as well. enjoy. > > > > -brett > > > >

1 0

Re: Top 100 Nameservers (Serving the most Domains)
by Paul A Vixie 10 Jun '97

10 Jun '97

> I've always been curious how well bind runs with 10,000+ domains in it. > That's one big named.boot file. > > Rusty Hodge <rusty(a)hodge.com>, San Francisco Piece 'o cake. For BIND 8.1 that is. BIND 4.9 will start up in about twice the time, but then every 15 minutes it will appear to freeze solid while it stat()'s all those files. BIND 8.1 does it all incrementally. BIND 8.2 will have a clustered memory allocator which will make it start up in about 1/5th the time it takes now. But this is some months from now.

1 0