- Test - lists.nanog.org

Re: Ascend GRF
by Alex Rubenstein 11 Jun '97

11 Jun '97

>From what I have seen (disclaimer: I have not used either) and heard (same disclaimer), the case is the the GRF is turly a piece. 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 >

1 0

Automotive Nextwork Certification Doc?
by mcquaidj＠netscout.com 11 Jun '97

11 Jun '97

From: Jim McQuaid@FRONTIER on 06/11/97 12:42 PM To: nanog(a)merit.edu cc: Subject: Automotive Nextwork Certification Doc? At the Tampa NANOG someone commented that the ANX document calling out the network metric specifications was now available (for purchase) from them. I don't see this on their standard catalog / web site. Any clues about who/where/how to get this document? Thanks, Jim McQuaid NetScout Systems, formerly Frontier Software (508) 244-4001 x 1456 mcquaidj(a)netscout.com / www.netscout.com mcquaidj(a)frontier.com / www.frontier.com still works!

1 0

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