Hi Danny, Thanks for you help - no problems. I would agree 192 vs 63/64 it is to much of a coincidence for it not to be related somehow. Weirder and weirder - presumably people trying to hack the BGP session below: neighbor 212.121.34.1 ttl-security hops 192 And the session is up and we get: Extended IP access list ACL-MATCH-TTL-0/254 (Compiled) 10 permit ip any any ttl eq 0 (869 matches) 20 permit ip any any ttl eq 1 (1 match) 260 permit ip any any ttl eq 25 (1 match) 580 permit ip any any ttl eq 57 (1 match) 590 permit ip any any ttl eq 58 600 permit ip any any ttl eq 59 610 permit ip any any ttl eq 60 620 permit ip any any ttl eq 61 (2 matches) 630 permit ip any any ttl eq 62 (2 matches) 640 permit ip any any ttl eq 63 (1 match) <- presumably the foundry 1210 permit ip any any ttl eq 120 (2 matches) 1220 permit ip any any ttl eq 121 (2 matches) 1230 permit ip any any ttl eq 122 (1 match) 1240 permit ip any any ttl eq 123 (1 match) 1250 permit ip any any ttl eq 124 (1 match) 2500 permit ip any any ttl eq 249 (6 matches) 2510 permit ip any any ttl eq 250 (3 matches) This is connected to an ethernet IX and all peers are one hop away. Kind Regards Ben -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: 15 February 2008 01:16 To: Ben Butler Cc: Hank Nussbacher Subject: Re: BGP TTL Security On Feb 14, 2008, at 6:12 PM, Ben Butler wrote:

Hi,

I have put a route map on the interface and matched every TTL from 0 to 254 and I am only getting matches on TTL 0.

Is the ttl-security check still in place? I believe the way Cisco implemented that is that if the TTL doesn't match the prescribed value then they expire the TTL to drop the packet in the fast path.

The box on the other side in this particular instance is a high end Foundry.

I don't really care about the 192 thing because I will never have mutlihop peers that far away - it was simply an observation.

Well, that's quite a coincidence because Foundry's default IP TTL value is 64, which is quit suspicious.

The problem is needing to configure both sides of the peering and consequently on a per session basis / cordinatition which means a lot of work and inertia of organising other people to roll out the change.

Hrmm... On other thought.. Is the Foundry a multi-hop peer? If so, perhaps in their configuration they're specifying ebgp multli-hop 1, which is triggering this behavior? But I'd suspect the above rather than this, because of the 192 behavior. Thoughts? -danny