June 1997 - NANOG - lists.nanog.org

RE: NSP ... New Information
by Rodney Joffe 11 Jun '97

11 Jun '97

Might I suggest that a new group be set up to discuss and handle operational issues? Clearly this is no longer it... and this list has no value if we keep having to dig through the manure to find the pony. I'm getting more spam from this list than I'm bouncing from AGIS. Enough already. Please. Rodney Joffe Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: Paul Ferguson [SMTP:pferguso@cisco.com] > Sent: Wednesday, June 11, 1997 8:58 AM > To: Phil Howard > Cc: nanog(a)merit.edu > Subject: Re: NSP ... New Information > > At 10:38 AM 06/11/97 -0500, Phil Howard wrote: > > > > >One way is to divide the IP space up into value tiers and bid for it. > >I'm sure NSI would be more than willing to do this :) > > > > Oh, no. Not this thread again. Somehow I get the feeling that the > signal/noise ratio is about to taka a nosedive again. > > This issues has been hashed, and re-hashed, to death on various > mailing lists, to include NANOG. I would suggest that if this > is an issue that you wish to discuss/pursue, please take it to > the PIARA mailing list: piara-request(a)apnic.net > > - paul

1 0

Re: Route leak (was Re: more routes than normal)
by Glenn Lepore 11 Jun '97

11 Jun '97

All, Looks like things have settled down a bit. Here is GSL's view of the world: gsl-lond-2#sho ip bgp 129.211.0.0 BGP routing table entry for 129.211.0.0/16, version 1938736 Paths: (3 available, best #2, advertised over EBGP) 4200 5672 204.59.145.25 (metric 37) from 204.59.145.5 (204.59.145.25) Origin IGP, localpref 90, valid, internal Community: 262144271, 262144301, 262144501, 262146001 Originator : 204.59.145.25, Cluster list: 204.59.145.5 4200 5672 192.157.69.19 (metric 37) from 204.59.137.5 Origin IGP, localpref 90, valid, internal, best Community: 262144271, 262144301, 262144501, 262146001 4200 5672 204.59.128.25 (metric 48) from 204.59.128.5 (204.59.128.25) Origin IGP, localpref 90, valid, internal Community: 262144271, 262144301, 262144501, 262146001 Originator : 204.59.128.25, Cluster list: 204.59.128.5 Looks like the leaks were fixed from our point of view. Cheers, Glenn Lepore ------------------------------------------------------- Glenn Lepore glepore(a)hq.si.net Network Technical Engineer Global One -------------------------------------------------------

2 1

Re: Ascend GRF
by Daniel Senie 11 Jun '97

11 Jun '97

PSI used to feed our site with a Cisco 7xxx and changed to a GRF400. The OpenROUTE Networks RBX250 router we use to talk to it had no problems with either. Actual packet throughput appears to be improved since the router was swapped, which I assume was the reason for the replacement. I haven't noticed a substantial difference in the speed with which the advertisements roll in. Either upstream box pumped out the BGP advertisements when the line first comes up at about 60% of the T1. Neither box pushes harder than that. There were some problems (non-BGP) when PSI first tried to activate the GRF, but those appear to have been resolved. At 07:58 AM 6/11/97 -0500, Peter Leppik wrote: >I've been hearing conflicting stories about the Ascend GRF lately. >Cisco claims that it doesn't really work as advertised in "realistic >networks," but Ascend says this is because Cisco's routers melt down >when the GRF feeds them routing table updates, so the GRF has to be >throttled back to work in a mixed environment. > >Does anybody have any real experience here? Any information, pointers, >anecdotes, or wild rumors would help. > >Thanks, > -Peter > > Daniel Senie mailto:dts@openroute.com Sr. Staff Engineer http://www.openroute.com/ OpenROUTE Networks, Inc. (a wholly owned subsidiary of Proteon, Inc.)

1 0

Re: FW: Re: Loss of BGP peering monitoring via SNMP
by k-ueda＠mms.mt.nec.co.jp 11 Jun '97

11 Jun '97

I could not find out " .iso.org.dod.internet.mgmt.mib.15" group in MIB1(RFC1156),MIB2(RFC1213). Could you tell me RFC-No. of MIB which have this group. > >I have written a simple perl script that uses SNMP polling to check the >status of some of our BGP peerings from Cisco routers. Unfortunately, the >script is closely tied to our configuration information so it's not >appropriate to post as is. As I'm in Tampa, I don't have all my >documentation on the MIB variables I used. > >To get you started, here are the hybrid text/numeric OIDs used by the >script to poll the applicable data out of the tables: > > .iso.org.dod.internet.mgmt.mib.15.3.1.7 BGP Peer Remote Address > .iso.org.dod.internet.mgmt.mib.15.3.1.2 BGP Peer FSM State > .iso.org.dod.internet.mgmt.mib.15.3.1.15 BGP Peer FSM Transitions > >The premise of the script is to poll periodically for the state of each >peer. If the state is different than the last poll or the count of >transitions was incremented (indicating a peering went down and was >reestablished between polls) a warning message is sent to a list of >recipients. The Peer Remote Address table is used to dynamically discover >new peerings. > >Other replies have mentioned the use of BGP traps. Traps are probably the >better way to go -- we, unfortunatly, have some issues with our current >trap collection that didn't allow us to easily add the BGP processing. > >- Doug > > / Douglas A. Junkins | Network Engineering \ >/ Sr. Network Engineer | NorthWestNet \ >\ junkins(a)nwnet.net | Bellevue, Washington, USA / > \ +1-425-649-7419 | / > > >On Thu, 5 Jun 1997, Curtis Generous wrote: > >> We have been caught several times lately with some of our border routers >> loss of BGP peering going undetected for sometime. Is there a way >> to enable BGP peering loss monitoring via SNMP from a CISCO router? >> I've looked at both the public and private MIBS but haven't found anything. >> >> I am aware of the 'nocol' package but really was hoping for an SNMP based >> approach to tie into our net-mgmt packages (sunnet and hpov). >> >> TIA >> >> --curtis >> -- >> Curtis Generous generous(a)uucom.com Phone: (703) 461-1350 >> UUcom Inc., Suite 250, 4875 Eisenhower Avenue, Alexandria, VA 22304-0797 >> > > > >------- End of Forwarded Message > > ________________________________________________ NECマルチメディアサービス構築運営本部植田晃市 e-mail : k-ueda(a)mms.mt.nec.co.jp tel : 03-3798-6085 fax : 03-5440-7297

1 0

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

11 Jun '97

At 01:36 PM 6/4/97 -0400, you wrote: >Well, that was interesting. > >Thanks to everyone who has responded thus far. I've gotten a lot of >"sale" types of email, but also a lot of really good information. > >It appears as if I was right in my assumption that I needed to get my own >IP block of PI space from the InterNIC. > Isn't the biggest problem with PI space having a big enough network so Sprint and everyone else doesn't filter you? Specifically a /19 or larger (~ 8000 addresses)? Can you justify to them 32 Class C's so you can be seen everywhere? I know of another startup provider who had this problem. Its a chicken and egg scenario. They needed to sell connectivity, but couldn't reach portions of the net, specifically Sprint. Kind of kills your marketing when you can't get to the entire 'Net. How do others deal with this scenario in a startup environment, or even an established environment where you can't justify 8000 addresses yet? Eric

24 37

64/2 allocations?
by Stephen Sprunk 11 Jun '97

11 Jun '97

This message is rather dated (LA IETF), but I haven't seen anything lately on the same topic, nor do there seem to be any relevant RFCs; could anyone perhaps point me to more recent discussions and/or plans to implement the below scheme? Does anyone have projections on when 192/3 will actually be exhausted at the current allocation rate? Does anyone believe the opening of 64/2 (or more likely, a segment thereof) will cause a change in allocation policies or routing filters? Is anyone aware of any problems with current equipment in the major providers that would preclude the deployment of 64/2 CIDR blocks? Has anyone considered the possible effects of IP space being marked "atomic"; that is, not allowed to be sub-allocated to another AS (and therefore hopefully precluding route explosion). Non-atomic allocations could still be made from the 204/6 swamp to support multi-homing for ASes not worthy of a /19 (or whatever the policy is today). Stephen >To: Michael Dillon <michael(a)memra.com> > Subject: Re: Allocation of IP Addresses > From: Paul Ferguson <pferguso(a)cisco.com> > Date: Wed, 13 Mar 1996 19:15:44 -0500 > Cc: Jim Browning <jfbb(a)atmnet.net>, "'com-priv list'" <com-priv(a)psi.com>, "'NANOG > List'" <nanog(a)merit.edu>, "'NIC Registry list'" <nic-registry(a)internic.net> > Sender: owner-nanog(a)merit.edu [snip] >Well, I knew this topic would come up sooner or later, since it was >discussed briefly in LA/IETF at the CIDRD WG meeting(s). > >A snippet from the LA/IETF CIDRD minutes: > >[snip] > >Yakov >Class A Allocation Guidelines >============================= >Motivation >Observation 1: 192/3 is 1/8 of the total IPv4 unicast space >Observation 2: 64/2 is 1/4 of total IPv4 unicast addrses space >Hypothesis1: at some point we will exhaust 192/3 >Hypothesis2: at some point we will need to allocate out of 64/2 >Observation3: It appears safe to allocate out of 64/2 based >on experience documented in RFC???? on Class A Experiment > >Recommendation >allocation of /17 or larger should be done out of 64/2 >allocation of /18 or smaller should be done out of 192/3 > >Comments? >Randy: Do you mean start this now? >YR: No, only when we decide it necessary. > >Eliot Lear: Can big ISPs get bigger blocks? >YR: Yes, it should allow them to. >EL: Do we need to advise Registries? >EL: Should 192/3 be declared unroutable? >YR: Perhaps part of it. >BManning: I would like to attach a rider on this. >I think before anyone gets anything out of 64/2 that they >should agree to give back their old blocks. >TonyLi: Is there some reason not to start alloc 64/2 immediately? >YR: We don't have to yet, so perhaps we should not. >TonyLi: Pressure from international carriers to get large blocks. >ELear: We should wait as long as possible to age legacy systems. >Tony: There weren't any big problems in the RFC. >BManning: Some things were not tested. Only routing protocols were tested. >We couldn't figure out a reliable way to test interior routing. >We should hold off a little longer before we jump into this. >NoelChiappa: We can't get rid of all the legacy systems. Is the >cost of hurting the legacy equipment less than the benefit of 64/2. > >[general discussion of when we should implement this. Now or >wait a little longer for legacy systems to expire.] >[discussion of route-able v unroute-able prefixes. Will certain >prefix ranges be declared unroute-able in future?] >MKosters: @home has a /14 out of net 24, so we have already >allocated out of Class A. > >BrianC: Suppose IANA decides to do this, and some joe-ISP >asks for a /14. We haven't given the Registries any guidance >on how to allocate. >RConrad: Policy most likely to remain the "power of 2" increase. >The size of the ISP is irrelevant with this scheme. >Cathy of @home complained that Sean won't take 24/14 only 24/8. >Sean Doran raised the issue of charging for prefixes. > >Tony advised we leave this for further discussion on the mailing list. > >[snip]

3 2

Re: NSP ... New Information
by Eric Kozowski 11 Jun '97

11 Jun '97

>Suppose that IP space were not a problem. When IPv6 comes up all around, >it certainly won't be then. You can have and waste all the IP space you >could imagine, since we'll be numbering every atom in the known universe. > >And suppose we have ASNs a plenty. > >Would Sprint, Digex, and AGIS still be trying to cut out so many routes? It has nothing to do with available IP address space. It is purely the number of routes in the "global" BGP routing table. Doing rout filtering a la Sprint is one way to enforce better aggregation and cut down on route table size. Also, in general, the longer the prefix, the more a route tends to flap. Route filtering is one way to help cust down on the number of BGP updates. > >Are any other ISPs doing this filtering? Yes. -- Eric Kozowski VP Internet Services eric(a)structured.net Structured Network Systems, Inc. (800)390-5945 Support A Verio Affiliate (800)881-0962 Sales/Info http://www.structured.net/ PGP Key fingerprint = 0A E4 91 B8 BD CB 3E 95 42 12 04 4E 14 DF 86 76 'They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.' -- Benjamin Franklin 1759

2 1

unreachable
by Bill Becker 11 Jun '97

11 Jun '97

Can't seem to reach any of cyberpromo's nameservers. Anybody know why? Bill

5 5

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