- NANOG - lists.nanog.org

RE: multihoming without BGP
by Rodney Joffe 11 Jun '97

11 Jun '97

> -----Original Message----- > From: Paul A Vixie [SMTP:paul@vix.com] > Sent: Wednesday, June 11, 1997 11:35 AM > To: nanog(a)merit.edu > Subject: Re: multihoming without BGP > > <snip> > > The way I think of this is that BGP describes reachability, and > clients need > to know about topology in order to select the right web server, and > these two > (reachability and topology) are necessarily unrelated to each other. > > I think that there is another important element or metric that is not > served by either - packet loss across the path. You know a server is > reachable - BGP tells you. If you know the topology, you know it is > "close". But looking at a typical day at MAE East, for example, when > you take into account the packets that end up being dropped, it may > *not* be the 'best' path. > > > Rodney Joffe > Chief Technology Officer > Genuity Inc., a Bechtel company > http://www.genuity.net >

1 0

Which RFC?
by Cameo Wood 11 Jun '97

11 Jun '97

Anyone remember the RFC# that details the suggested email user names for specific operations? i.e. dns-admin for DNS, abuse for Abuse, postmaster for mail problems, noc for technical problems and requests, and peering for peering request/problems etc. If anyone remembers what is is, could you please email it to me? (I do not wish to furthur muddle up the list.) Thanks in advance! Cameo

1 0

Ascend GRF
by Peter Leppik 11 Jun '97

11 Jun '97

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

3 2

Re: more routes than normal
by Alex Rubenstein 11 Jun '97

11 Jun '97

Definately: 48312 network entries (92279/171242 paths) using 10756148 bytes of memory But I don't see the strange routes you are; what networks? At 10:21 AM 6/11/97 +0100, Andrew Bangs wrote: >Sorry for waking you all before breakfast, but is anyone else seeing >~5000 more routes than normal this morning ? > >Just a sample of some unusually long ASPaths I'm seeing here > > >Jun 11 10:03:41 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 1323 1323 1323 > 1323 1323 1323 1673 1239 1792 2907 2498 > >Jun 11 10:03:41 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 5646 1793 1239 > 3561 4574 > >Jun 11 10:05:45 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 1323 1323 1323 > 1323 1323 1323 1673 3561 577 549 > >Jun 11 09:57:59 BGP RECV flags 0x40 code ASPath(2): 174 2041 3789 1323 1323 1323 > 1323 1323 1323 1673 5378 5459 > >(and it isn't just PSI we're seeing these from, just that that was the >log I looked in. 2041 3789 seems a common factor though. ) > > >GateD-beech.router.demon.net> show ip routes >100 IP radix tree: 97679 nodes, 50773 routes >GateD-beech.router.demon.net> > >This is looking horribly familiar. > > > Regards, > Andrew >-- >Andrew Bangs, Senior Systems Administrator, Demon Internet Ltd >andrewb(a)demon.net http://www.demon.net/ http://www.demon.nl/ >

2 1

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