Had this before, just to add to Marko's comments I had to configure the
following for this to work:
tcp-map BGP-MD5
tcp-options range 19 19 allow
class-map BGP-MD5
match port tcp eq 179
policy-map global_policy
class BGP-MD5
set connection advanced-options BGP-MD5
set connection random-sequence-number disable
--
BR
Tony
Sent from my iPad
> On 27 Feb 2014, at 14:00, "Ryanlk18 ." <[email protected]> wrote:
>
> 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
_______________________________________________
Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::
iPexpert on YouTube: www.youtube.com/ipexpertinc
