Hello,
I am not sure regarding method 2, would appreciate it if someone can correct
me.
However as per Cisco Doc in the reference below:
BGP ttll-security hops
This feature should be configured on each participating router. It secures
the BGP session in the incoming direction only and has no effect on outgoing
IP packets or the remote router.
This shows that this feature is only meant to protect against forged IP
addresses, and works by comparing the TTL of an incoming packet against a
configured TTL,
http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_n1gt.html#wp1100096
Method 2:
Router bgp 100
neighbor 2.2.2.2 update-source Loopback0
neighbor 2.2.2.2 ttl-security hops (+ mandatory hop count)
HTH,
Regards,
On Fri, Aug 20, 2010 at 7:30 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
> Jack, inside comments:
>
> Jack Router @ 20/8/2010 1:24 -0300 dixit:
>
> Hello,
>>
>> After labing a bit with EBGP neighbors using loopback interfaces I have
>> some
>> observations. Perhaps someone can clarify if I am correct:
>>
>> R1-------------------R2
>> AS 100 AS 200 L0: 1.1.1.1 L0: 2.2.2.2
>>
>> The task is to establish neighborships between R1 and R2 using L0
>> interfaces.
>>
>> I think that three methods are possible.
>> Following examples show R1 configurations, R2 has reverse configuration:
>> Method 1:
>> Router bgp 100
>> neighbor 2.2.2.2 update-source Loopback0
>> neighbor 2.2.2.2 ebgp-multihop (+ optional hop count, default is 255)
>>
>
> Old way, send with ttl greater than 1.
>
>
>
>> Method 2:
>> Router bgp 100
>> neighbor 2.2.2.2 update-source Loopback0
>> neighbor 2.2.2.2 ttl-security hops (+ mandatory hop count)
>>
>
> New security mode, to discard attacks that come from far away,
> if the TTL is not enough.
> The difference lies in the added security against DOS attacks,
> because it will not reach the BGP code.
>
>
>
>> Method 3:
>> Router bgp 100
>> neighbor 2.2.2.2 update-source Loopback0
>> neighbor 2.2.2.2 disable connected check
>>
>
> Easy hack, implied by 1 or 2, just for 1 hop but originated by
> a different interface than the connected one.
>
>
>
>> My understanding is that all methods will play with TTL of packets sent
>> from
>> one neighbor to another thus allowing packets to reach defined neighbor.
>> In
>> that sense method 1 and 2 are identical as TTL can be defined.
>> Method 3 is a bit different as it will set TTL to 255 and there is no way
>> to
>> change it.
>>
>> Am I right ?
>>
> I would expect that method 3 does not mess with TTL at all.
> But have not tested it, would you ?
> -Carlos
>
>
>
>> Thanks,
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- KJ Blogs and organic groups at http://www.ccie.netReceived on Fri Aug 20 2010 - 20:00:59 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:52 ART