Hello Charles, The TTL security check has effect only on incoming direction
If you check the output of the cmd: sh ip b nei x.x.x.x | i TTL You'll see: Mininum incoming TTL 254, Outgoing TTL 255 So if the TTL of the hello sent to you by your upstream is less than the minimum incoming value +1 than your router will drop it silently By default eBGP session sends messages with TTL=1 Thus your upstream would have to enable this as well adam -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Charles Sprickman Sent: Wednesday, June 27, 2012 11:55 AM To: [email protected] Subject: [c-nsp] ttl-security issues So I was reading the fine "Secure BGP Template" over at Cymru, and started looking at the "neighbor x.x.x.x ttl-security hops y" setting which I had not seen before. My understanding after looking at the cisco docs was that you determined how many hops away your peers were, then you enable the setting based on the number of hops. For example, a directly connected bgp peer would be: neighbor x.x.x.x ttl-security hops 1 A multihop neighbor that's three hops away would be: neighbor x.x.x.x ttl-security hops 3 I have nothing tricky going on here - two upstream neighbors each directly connected. I enabled this on one and about a minute later the bgp session dropped. The drop was logged, but there was nothing in the log stating that the ttl-security mechanism was what dropped it. I removed the ttl-security statement, session came back up. Tried with a hop count of 2 just for giggles, session drops, and again nothing in the log regarding the ttl-security mechanism. It's late at night, so I try with the other neighbor. Same thing. Am I missing something obvious here? Is there anything other than multi-hop config that interferes with this feature? Thanks, Charles ps - what are some good references these days for overall cisco best practices in an ISP environment? I've not had to do much beyond maintenance in quite some time and most of what I know dates to the era when cisco brought out the service provider train, the 2501 was a totally reasonable CPE, and NANOG was readable. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
