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 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

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

25 Apr '04

> It is a great box. But I need BGP. I notice Cisco does not support 7505 > with Software Advisor but does 7507 whats the deal with that ? There are no differences between the 7505 and the 7507 when it comes to BGP. As for the 3550, it'll do BGP just fine - but it can't handle a full routing table. Same with the 3750. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

RE: Lazy network operators
by Michel Py 25 Apr '04

25 Apr '04

> Paul Jakma wrote: > Hmmm, or rather, there just wont be any demand for > IPv6 deployment, at least from the edges (consumers, > small/medium networks). Oh oh I see another one taking the path that leads to the dark side. _.-'~~~~~~`-._ / || \ / || \ | || | | _______||_______ | |/ ----- \/ ----- \| / ( ) ( ) \ / \ ----- () ----- / \ / \ /||\ / \ / \ /||||\ / \ / \ /||||||\ / \ /_ \o========o/ _\ `--...__|`-._ _.-'|__...--' | `' |

12 17

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

25 Apr '04

> > I bought a Riverstone Rs-3000 for BGP with a single upstream provider. > > Great Deal. > > Yeah, it might be a Great Deal (tm), but you're in for some surprises. > I've seen an RS-8600 (with CM3 and 512MB on board) nearly melt under > 13Mbps of Nachi, to the point that I had to set the CM failover > keepalive timer to >30 seconds. This should come as no surprise - the Riverstone boxes are flow-based. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

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

24 Apr '04

> > 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: > > This is a feature, and hopefully Juniper will also add the same feature > soon. The feature allows you to change the MD5 key without flapping the > BGP session which is very important on large peering sessions. There is > no requirement that MD5 keys must remain constant throughout an entire TCP > session, or to terminate a TCP session when the key changes. As long as > both sides agree, the key can be changed at any time including in the > middle of a TCP session. New packets after the key change are sent with > message digests based on the new key. 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! Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: TCP/BGP vulnerability - easier than you think
by Iljitsch van Beijnum 23 Apr '04

23 Apr '04

On 21-apr-04, at 22:00, Paul Jakma wrote: >>> Why would MD5 be more of a crypto DoS risk with IPSec AH headers than >>> with bgp tcp-md5? >> Beats me. But why do you bring up IPsec? > The paragraph is quoted is your advice against using IPSec, Unless I was really sleep-typing I didn't say anything about IPsec, just about "crypto", which as far as I'm concerned includes MD5, which we were talking about. > I dont > see why an MD5 auth header IPSec protected sessions would have more > risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The > risk is due to MD5, not IPSec :). As Crist Clark just pointed out: the presence of the SPI and replay counter actually makes it harder to do a crypto DoS against IPsec than the TCP MD5 option (assuming the traffic can't be sniffed). Makes you wonder if those TDM guys weren't on to something with out of band signalling, doesn't it? >> Anyway, what needs to happen is a form of crypto where the >> expensive algorithms are only executed for good packets and not for >> all packets. > So configure ipsec to authenticate packets between the peers allowing > only md5 or somesuch. I dont know about other IOS, but other > implementations do allow one to specify security associations on a > per port basis. Another advantage of IPsec is that it allows for key changes in a sane way. I'm not sure I'd want my routers to run IKE, though. However, note that even a relatively light-weight check such as an HMAC-MD5 can blow away a typical router CPU at orders of magnitude below line rate, so it is essential that attackers don't get to bypass the non-crypto checks for than a tiny fraction of the packets they spoof.

2 1

RE: Backbone IP network Economics - peering and transit
by Michel Py 23 Apr '04

23 Apr '04

> Deepak Jain wrote: > But that structure doesn't vary vastly if you'd traffic out > that gig via transit vs direct connect. It does vary (and > add lots of infrastructure) if you don't aggregate your > traffic at IXes and instead use loops to bring transit to > you instead of going to it. (say a few 100Mb/s or OC3s in > a few places instead of a GigE at an IX). Indeed. > Perhaps we should (for technical reasons) describe > peering as "direct connecting". This makes a lot of sense to me (although I would suggest a different name later). Since the beginning I have been trying to make the point that "direct connecting" was typically a no-brainer in terms of money. Peering when you have to buy the local loop is not such a slam dunk. > Business reasons aside, technically the difference is > that with transit you are expecting access via indirect > connections to networks. I'm not so sure about this. There are lots of people that buy transit and are directly connected to their provider in an IX for example. > With peering you expect direct connections into a network. If "direct connecting" != peering then definitely. Maybe we need to say differentiate between: - Connected transit - Remote transit - Connected peering - Remote peering And agree that, by default, transit ~= remote transit peering ~= direct peering Michel.

3 2