It i just a TTL-security "trick."
When you configure TTL-Security you tell the router to do 2 things:
1) Set the outbound BGP packets with a TTL of 255
2) Only except packets with a TTL greater than 253
Here is an abbreviated packet capture between R1 and R2 using the loopback
addresses for eBGP peering.
The neighbor TTL security is set to hops 2.
*************************
Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)
Time to live: 255
Protocol: TCP (0x06)
Source port: bgp (179)
*************************
If I remove the TTL-Security and use "disable-connected-check" on both
routers...still using loopbacks as peer:
If you use disable-connected-check, you tell the router 2 things:
1) Leave the TTL 1
2) If i receive a BGP packet with a TTL of anything including 0, accept the
packet
*************************
Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)
Time to live: 1
Protocol: TCP (0x06)
Source port: bgp (179)
*************************
Chris
On Fri, Aug 20, 2010 at 2:33 PM, karim jamali <karim.jamali_at_gmail.com>wrote:
> Hi Jack,
>
> Honestly I am not sure..Can you test with both ttl-security without any
> ebgp
> multihop,since your case might be the on one side you configured EBGP
> multhop that's why one router can reach the other, the other is accepting
> its packet after checking the TTL of incoming packet with configure ttl. I
> believe with both sides only configured with ttl-security it won't work,
> due
> to if doc is correct "that the feature doesn't affect outgoing packets"
>
> Best Regards,
>
> On Fri, Aug 20, 2010 at 9:48 PM, Jack Router <pan.router_at_gmail.com> wrote:
>
> > Karim,
> >
> > I am always confused when documentation says that something "should" be
> > configured. In this case it certainly "does not have to" be configured on
> > every router in order for EBGP routers to establish neighborships.
> > Ttl-security on one and + ebgp-multihop on another will work. I just
> labbed
> > this:
> >
> > #################################
> > ROUTER 1:
> >
> > R1#sh run | s router bgp
> > router bgp 100
> > no synchronization
> > bgp log-neighbor-changes
> > neighbor 2.2.2.2 remote-as 200
> > neighbor 2.2.2.2 ttl-security hops 2 <<<<<<<<<<<<<
> > neighbor 2.2.2.2 update-source Loopback0
> > no auto-summary
> >
> > R1#sh ip bgp summary
> > BGP router identifier 1.1.1.1, local AS number 100
> > BGP table version is 1, main routing table version 1
> >
> > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> > State/PfxRcd
> > 2.2.2.2 4 200 44 45 1 0 0 00:13:21
> > 0
> >
> > #################################
> > ROUTER 2:
> >
> > R2#sh run | s router bgp
> > router bgp 200
> > no synchronization
> > bgp log-neighbor-changes
> > neighbor 1.1.1.1 remote-as 100
> > neighbor 1.1.1.1 ebgp-multihop 255 <<<<<<<<<<<<<<<<<
> > neighbor 1.1.1.1 update-source Loopback0
> > no auto-summary
> >
> > R2#sh ip bgp summ
> > R2#sh ip bgp summary
> > BGP router identifier 2.2.2.2, local AS number 200
> > BGP table version is 1, main routing table version 1
> >
> > Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> > State/PfxRcd
> > 1.1.1.1 4 100 44 45 1 0 0 00:13:59
> > 0
> >
> > #################################
> >
> > I will continue testing tonight :)
> >
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> > karim jamali
> > Sent: 20-Aug-10 13:01
> > To: Carlos G Mendioroz; Cisco certification
> > Subject: Re: EBGP and multihops
> >
> > 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_n1g
> > t.html#wp1100096<
> http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_n1g%0At.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.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> KJ
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Fri Aug 20 2010 - 16:09:19 ART
This archive was generated by hypermail 2.2.0 : Wed Sep 01 2010 - 11:20:52 ART