- NANOG - lists.nanog.org

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

Teleglobe / Bell Nexxia nexthop problems ?
by Mike Tancsa 25 Apr '04

25 Apr '04

I am not a direct customer of either of them, but have a lot of endpont sites in Quebec which go through 6543 and 577. Anyone from either of those networks know whats up ? Since we usually go through Chicago to reach them, this is the only reason we noticed. There are other prefixes involved, not just the /16 From the teleglobe LG in Chicago, Type escape sequence to abort. Tracing the route to 199.243.35.3 1 if-2-0.core2.Chicago3.teleglobe.net (66.110.14.166) [MPLS: Label 21 Exp 0] 12 msec 12 msec 12 msec 2 if-9-0.core2.Scarborough.Teleglobe.net (207.45.222.181) 12 msec 12 msec 8 msec 3 ix-7-0.core2.Scarborough.Teleglobe.net (207.45.198.2) 28 msec 24 msec 24 msec 4 * * * 5 * * * 6 * * * 7 * * * vs out of newyork, its fine Type escape sequence to abort. Tracing the route to 199.243.35.3 1 if-8-0.core3.NewYork.Teleglobe.net (64.86.83.154) [MPLS: Label 74 Exp 0] 204 msec 204 msec 200 msec 2 if-9-0.core2.Montreal.Teleglobe.net (207.45.222.110) 204 msec 208 msec 8 msec 3 ix-8-0.core2.Montreal.Teleglobe.net (207.45.204.46) 204 msec 204 msec 216 msec 4 core4-montreal02-pos6-2.in.bellnexxia.net (206.108.107.61) 200 msec 200 msec 204 msec 5 64.230.243.238 204 msec 12 msec 12 msec 6 64.230.242.94 16 msec 16 msec 16 msec 7 64.230.242.86 56 msec 52 msec 56 msec 8 64.230.248.178 64 msec 60 msec 60 msec 9 64.230.251.18 464 msec 200 msec 200 msec 10 199.243.35.3 [AS 577] 488 msec 320 msec 444 msec The lg from Chicago says, BGP routing table entry for 199.243.0.0/16, version 4127369 Paths: (2 available, best #2) Advertised to peer-groups: reflector-client Advertised to non peer-group peers: 66.110.14.2 204.255.169.17 206.223.119.39 206.223.138.254 577, (aggregated by 577 206.108.96.201) 207.45.220.252 (metric 45) from 207.45.223.231 (207.45.223.231) Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate Community: 6453:1000 6453:1200 6453:1203 Originator: 207.45.220.252, Cluster list: 207.45.223.231 577, (aggregated by 577 206.108.96.201) 207.45.220.252 (metric 45) from 207.45.222.246 (207.45.222.246) Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best Community: 6453:1000 6453:1200 6453:1203 Originator: 207.45.220.252, Cluster list: 207.45.222.246 -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0