Re: BGP peculiarity

This example is from CCIE Routing & Switching, Dynamips Lab
Workbook(IEWB-RS-DYN), Version 4.1 Lab 4

R2 ( AS 200 ) and R6 ( AS 100 ) are e-BGP peers not directly connected.

*R2's BGP config :*

Rack1R2#sh run | sec router bgp 200
router bgp 200
no synchronization
bgp log-neighbor-changes
bgp redistribute-internal
neighbor 141.1.0.5 remote-as 300
neighbor 141.1.36.6 remote-as 100 *(R6)*
neighbor 141.1.36.6 ebgp-multihop 255
neighbor 141.1.36.6 soft-reconfiguration inbound
neighbor 141.1.123.1 remote-as 200
no auto-summary

*R6's BGP config :*

Rack1R6#sh run | sec router bgp 100
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 54.1.1.254 remote-as 54
neighbor 141.1.123.2 remote-as 200 *(R2)*
neighbor 141.1.123.2 ebgp-multihop 255
neighbor 141.1.123.2 soft-reconfiguration inbound
neighbor 141.1.123.2 filter-list 1 out
no auto-summary

*BGP routes advertised by R2 to R6 :*

Rack1R2#sh ip bgp neighbors 141.1.36.6 advertised-routes
BGP table version is 74, local router ID is 150.1.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
             r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network Next Hop Metric LocPrf Weight Path
*> 114.0.0.0 141.1.36.6 0 100 54 i
*> 115.0.0.0 141.1.36.6 0 100 54 i
*> 116.0.0.0 141.1.36.6 0 100 54 i
*> 117.0.0.0 141.1.36.6 0 100 54 i
*> 118.0.0.0 141.1.36.6 0 100 54 i
*> 119.0.0.0 141.1.36.6 0 100 54 i
**>i205.90.31.0 192.10.1.254 0 100 0 254 ?*
**>i220.20.3.0 192.10.1.254 0 100 0 254 ?*
**>i222.22.2.0 192.10.1.254 0 100 0 254 ?*

 *BGP Routes received by R6 from R2 :*

 Rack1R6#*sh ip bgp neighbors 141.1.123.2 received-routes
*BGP table version is 56, local router ID is 150.1.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network Next Hop Metric LocPrf Weight Path
*> 205.90.31.0 141.1.123.2 0 200 254 ?
*> 220.20.3.0 141.1.123.2 0 200 254 ?
*> 222.22.2.0 141.1.123.2 0 200 254 ?

*BGP routes advertised by R6 to R2 :*

Rack1R6#*sh ip bgp neighbors 141.1.123.2 advertised-routes
*BGP table version is 62, local router ID is 150.1.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network Next Hop Metric LocPrf Weight Path
*> 112.0.0.0 54.1.1.254 0 0 54 50 60 i
*> 113.0.0.0 54.1.1.254 0 0 54 50 60 i
*> 114.0.0.0 54.1.1.254 0 0 54 i
*> 115.0.0.0 54.1.1.254 0 0 54 i
*> 116.0.0.0 54.1.1.254 0 0 54 i
*> 117.0.0.0 54.1.1.254 0 0 54 i
*> 118.0.0.0 54.1.1.254 0 0 54 i
*> 119.0.0.0 54.1.1.254 0 0 54 i
**> 205.90.31.0 141.1.123.2 0 200 254 ?
*> 220.20.3.0 141.1.123.2 0 200 254 ?
*> 222.22.2.0 141.1.123.2 0 200 254 ?*

**
*Here, we can see that R6 is advertising back the same routes that it
learned from R2, back to R2.*
**
Regards,
Amit
* *
*

*
On Fri, Sep 16, 2011 at 8:17 PM, garry baker <baker.garry_at_gmail.com> wrote:
> can you show an example config, with some debugs, to show your issue?
>
> --
> Garry L. Baker
>
> "With sufficient thrust, pigs fly just fine..." - RFC 1925
>
>
> On Fri, Sep 16, 2011 at 5:20 PM, Amit Kumar Lohumi <getakl_at_gmail.com>
wrote:
>>
>> That is all well ..
>>
>> My query is regarding the inconsistent behaviour of BGP, irrespective
>> of "AS-OVERRIDE" or "ALLOWAS-IN" commands being used.
>>
>> In some cases, it is observed that BGP follows its standard rule for
>> route updates and does not advertise routes learned from an e-BGP peer
>> back to the same neighbor.
>>
>> But in some other cases, i have observed that BGP does actually
>> advertise routes back to an e-BGP peer from which they were learnt in
>> the first place. Why this dichotomy ?
>>
>> It is a different matter that the BGP AS originating those routes will
>> reject them if they are advertised back to it because it will see its
>> own AS # in the AS-Path. That part is understood. My query is
>> regarding the BGP policy for the routes which will not be included in
>> updates to e-BGP peers. As i understand, BGP should not advertise to
>> an e-BGP peer those routes for which the AS-path contains AS# of that
>> peer. But i have seen his rule violated in some scenarios. Why is that
>> ?
>>
>> Regards,
>> Amit
>>
>> On Fri, Sep 16, 2011 at 6:24 PM, Narbik Kocharians <narbikk_at_gmail.com>
>> wrote:
>> > Amit,
>> > When an e-bgp neighbor advertises a prefix to you, it will prepend its
>> > AS
>> > number, and if you ever advertise it back to him, he will see his AS
>> > number
>> > in the update and reject the route. Unless you have "AS-OVERRIDE" or he
>> > has
>> > "ALLOWAS-IN".
>> >
>> > On Fri, Sep 16, 2011 at 5:09 AM, Amit Kumar Lohumi <getakl_at_gmail.com>
>> > wrote:
>> >>
>> >> Hi All,
>> >>
>> >> Can anyone pls explain ....
>> >>
>> >> why is it that in some cases a BGP router would not advertise e-BGP
>> >> routes learned from a peer back to the same peer (sticking to the
>> >> standard rule on BGP updates).
>> >>
>> >> ... while in other cases, BGP will infact advertise the e-BGP routes
>> >> learned from a peer back to the same peer (although they do get
>> >> rejected by the originating peer because of ASN match ).
>> >>
>> >> I have made these dichotomous BGP observations on a couple of
>> >> different scenarios.
>> >>
>> >> Regards
>> >>
>> >>
>> >> Blogs and organic groups at http://www.ccie.net
>> >>
>> >>
Received on Fri Sep 16 2011 - 23:43:44 ART