- Test - lists.nanog.org

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 26 Apr '04

26 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 26 Apr '04

26 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

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

25 Apr '04

> Alexander Hagen > As a cost cutting alternative - has anyone played with > the 2900 XL series using sub interfaces to turn them > into virtual router ports ? "routing on a stick". As long as you understand that the aggregate bandwidth can't be more than the port you hook too, fine. On a 7500, you need your FE on a real VIP, not the legacy FE blade that was the precursor to the VIP2. Although there is a later version that's ISL capable, the performance is not there. Michel.

1 0

RE: Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5key for old session after key change)
by Malayter, Christopher 25 Apr '04

25 Apr '04

I agree here. If we can roll new md5 keys without session resets I am all for it. I believe Juniper needs to fix their implementation. Especially with md5 rolling out network wide for quite a few networks. If an employee leaves and we have to reset the md5 passwords for the entire network with a hybrid of Juniper and Ciscos, I would love to not have to bounce all of my sessions. I think your best bet is to call JTAC and ask for a feature request. -Chris -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Saturday, April 24, 2004 4:32 PM To: sthaug(a)nethelp.no Cc: nanog(a)merit.edu Subject: Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5key for old session after key change) On Sat, 24 Apr 2004 sthaug(a)nethelp.no wrote: > But as long as the session *is* reset anyway, the current situation is > extremely confusing - the log messages (on both Cisco and Juniper) give > no indication that the invalid key in question is for an *old* BGP > session, no longer active! That's why I hope Juniper will fix their implementation not to reset the session and to stop using an old key. Once the key is changed, all new packets (including new packets for old sessions) should use the new key, not the old key. You think the bug is on Cisco's side, I think the bug is on Juniper's side. Hence interoperability.

2 1

Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrongMD5key for old session after key change)
by sthaug＠nethelp.no 25 Apr '04

25 Apr '04

> We've experienced this as well, between old versions of IOS without the new > feature Sean describes, and newer versions with the new feature. > > Between two versions of IOS, we were successful at making this change if we > changed both MD5 passwords at the same time: > > So if you do this: > > a) Configure password in Router A > b) Wait till the first keepalive > c) Configure password in Router B (at this time getting error message) > d) After two keepalives (total three keepalive) the bgp goes down and comes > up automatically > e) The error messages still seen for 5 minutes > > However, if you skip steps b and c, and immediately configure the far end > with the new password, there are no flaps, and should be no logs. > > Please let me know if this works for you. It certainly doesn't work between Cisco and Juniper, because the Juniper always resets the session when you configure a new MD5 key. After some more lab testing I have concluded that the key (pardon the pun) to make this work between Cisco and Juniper, and not get a lot of log messages about invalid keys, is to get an orderly termination of the old BGP session. I found two ways to make sure that happens: 1. Configure (and commit) the new key on the Juniper side first. This leads to an orderly termination of the existing BGP session, and then the new key can also be configured on the Cisco side. 2. Do an explicit reset of the BGP session on the Cisco side (which again gives you an orderly termination of the existing BGP session), and then configure the new key on both routers (here it doesn't matter which router gets the new key first). It would Really Nice (tm) if this was documented in the manuals. But to reiterate the original point - if a new key is configured on the Cisco side first, without resetting the existing BGP session, Cisco and Juniper will disagree about the key used to terminate the existing BGP session, with lots of confusing log messages as a result. Now that i understand what's happening, I agree that it would be good for Juniper to implement key change without BGP session reset too - but until that happens, the current situation is rather confusing (how is the user supposed to guess that the "invalid key" messages refer to the old BGP session?). Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

3 2