April 2004 - Test - lists.nanog.org

RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 or other vendor ?
by Michel Py 26 Apr '04

26 Apr '04

> "Alexander Hagen" > What about a 7505 w/ RSP4/256 and 2 VIP 2-50/128s with 4 PA-FE-TXs. I would get a 7507 w/redundant RSPs and redundant PS. > For additional port density a 3550 ? Even a 2650 would do >> What is better about the 7206 VXR ? > Fewer software bugs, Not in my experience. > simpler platform, half the vertical space in the rack, > redundant power supplies, Indeed. The part I missed earlier is that I think Alexander needs to buy the platform. As of today I can not recommend buying any 7500 as even the 7507 and the 7513 are going to EOL sooner or later. If you can't afford a 7603, then the 7206VXR with NPE400G and a gigabit trunk to a 3550 is what I would do.

4 5

RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 o r other vendor ?
by Chris Ranch 26 Apr '04

26 Apr '04

Crap, sorry about the html.

1 0

RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 o r other vendor ?
by Chris Ranch 26 Apr '04

26 Apr '04

Steve Gibbard wrote: > Being able to take a full BGP table in a Cisco is simply a matter of > having enough memory. I just accidentally ran into an ugly surprise turning up some 4006/SupIV's with full tables. There's a 128K hardware fib table limit. Crack it, and CEF shuts down. There's an unallocated 350M block lying around. Took the TAC a while to point out the fine print, and now I face the pleasure of a forklift upgrade. Chris

1 0

Providing service for geographically disparate fiber SANs ... Level3 ?
by Joe Schmoe 26 Apr '04

26 Apr '04

Learning a lot about SANs and will possibly need to build one ... and am interested in the feasibility of distributing a SAN across a wide geographical area. Because of their wide private network and reasonable costs, Level3 comes to mind ... So the question is, if you need to build a fiber SAN across several datacenters, do you have the ability to have a real fiber connection between all of them, or is it a virtual connection, where your fiber goes to their routers, which goes to fiber between their routers, etc., making several hops between each node of your SAN ? This seems "bad" to me, because a router problem between the two nodes would essentially "break" the SAN - much like breaking a hardware RAID array by disconnecting a drive. Comments ? How are people, from the point of view of the network, building fiber SANs, and what providers (L3 ?) are they using ? thanks. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

2 1

RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200orother vendor ?
by sthaug＠nethelp.no 26 Apr '04

26 Apr '04

> I was surprised by the similarities between the 7507 and 7513. Why EOL > the one device that has a pleasing form factor ? There are MANY > providers who would be quite happy with ~ 600 mbps? That's a lot of > billings... It's the 7505 that's EOLed. Possibly because it doesn't sell well enough, I don't know. For an ISP environment it has a significant problem in not supporting redundant powersupplies. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Deadline Apr 27: Extending CALEA to IP-Enabled services
by Sean Donelan 26 Apr '04

26 Apr '04

Verisign submitted a very nice presentaiton with pictures showing its proposal for monitoring all parts of the network including ISPs, hotels, cafes, universities, etc. http://gullfoss2.fcc.gov/prod/ecfs/retrieve.cgi?native_or_pdf=pdf&id_docume… You can search for all other submissions on the FCC web site under the ECFS system using the proceeding number RM-10865. Verisign's is not the only proposal. There are many alternative ways to assist law enforcement, some of which are much less expensive and possibly more effective.

1 0

More MD5 fun: Cisco uses wrong MD5 key for old session after key change
by sthaug＠nethelp.no 26 Apr '04

26 Apr '04

The other day I was trying to configure MD5 authentication on a BGP peering with MCI. Juniper at our end, Cisco at their end. We couldn't get the session up the way we wanted - or rather, we got the session up, and everything *seemed* to work fine, but the Cisco router was logging lots of "Invalid MD5 digest" - this did not seem to stop. Today I saw the same thing on a session where I controlled both ends, and was later able to reproduce it in the lab. The routers are: Cisco 7206, IOS 12.0(23)S6, IP 7.0.0.9 Juniper M7i, JunOS 6.2R2.4, IP 7.0.0.18 The session was sniffed with the latest (-current) version of tcpdump from tcpdump.org - which supports verification of TCP MD5 digests ("chel3ixy" is the MD5 key): # tcpdump -ni xl1 -s 1500 -M chel3ixy tcp port 179 Here we see normal BGP keepalives, all MD5 digests valid: 21:19:10.183900 IP 7.0.0.18.3961 > 7.0.0.9.179: P 76:95(19) ack 77 win 17102 <nop,nop,md5:valid>: BGP, length: 19 21:19:10.184306 IP 7.0.0.9.179 > 7.0.0.18.3961: P 77:96(19) ack 95 win 16206 <md5:valid,eol>: BGP, length: 19 21:19:10.298365 IP 7.0.0.18.3961 > 7.0.0.9.179: . ack 96 win 17083 <nop,nop,md5:valid> 21:19:40.181172 IP 7.0.0.18.3961 > 7.0.0.9.179: P 95:114(19) ack 96 win 17083 <nop,nop,md5:valid>: BGP, length: 19 21:19:40.181690 IP 7.0.0.9.179 > 7.0.0.18.3961: P 96:115(19) ack 114 win 16187 <md5:valid,eol>: BGP, length: 19 21:19:40.280368 IP 7.0.0.18.3961 > 7.0.0.9.179: . ack 115 win 17064 <nop,nop,md5:valid> 21:20:10.202449 IP 7.0.0.18.3961 > 7.0.0.9.179: P 114:133(19) ack 115 win 17064 <nop,nop,md5:valid>: BGP, length: 19 21:20:10.202831 IP 7.0.0.9.179 > 7.0.0.18.3961: P 115:134(19) ack 133 win 16168 <md5:valid,eol>: BGP, length: 19 21:20:10.302389 IP 7.0.0.18.3961 > 7.0.0.9.179: . ack 134 win 17045 <nop,nop,md5:valid> 21:20:40.214582 IP 7.0.0.18.3961 > 7.0.0.9.179: P 133:152(19) ack 134 win 17045 <nop,nop,md5:valid>: BGP, length: 19 21:20:40.214960 IP 7.0.0.9.179 > 7.0.0.18.3961: P 134:153(19) ack 152 win 16149 <md5:valid,eol>: BGP, length: 19 21:20:40.314417 IP 7.0.0.18.3961 > 7.0.0.9.179: . ack 153 win 17026 <nop,nop,md5:valid> After a while I decided to change the MD5 key. The session with the new key came up and looked fine, but the old session didn't close properly. Notice the close is initiated from the Juniper side, and the first packet from the Cisco side is now sent with an invalid MD5 digest - it turns out that the packet is actually sent with an MD5 digest based on the *new* key: 21:20:56.850905 IP 7.0.0.18.3961 > 7.0.0.9.179: F 173:173(0) ack 153 win 17026 <nop,nop,md5:valid> 21:20:57.845617 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 21:20:59.845711 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 21:21:03.846005 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 21:21:10.551830 IP 7.0.0.9.179 > 7.0.0.18.3961: P 153:172(19) ack 152 win 16149 <md5:invalid,eol>: BGP, length: 19 And since Juniper is now getting packets with invalid MD5 digests (for this session, which hasn't yet been properly closed), we get a *long* sequence (about 10 minutes) of: 21:23:03.854077 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 21:24:05.941658 IP 7.0.0.9.179 > 7.0.0.18.3961: FP 153:212(59) ack 152 win 16149 <md5:invalid,eol>: BGP, length: 59 21:24:07.858411 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 21:25:11.862725 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 21:25:35.028423 IP 7.0.0.9.179 > 7.0.0.18.3961: FP 153:212(59) ack 152 win 16149 <md5:invalid,eol>: BGP, length: 59 21:26:15.867021 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 21:27:04.115353 IP 7.0.0.9.179 > 7.0.0.18.3961: FP 153:212(59) ack 152 win 16149 <md5:invalid,eol>: BGP, length: 59 21:27:19.871338 IP 7.0.0.18.3961 > 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 <nop,nop,md5:valid>: BGP, length: 21 And for every packet from the Juniper side (trying to close the old BGP session properly, with the correct MD5 key for the old session), the Cisco side now logs an invalid digest: Apr 24 21:23:03.854 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:24:07.857 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:25:11.860 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:26:15.863 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:27:19.871 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Meanwhile, the new session (with the new MD5 key) is up and all is well *on that session*. But because the Cisco side keeps logging these messages, it *looks* like the new session is somehow not working. As far as I can see, the bug here is clearly on the Cisco side. We will definitely be logging a TAC case about this. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

5 4

Re: Hardware for full mesh bgp
by Henning Brauer 25 Apr '04

25 Apr '04

* Brad Knowles <brad.knowles(a)skynet.be> [2004-04-25 18:16]: > At 6:09 PM -0700 2004/04/25, Henning Brauer wrote: > > * Henning Brauer <hb-nanog(a)bsws.de> [2004-04-25 18:04]: > >> check this out: http://somewhere.whereever/pic.jpg > > eek. that should have been > > http://misc.bsws.de/img_1001.jpg > Okay, so you've got the picture now. However, I'm sure that some > people are going to be interested in more details on the hardware -- > you might want to tell them it's a Soekris net4501, or whatever. it's a 4801. > Also, are you using the crypto accelerator for calculating the MD5 > hashes? no, we have no cards here currently.

2 3

Hardware for full mesh bgp
by Henning Brauer 25 Apr '04

25 Apr '04

In the light of people dicussing the hardware requirements for running full mesh bgp with tcmd5 and minimal filtering I just have to point out what we're doing here currently... 14 OpenBSD developers who hack networking stuff from all over the world have flown in to enjoy 4 days of coding. OF course we are also working on our bgpd. As we're a little low on electrical power here we use a lot of small embedded machines - and I have full mesh bgp sessions on quite some of those, using tcp md5sig sessions of course. check this out: http://somewhere.whereever/pic.jpg that little green box bob and myself are holding in our hands has a full feed. It is a 266 MHz Geode with 128MB RAM working off a CF card. Getting the session established and the full table transferred takes less than 8 seconds...

1 1

Re: Cisco Rolls Major Patches to TCP Flaw
by Chris Moody 25 Apr '04

25 Apr '04

http://tinfoilhat.shmoo.com/ Should do the trick. ;o) -Chris > > Does anybody have a tinfoil hat I can borrow so that I may join in the > festivities? > > -J > > -- > Jeff Workman | jworkman(a)pimpworks.org | http://www.pimpworks.org >

1 0