Some food for thought, I would avoid TTL security unless specifically asked to use it (or in cisco's round about way of asking to use it). If you are asked to "Secure your BGP Session" then just use authentication. TTL security is pretty straight forward, but requires you to know the exact hop count of the underlying IGP to your destination. If you are off by 1, then no dice.
In the lab, probably not a big deal. In the real world, it can sometimes be a bit more tricky. One other thing about BGP authentication, in case anyone is interested. I was having a problem with BGP authentication going through an ASA. Although the ASA was configured to allow all traffic through, when I enabled authentication, BGP would drop. The debug told me the problem was with the password. After a little goole'ing, I found that the ASA was changing the MD5 on the authentication packets, causing my authentication to fail. To fix this you have to go in and tell the ASA to leave the BGP authentication packets alone. Here is a good article describing how to set it up. https://supportforums.cisco.com/docs/DOC-21347 V/r, Ryan Krcelic On Thu, Feb 27, 2014 at 8:51 AM, Christopher Lemish < [email protected]> wrote: > Thanks guys! > > Thank you, > Chris > > > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Bob McCouch > Sent: Wednesday, February 26, 2014 7:36 PM > To: Marko Milivojevic > Cc: OSL CCIE ([email protected]) > Subject: Re: [OSL | CCIE_RS] BGP: TTL Security > > I think the issue is exactly what Marko mentions in #1 & 2: > > 1) The TTL is set to 255, instead of 1 (default) > 2) TTL security feature needs to be turned on on both sides > > If you were to only enable TTL security on one side, it would need "hops > 254" because the other EBGP peer will send its packets with TTL 1, the > default for EBGP sessions. You need to enable it on both sides for it to > work correctly by setting the TTL to 255 and then subtracting only the > expected number of hops. After all, spoofing a packet that lands on your > router with a TTL 1 is not too hard. But spoofing a packet that lands on > your router with a TTL of 254 would be quite a feat if you're not on the > same wire. > > Best, > Bob > CCIE #38296 > HerdingPackets.net > > > On Wed, Feb 26, 2014 at 3:41 PM, Marko Milivojevic <[email protected] > >wrote: > > > I can confirm (and so can you in the lab environment). > > > > When configured with the ttl-security, several things are important > > for the eBGP neighbors: > > > > 1) The TTL is set to 255, instead of 1 (default) > > 2) TTL security feature needs to be turned on on both sides > > 3) TTL of the incoming packet will be matched against the configured > > hop count using a simple check: (255-Packet_TTL) <= hops > > > > Let's take a look. > > > > (AS65001)R1[Gi1]---{192.168.12.0/24}---[Gi1]R2(AS65002) > > > > > > R1: > > interface GigabitEthernet1 > > ip address 192.168.12.1 255.255.255.0 ! > > router bgp 65001 > > neighbor 192.168.12.2 remote-as 65002 neighbor 192.168.12.2 > > ttl-security hops 2 ! > > address-family ipv4 > > neighbor 192.168.12.2 activate > > ! > > > > R2: > > interface GigabitEthernet1 > > ip address 192.168.12.2 255.255.255.0 ! > > router bgp 65001 > > neighbor 192.168.12.1 remote-as 65001 neighbor 192.168.12.1 > > ttl-security hops 2 ! > > address-family ipv4 > > neighbor 192.168.12.1 activate > > ! > > > > R1: > > R1#show bgp ipv4 unicast summary > > BGP router identifier 192.168.12.1, local AS number 65001 BGP table > > version is 1, main routing table version 1 > > > > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > > State/PfxRcd > > 192.168.12.2 4 65002 7 7 1 0 0 > 00:04:15 > > 0 > > > > So, the session is up, even though they're directly connected (proving > > the point of the TTL statement above). But what WAS the actual TTL > > used on the wire? See for yourself - this is the SYN packet for that > session. > > > > Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) > > Ethernet II, Src: 00:0c:29:84:d3:2e (00:0c:29:84:d3:2e), Dst: > > 00:50:56:92:37:3d (00:50:56:92:37:3d) > > Internet Protocol Version 4, Src: 192.168.12.1 (192.168.12.1), Dst: > > 192.168.12.2 (192.168.12.2) > > Version: 4 > > Header length: 20 bytes > > Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; > ECN: > > 0x00: Not-ECT (Not ECN-Capable Transport)) > > Total Length: 44 > > Identification: 0xa870 (43120) > > Flags: 0x02 (Don't Fragment) > > Fragment offset: 0 > > Time to live: 255 > > Protocol: TCP (6) > > Header checksum: 0x3947 [correct] > > Source: 192.168.12.1 (192.168.12.1) > > Destination: 192.168.12.2 (192.168.12.2) Transmission Control > > Protocol, Src Port: 51300 (51300), Dst Port: bgp (179), Seq: 0, Len: 0 > > > > -- > > Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor / > > Managing Partner - iPexpert > > :: Free Video Training: http://youtube.com/iPexpertInc > > :: Social: http://twitter.com/@icemarkom | http://fb.me/ccie18427 > > :: iPexpert: http://www.ipexpert.com/Communities | +1-810-326-1444 > > > > > > > > On Wed, Feb 26, 2014 at 12:19 PM, Edgar Díaz Orellana < > > [email protected]> wrote: > > > > > In fact using an loopback interface is kind of had a second hop, 1 > > > of > > them > > > is external the other is internal thru control-plane. > > > > > > That's why need to use 2 hops if you had neighbors peering thru > > > loopbacks > > > > > > Sent from my iPhone > > > > > > > On 26-02-2014, at 14:09, marc abel <[email protected]> wrote: > > > > > > > > Are you peering between loopbacks? In this case you would need to > > > > do ttl-security hops 2. Your neighbor is going to decrement 1 ttl > > > > before sending and then local router would decrement 1 before > > > > delivering to loopback interface. This probably wouldn't show up > > > > in your traceroute, > > > but > > > > you would have a ttl of 253. > > > > > > > > > > > > On Wed, Feb 26, 2014 at 10:22 AM, Christopher Lemish < > > > > [email protected]> wrote: > > > > > > > >> Guys, > > > >> > > > >> I just turned up a BGP session for a customer (doing BGP Failover > > > >> for them). I am using the "neigh ttl-security hops" cmd. A > > > >> traceroute confirms it is 1 hop away. The Cisco documentation > > > >> explains that if a > > > TTL > > > >> is received that equals the TTL value expected or is higher, the > > router > > > >> will accept that packet. > > > >> > > > >> I was troubleshooting it quickly and the cmd "neigh x.x.x.x > > ttl-security > > > >> hops 254" is the only hop count that maintains the BGP session. > > > >> I > > > thought > > > >> I recall that the ttl-security cmd "must exactly" match the > > > >> number of > > > hops > > > >> away from one of Joe's videos. But, I thought we could use the > > > >> "neigh x.x.x.x ttl-security hops 1" which means it is 1 hop away > > > >> and would > > > accept > > > >> a TTL of 254 or higher, indicating that it is 1 hop away. > > > >> > > > >> (TTL=255)-->(TTL=254) > > > >> PE--------CE > > > >> > > > >> The IOS version of this 3925 is the following: > > > >> Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version > > > >> 15.2(4)M5, RELEASE SOFTWARE (fc2) > > > >> > > > >> Thank you, > > > >> Chris > > > >> > > > >> _______________________________________________ > > > >> Free CCIE R&S, Collaboration, Data Center, Wireless & Security > > > >> Videos > > :: > > > >> > > > >> iPexpert on YouTube: www.youtube.com/ipexpertinc > > > > > > > > > > > > > > > > -- > > > > Marc Abel > > > > CCIE #35470 > > > > (Routing and Switching) > > > > _______________________________________________ > > > > Free CCIE R&S, Collaboration, Data Center, Wireless & Security > > > > Videos > > :: > > > > > > > > iPexpert on YouTube: www.youtube.com/ipexpertinc > > > _______________________________________________ > > > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos > :: > > > > > > iPexpert on YouTube: www.youtube.com/ipexpertinc > > > > > _______________________________________________ > > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > > > iPexpert on YouTube: www.youtube.com/ipexpertinc > > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc > _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
