October 1999 - Test - lists.nanog.org

Re: Regarding global BGP community values
by Alex P. Rudnev 14 Oct '99

14 Oct '99

Hmm. In the 'SNMPSTATD' monitoring I use (it's in the near plans) to monitor not _FREE MEMORY but _THE BIGGEST PIECE OF THE FREE MEMORY_. It's the most critical argument. If it is less than 128K, 'config' command do not work; if it is less than 1500 bytes, nothing works at all -:) > > AFAIK, there is some more memory wasting and dangerous feature in > current (at least it was so year ago) implementation of memory allocation > subsystem in Cisco: when you are going below some magic value > (for defaultless routers usualy below 10-8 megs) and have even > moderate BGP activity, very soon (less then a day) you will be out of > memory even in the presence of this 8-10 megs of free memory because your largest fragment will be very close to 0. > As I was told several years ago this is fundamental "feature" of > memory allocation implementation (poor fragmentation resistance with low memory and lots of small alloc's/free's). The fundamental feature for the REAL-TIME device (such as ROUTER) should be a lot of HOT-DOG mechanisms preventing /at least/ lost of the control over the device. In case of such _voracious_ processes (as BGP is) it should be used any mechanism preventing it from catching all existing resources (CPU and MEMORY in our case).

2 1

BGP and memory
by Alex P. Rudnev 13 Oct '99

13 Oct '99

Amazing fact: Come back to this talks about BGP and memory, I calculated the size of total BGP information in the 'show ip bgp' cisco output. No doubt, it's not all attributes printed here, but on the other hand it's the text view, not the binary presentation. Results are: 118113 lines 10065161 bytes (10Mb) 100 bytes/route , in the text form, average. Compare to 65955 network entries and 159898 paths using 12154642 bytes of memory 31322 BGP path attribute entries using 2800660 bytes of memory 14718 BGP route-map cache entries using 235488 bytes of memory 1712 BGP filter-list cache entries using 27392 bytes of memory 178 received paths for inbound soft reconfiguration BGP activity 540738/474776 prefixes, 5007746/4847848 paths 3037709 prefixes revised. and note - this is BINARY form... No, if someone want to implement the core BGP in the 8 MB ram, he can do it as well (through the cost of his work + cost of debug should be much greater than the cost of 128RAM memory -:)). Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

4 4

California Outage ?
by Derrick Bennett 13 Oct '99

13 Oct '99

Around 2:45 PST we started seeing massive response time issues and connectivity problems. I have reports that SunnyVale had an outage and that connections to Palo Alto are down. I also noticed massive traffic spikes on the above.net graphs for Mae-West and Paix connections. Anyone have any info on what exactly died out there today ? Derrick Bennett

4 3

Re: BGP and memory
by Ron Buchalski 13 Oct '99

13 Oct '99

>From: Jared Mauch <jared(a)puck.Nether.net> >To: Ron Buchalski <rbuchals(a)hotmail.com> >CC: alex(a)virgin.relcom.eu.net, nanog(a)merit.edu >Subject: Re: BGP and memory >Date: Wed, 13 Oct 1999 15:55:57 -0400 > > > Or buy third party memory instead of supporint >Ron's children, or his stock portfolio ;) > Memory's cheap, as long as you continue to buy the right boxes for it! -rb > - jared > >On Wed, Oct 13, 1999 at 10:58:46AM -0700, Ron Buchalski wrote: > > > > The problem is, it's probably cheaper to engineer a box with more low >cost > > memory than it is to pay a high salary to a programmer to write small >code. > > > > At least, it is in _this_ part of the world... ;-) > > > > -rb > > > > >From: "Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> > > >To: nanog(a)merit.edu > > >Subject: BGP and memory > > >Date: Wed, 13 Oct 1999 18:22:30 +0400 (MSD) > > > > > > > > >Amazing fact: > > > > > >Come back to this talks about BGP and memory, I calculated the size of > > >total BGP information in the 'show ip bgp' cisco output. No doubt, it's > > >not all attributes printed here, but on the other hand it's the text >view, > > >not the binary presentation. > > > > > >Results are: > > > > > > 118113 lines > > > 10065161 bytes (10Mb) > > > > > >100 bytes/route , in the text form, average. > > > > > >Compare to > > > > > >65955 network entries and 159898 paths using 12154642 bytes of memory > > >31322 BGP path attribute entries using 2800660 bytes of memory > > >14718 BGP route-map cache entries using 235488 bytes of memory > > >1712 BGP filter-list cache entries using 27392 bytes of memory > > >178 received paths for inbound soft reconfiguration > > >BGP activity 540738/474776 prefixes, 5007746/4847848 paths > > >3037709 prefixes revised. > > > > > >and note - this is BINARY form... > > > > > >No, if someone want to implement the core BGP in the 8 MB ram, he can >do > > >it as well (through the cost of his work + cost of debug should be much > > >greater than the cost of 128RAM memory -:)). > > > > > >Aleksei Roudnev, Network Operations Center, Relcom, Moscow > > >(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) >230-41-41, > > >N 13729 (pager) > > >(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > > > > > > > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com > >-- >Jared Mauch | pgp key available via finger from jared(a)puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. >END OF LINE | > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: MCI Worldcom fiber cut in White Plains, NY
by Sean Donelan 13 Oct '99

13 Oct '99

Paul A Vixie <vixie(a)mibh.net> writes: > i take it that it's mostly the bypass carriers and the long haul > carriers who cheese out on ringing their sonet on diverse paths? > i know pac bell rings just about everything. how are the other > regionals? Due to the way the FCC regulations are written, ILECS appear to have more reportable outages. However, due to who carries the most Internet traffic, the cuts which make NANOG tend to involve CLECs and a couple of long-haul IXCs. Many of which aren't reportable outages according the the FCC regulations. I have a problem with the way the reporting is done, in particular the "root cause" analysis. Usually the backhoe is blamed as the root-cause. But as Paul points out, why should a single cut lead to a reportable incident in these facilities? As is usual in other industries, there is often a string of decisions leading up to the final direct cause of the the outage. Whether a regional has rings or strings depends on where you look. In *major* metro areas, they tend to have rings. In the suburbs, strings start appearing. In rural areas, rings or any type of diversity is hard to find. "Rural" isn't necessarily god-forsaken country either. Third-tier suburbs around a metro area are a typical example. They are often spokes hanging off the metro ring. SBC (parent of Pacbell, Ameritech, and others) has several outage reports on file where most or all the circuits in a region were routed through a single facility.

1 0

Re: how to waste fiber (was:OT:MarketSpeak)
by Danny McPherson 13 Oct '99

13 Oct '99

> > > 50ms is fast? You'd drop sevral packets I'd guess. > > easily survivable. but will bgp flap? sure, if your BGP holdtime is less than 50ms :-) On a series note, GR253 specs it at 50ms. Convergence in regional rings, however, is often more a function of propagation delay, and more realistically, with larger-than-probably-should-be rings expect times more around the 100ms range. As for how it'd look on your router, assuming a trunk failure, you'd likely see a bunch of CRC or frame errors on the interface, and an array of SONET errors on the controller. Then, presumably, you'd see a bit more latency on the connection while running on the usually less-optimally-routed protect path. Of course, more interesting than presumably transparent trunk failures in relation to SONET protection, are trib failures with inter-router APS on the trib side. This requires a bit more attention to detail (speaking from experience). -danny

2 1

NT server problem.
by Tatsuya Kawasaki 13 Oct '99

13 Oct '99

Could anyhone tell me that if NT server "runs" nslookup. Does NT cache nslookup entries for a period time. Ie, nslookup does not actually query to server. Unfortunately I do not have access to NT server to check this. TIA, Tatsuya /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tatsuya Kawasaki KIVEX.com (Division of Allegiance Telecom) Unlock the Power of the Internet URL:www.KIVEX.com Phone 301.215.6777 Fax 301.215.5991 Affiliation given for identification not representation /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

2 2

Re: BGP and memory
by Ron Buchalski 13 Oct '99

13 Oct '99

The problem is, it's probably cheaper to engineer a box with more low cost memory than it is to pay a high salary to a programmer to write small code. At least, it is in _this_ part of the world... ;-) -rb >From: "Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> >To: nanog(a)merit.edu >Subject: BGP and memory >Date: Wed, 13 Oct 1999 18:22:30 +0400 (MSD) > > >Amazing fact: > >Come back to this talks about BGP and memory, I calculated the size of >total BGP information in the 'show ip bgp' cisco output. No doubt, it's >not all attributes printed here, but on the other hand it's the text view, >not the binary presentation. > >Results are: > > 118113 lines > 10065161 bytes (10Mb) > >100 bytes/route , in the text form, average. > >Compare to > >65955 network entries and 159898 paths using 12154642 bytes of memory >31322 BGP path attribute entries using 2800660 bytes of memory >14718 BGP route-map cache entries using 235488 bytes of memory >1712 BGP filter-list cache entries using 27392 bytes of memory >178 received paths for inbound soft reconfiguration >BGP activity 540738/474776 prefixes, 5007746/4847848 paths >3037709 prefixes revised. > >and note - this is BINARY form... > >No, if someone want to implement the core BGP in the 8 MB ram, he can do >it as well (through the cost of his work + cost of debug should be much >greater than the cost of 128RAM memory -:)). > >Aleksei Roudnev, Network Operations Center, Relcom, Moscow >(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, >N 13729 (pager) >(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: OT:MarketSpeak
by Sean Donelan 13 Oct '99

13 Oct '99

Eric Germann <ekgermann(a)cctec.com> writes: > Someone needs to flog the marketing people at Sprint .. I suspect Sprint's engineers are already flogging the marketing people. > Switch routers in its backbone, which translates into greater ^^^^^^^ > response time and reliability for your users" Only a marketing department would think "greater" response time is a good thing. Most people want lower/faster response times, not greater/slower response times from their networks. More is not always better.

1 0

RE: Peering: Sprint & CW
by jlewis＠lewis.org 13 Oct '99

13 Oct '99

I was able to solve the problem (at least for us) with some BGP tuning. CW was already prefering UUNet to get packets back to us, so I have us prefering UUNet for reaching CW by prepending received routes from Sprint that contain _3561_. BTW...several people have asked about the program that generated the output that looks like a combination of ping and traceroute. It's mtr. http://www.bitwizard.nl/mtr/ ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| Spammers will be winnuked or System Administrator | nestea'd...whatever it takes Atlantic Net | to get the job done. _________http://www.lewis.org/~jlewis/pgp for PGP public key__________

1 0