June 1997 - NANOG - lists.nanog.org

re: Wavelan & Linux @ NANOG
by Rob Gutierrez 05 Jun '97

05 Jun '97

> I have a Linux laptop & want to use one of the WaveLAN (Digital) > wireless units. > > If someone has this working, I'd like to hear from you. I have a laptop w/Linux 2.0.30. Hope you have the sources on your laptop. This is supported in 2.0.x. Can't help you for anything before that. Nope, the generic kernels don't have Wavelan support built in :( Just in case anybody else is at NANOG and wants to use the Wavelans: cd to /usr/src/linux. vi .config. Search for CONFIG_NET_RADIO. Define it (ie: delete the "#" and say "CONFIG_NET_RADIO=y"). Next line, add "CONFIG_WAVELAN=y". Make the new kernel ("make depend ; make clean ; make zImage"). If you've installed Linux on a laptop, then you're not clueless and you know where to go from here (lilo, etc). You'll need to remake/reinstall pcmcia (hope you have those sources also) since the symbols won't match. You can force pcmcia to run anyway w/o rebuilding, but it might not be pretty... Don't forget to edit /etc/pcmcia/network.opts with the address you've been given. I'd give you my kernel+pcmcia, but I left my laptop at home today. > Thanks, No prob. rob.

1 0

Re: BGP Routing problem
by Bil Herd 05 Jun '97

05 Jun '97

We have seen upon occasion where a dampened route will not be replaced by a route of the same specificity for about 20-45 minutes. While we didn't care for this behaviour, I guess it was somewhat predictable. What had us concerned was we have seen each of our three providers black hole us on at least one occasion (sometimes more) when their backbone or core flapped. It could be described as appearing as if their borders did not receive the information to withdraw our advertisements. Looking Glass showed us "history" and "received only" entries, but no active replacements... similar to the symptoms that you are describing. Sprint's NOC reported hearing active advertisements from our "down" providerm but I heard this second-hand. Killing our BGP session with the offending provider after the problem started would not fix the problem, our routes continued to be preferred to someone we no longer had a bgp session with. This situation would usually fix itself within 45 minutes. While this doesn't happen often, it has the affect that having two other providers is useless if the third is erronously advertising us. Is there a failure scenerio where borders will continue to advertise AS's due to loss of connectivity with their interior routers? Bil Herd InterActive On Thu, 5 Jun 1997, Anthony Walker wrote: > We are currently multi-homed during the day and tripple homed at > night. > Basicaly we (AS6180) have been announcing all our adresses including > 196.25.116.0, 196.25.117.0 and 196.25.203.0 via AS 3741 at night, > and this gets switched of during the day. The problem seems to relate > to the fact that these addresses are part of AS 5713's CIDR > 196.25.0.0/16 and we thought we could get away with announcing them > like this. It did work fine for over a week, but now today we have a > problem. > > MAE-East (see example at end of message) , the Sprintnap and who > knows who else still have entries for these via AS3741 but they are > showing as received-only, and no best path. Yet via MAE West they are > fine. > > We are going to stop announcing these via AS3741 at night, but its > been 9 hours now since they were not announced and these > received-only entries are still sitting there blocking these routes > from it seems about a third of the internet. > MAE-East Looking Glass Results > Query: bgp > Addr: 196.25.203.0 > BGP routing table entry for 196.25.203.0/24, version 5006458 > Paths: (1 available, no best path, advertised over IBGP) > 1673 1239 4005 3741 6180, (received-only) > 192.41.177.141 from 192.41.177.141 (140.223.57.217) > Origin IGP, external >

1 0

Re: the original thirteen NSFNET regionals
by Curt Howland 05 Jun '97

05 Jun '97

He's over at @Home, selling IP to the masses. I was wondering when someone was going to bring up NSI, since when I started there in 1992 it was called a "regional". I never could figure out how a network reaching not only accross the US, but to Greenland, Alaska, Antarctica, Australia, New Zeland, Great Brittain, etc, could be called "regional". Of course, that was before the PPP link to the Space Shuttle. Oh, and that South Pole thing... :^> Those were great times. Never knew what the next project was going to be. "Get reliable service to Moscow." Gee, I thought the South Pole was hard... Curt- > Rob Gutierrez wrote: > > Does NSI (NASA Science Internet) qualify as one of those? Yeah, it was > > 1989 when it started (Hi Milo!), but ... :) > > Where is Milo Medin nowadays.. ? > > -- > miguel a.l. paraz <map(a)iphil.net> +63-2-893-0850 > iphil communications, makati city, philippines <http://www.iphil.net>

1 0

Packet Loss on MBone from NANOG/Tampa
by Eric Kozowski 05 Jun '97

05 Jun '97

I'm seing high packet loss on the MBone for the NANOG session. Anybody know when/if this will be fixed? It appears that the bulk of the packet loss is at paloalto-mbone1.bbnplanet.net with quie a bit more at maew-mbone.nsn.nasa.gov. Mtrace from 198.133.26.253 to 206.58.161.69 via group 224.2.176.59 Querying full reverse path... * switching to hop-by-hop: 0 teufel (206.58.161.69) -1 artful (206.58.161.11) DVMRP thresh^ 1 -2 eugene-isp.nero.net (207.98.64.6) DVMRP thresh^ 64 -3 * dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 64 -4 paloalto-mbone1.bbnplanet.net (192.42.110.249) Unknown protocol code 5 thresh^ 32 -5 sanjose1-mbone1.bbnplanet.net (4.0.0.34) Unknown protocol code 5 thresh^ 32 -6 maew-mbone.nsn.nasa.gov (198.32.136.99) DVMRP thresh^ 64 -7 mae-west-mbone.ibm.net (198.32.136.110) DVMRP thresh^ 0 -8 ? (165.87.35.56) DVMRP thresh^ 0 -9 ? (198.133.26.254) PIM thresh^ 0 -10 ? (198.133.26.253) Round trip time 323 ms Waiting to accumulate statistics... Results after 10 seconds: Source Response Dest Packet Statistics For Only For Traffic 198.133.26.253 206.58.161.69 All Multicast Traffic From 198.133.26.253 v __/ rtt 2836 ms Lost/Sent = Pct Rate To 224.2.176.59 198.133.26.254 ? v ^ ttl 0 -2/520 = 0% 40 pps -1/335 = 0% 25 pps 165.87.35.56 ? v ^ ttl 1 2/522 = 0% 40 pps 1/336 = 0% 25 pps 198.32.136.110 mae-west-mbone.ibm.net v ^ ttl 2 27/520 = 5% 40 pps 18/335 = 5% 25 pps 198.32.136.99 maew-mbone.nsn.nasa.gov v ^ ttl 64 224/1143 = 20% 87 pps 35/317 = 11% 24 pps 4.0.0.34 sanjose1-mbone1.bbnplanet.net v ^ ttl 65 0/876 = 0% 67 pps 0/282 = 0% 21 pps 131.119.0.197 192.42.110.249 paloalto-mbone1.bbnplanet.net v ^ ttl 66 524/933 = 56% 71 pps 58/282 = 21% 21 pps 204.70.158.61 dec3800-2-fddi-0.SanFrancisco.mci.net v ^ ttl 67 10/2252 = 0% 0 pps 2/224 = 1% 0 pps 166.48.14.6 207.98.64.6 eugene-isp.nero.net v ^ ttl 68 31/555 = 6% 55 pps 3/222 = 1% 22 pps 206.58.161.11 artful v \__ ttl 69 494 49 pps 219 21 pps 206.58.161.69 206.58.161.69 Receiver Query Source -- 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

1 0

Re: satellite connections
by Brett D. Watson 05 Jun '97

05 Jun '97

> Hi, > > Stephen Sprunk wrote: > > > I'm not sure how many TCP/IP stacks still set those bits; it may be > > necessary to have a router manipulate the bits after examining the port > > numbers of a connection. > > Looks like a good place to use access lists that choose packets based on > tcp, udp, and port number. If I could get a 45 Mbps circuit over high-latency > geosatellite, one-way, I could use it for http and "push" traffic. > The requests, outbound stuff, and interactive traffic would fit into a T1 > under the ocean. if you're interested in that, cisco's new CoS stuff uses precedence (extended access lists, mac address, ports numbers) to do just such a thing. it would be most useful if isp's could have concensus on the precedence "classes" to work across the multiprovider internet (may not be practical though). -brett

1 0

Re: BGP Routing problem
by Danny McPherson 05 Jun '97

05 Jun '97

i believe (received-only) means that bgp soft-reconfiguration is configured for the peer and since some policy is denying the route, it won't be used .. unless a policy change occurs. here's what we're currently hearing from you folks... peer1.sjc1#sh ip bgp re 6180 BGP table version is 2830358, local router ID is 207.240.24.10 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i196.6.121.0 192.41.177.248 10 80 0 701 5713 6180 i * i 198.32.176.2 10 80 0 701 5713 6180 i *> 198.32.184.42 10 80 0 701 5713 6180 i * i196.28.5.0 192.41.177.248 10 80 0 701 5713 6180 i * i 198.32.176.2 10 80 0 701 5713 6180 i *> 198.32.184.42 10 80 0 701 5713 6180 i h 206.49.228.0 198.32.184.42 10 80 0 701 5713 6180 i * i 192.41.177.243 10 80 0 4000 6187 6180 i * i 192.157.69.80 10 80 0 4000 6187 6180 i *> 198.32.136.94 10 80 0 4000 6187 6180 i * i206.49.229.0 192.41.177.243 10 80 0 4000 6187 6180 i * i 192.157.69.80 10 80 0 4000 6187 6180 i *> 198.32.136.94 10 80 0 4000 6187 6180 i and it appears as though routing via alternet is working for the networks you mentioned. -danny > Hi > > We are a ISP in South Africa and have a problem we are trying to > figure out rather urgently, without much success so far. > > We are currently multi-homed during the day and tripple homed at > night. (our peaks are at night and we get cheap bandwidth from > another ISP who has their peak in the day). Internic has refused to > give us our own block of addresses which would have made thins much > simpler. (despite repeated attempts, and we now have 7 /24's from > various places and badly need more). > > Basicaly we (AS6180) have been announcing all our adresses including > 196.25.116.0, 196.25.117.0 and 196.25.203.0 via AS 3741 at night, > and this gets switched of during the day. The problem seems to relate > to the fact that these addresses are part of AS 5713's CIDR > 196.25.0.0/16 and we thought we could get away with announcing them > like this. It did work fine for over a week, but now today we have a > problem. > > MAE-East (see example at end of message) , the Sprintnap and who > knows who else still have entries for these via AS3741 but they are > showing as received-only, and no best path. Yet via MAE West they are > fine. > > We are going to stop announcing these via AS3741 at night, but its > been 9 hours now since they were not announced and these > received-only entries are still sitting there blocking these routes > from it seems about a third of the internet. > > Can any one offer any comments on why they are still there, what > received-only means and how we can get if fixed? > > Many thanks > Regards > Anthony Walker > > > MAE-East Looking Glass Results > Query: bgp > Addr: 196.25.203.0 > BGP routing table entry for 196.25.203.0/24, version 5006458 > Paths: (1 available, no best path, advertised over IBGP) > 1673 1239 4005 3741 6180, (received-only) > 192.41.177.141 from 192.41.177.141 (140.223.57.217) > Origin IGP, external

1 0

RE: Loss of BGP peering monitoring via SNMP
by Chad Skidmore 05 Jun '97

05 Jun '97

Cisco routers will send a trap on BGP peering changes. The following is an example config: snmp-server community private RW 1 snmp-server community public RO 2 snmp-server trap-authentication snmp-server enable traps envmon snmp-server enable traps bgp snmp-server enable traps frame-relay snmp-server host XXX.XXX.XXX.XXX public tty frame-relay isdn envmon bgp snmp You must enable traps for BGP events and then define the SNMP console "host" to receive those traps and list the traps you want sent to that host. Hope this helps, Chad ------------------------------------------ Chad Skidmore VP Operations & Engineering Data Source, L.L.C. http://www.dsource.com cskidmore(a)dsource.com > -----Original Message----- > From: Curtis Generous [SMTP:generous@uucom.com] > Sent: Thursday, June 05, 1997 7:07 AM > To: nanog(a)merit.edu > Subject: Loss of BGP peering monitoring via SNMP > > 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

1 0

RE: Loss of BGP peering monitoring via SNMP
by Rodney Joffe 05 Jun '97

05 Jun '97

Try "snmp-server enable traps bgp" on a cisco. Rodney (no more Mr. nice-guy) Joffe Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: Curtis Generous [SMTP:generous@uucom.com] > Sent: Thursday, June 05, 1997 7:07 AM > To: nanog(a)merit.edu > Subject: Loss of BGP peering monitoring via SNMP > > 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

1 0

BGP Routing problem
by Anthony Walker 05 Jun '97

05 Jun '97

Hi We are a ISP in South Africa and have a problem we are trying to figure out rather urgently, without much success so far. We are currently multi-homed during the day and tripple homed at night. (our peaks are at night and we get cheap bandwidth from another ISP who has their peak in the day). Internic has refused to give us our own block of addresses which would have made thins much simpler. (despite repeated attempts, and we now have 7 /24's from various places and badly need more). Basicaly we (AS6180) have been announcing all our adresses including 196.25.116.0, 196.25.117.0 and 196.25.203.0 via AS 3741 at night, and this gets switched of during the day. The problem seems to relate to the fact that these addresses are part of AS 5713's CIDR 196.25.0.0/16 and we thought we could get away with announcing them like this. It did work fine for over a week, but now today we have a problem. MAE-East (see example at end of message) , the Sprintnap and who knows who else still have entries for these via AS3741 but they are showing as received-only, and no best path. Yet via MAE West they are fine. We are going to stop announcing these via AS3741 at night, but its been 9 hours now since they were not announced and these received-only entries are still sitting there blocking these routes from it seems about a third of the internet. Can any one offer any comments on why they are still there, what received-only means and how we can get if fixed? Many thanks Regards Anthony Walker MAE-East Looking Glass Results Query: bgp Addr: 196.25.203.0 BGP routing table entry for 196.25.203.0/24, version 5006458 Paths: (1 available, no best path, advertised over IBGP) 1673 1239 4005 3741 6180, (received-only) 192.41.177.141 from 192.41.177.141 (140.223.57.217) Origin IGP, external

1 0

Wavelan & Linux @ NANOG
by Joe McGuckin 05 Jun '97

05 Jun '97

I have a Linux laptop & want to use one of the WaveLAN (Digital) wireless units. If someone has this working, I'd like to hear from you. Thanks, Joe McGuckin 1-888-371-4284 toll-free pager

2 1