- Test - lists.nanog.org

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

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

13 Oct '99

I do alot of stuff on a system sitting on a T1 to CW from my home which (through work) gets to the net via frac-T3 to Sprint and UUNet. Suddenly, yesterday connectivity from work/home to CW began to suck horribly. Today, it's no better. I called the Sprintlink NOC yesterday, and their response was it was an overloaded peering point in Washington, and don't hold my breath waiting for it to improve. Has anyone else noticed / been affected by this? Between the packet loss and the latency, a 300bps modem would be preferable. I can get about half a line ahead of pine while typing, waiting for chars to show up so I can see my typos. Maybe we should cancel the increase we just ordered in our Sprint T3 and order a CW frac-T3 instead. Hostname %Loss Rcv Snt Best Avg Worst 1. maui.atlantic.net 0% 19 19 1 3 26 2. border1-s2-1.Orlando-WCom.atlantic.n 0% 19 19 21 40 99 3. sl-gw3-orl-6-0-1.sprintlink.net 0% 19 19 23 55 192 4. sl-bb10-orl-0-3.sprintlink.net 0% 19 19 23 38 98 5. sl-bb10-rly-1-0.sprintlink.net 0% 19 19 40 55 105 6. sl-bb2-dc-4-0-0.sprintlink.net 0% 19 19 42 58 100 7. core7-hssi0-0-0.Washington.cw.net 12% 15 18 1024 1083 1150 8. corerouter1.WashingtonEast.cw.net 6% 16 18 1038 1081 1144 9. acr1-loopback.Restonrst.cw.net 0% 17 18 1031 1079 1159 10. 206.24.179.2 95% 0 17 0 0 0 11. pride.se.cw.net 95% 0 17 0 0 0 12. webserver.ie.cw.net 0% 16 17 1014 1086 1161 ---------------------------------------------------------------------- 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__________

2 1

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

13 Oct '99

See http://noc.bn.ru/~alex/MON I know about 5 - 10 installation here. On Wed, 13 Oct 1999, Craig A. Haney wrote: > Date: Wed, 13 Oct 1999 09:55:47 -0400 > From: Craig A. Haney <craig(a)seamless.kludge.net> > To: Alex P. Rudnev <alex(a)virgin.relcom.eu.net> > Subject: Re: Regarding global BGP community values > > >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 -:) > > someone still uses SNMPSTATD? > > -craig > > 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)

1 0

Re: Regarding global BGP community values
by Vadim Antonov 13 Oct '99

13 Oct '99

Aw, Tony, you're talking to a guy who made his name programming discrete transistor computers with core memory (i mean _real_ core memory, and real germanium transistors :) I bet he knows more than anyone else in this list about squeezing bits :) Cheers, --vadim PS Old-timers are entitled to being grumpy about how wasteful the modern computing is. After all, how do you feel about operating systems which just have to have at least 30 Mb of RAM to be useful? :) From: Tony Li <tony1(a)home.net> "Alex P. Rudnev" wrote: > The growth itself do not cause the problems, but in conjunction with the > poor router implementation (which cause 60,000 routes to use 30 MB of the > RAM - that means 500 bytes for every prefix -:) and numerous memory leaks > in the router implementation cause the problem. If we look around, we'll > see existing computers (including embedded ones) have not CPU and memory > problems, and all problems we see with the routers are mainly caused by > the bad implemented text. I, and the rest of the Internet community, would like to invite you to start a router company and show us how it can be done with far less memory. ;-) More seriously, you might take a look around and note that there are not a great deal of difference in the amount of memory needed to support a prefix across the various well-known implementations. Which is not to say that we're blameless, just that a lot of good people have worked hard and are all equally incompetent at conserving memory while simultaneously producing a scalable, stable, feature-rich implementation. Regards, Tony

2 1