Re: BGP peculiarity

Hello,

I'm sorry but I don't see what's the problem here:

1st you check what you advertise from R2 to R6
-> Rack1R2#sh ip bgp neighbors 141.1.36.6 advertised-routes
This is normal

2nd you check what you received from R2 on R6
-> Rack1R6#*sh ip bgp neighbors 141.1.123.2 received-routes
Also normal

3rd you check what you advertise from R6 to R2
-> Rack1R6#*sh ip bgp neighbors 141.1.123.2 advertised-routes
Looks also OK to me, as R6 will advertise the learned networks to all of its e-BGP neighbors.

Where the loop avoidance comes into play, is on R2, as it see that some prefixes coming from R6 are having its (R2) ASN in path, so those prefixes will no be added to BGP table.

Do I miss something here?

Calin

> ----- Original Message -----
> From: Amit Kumar Lohumi
> Sent: 09/16/11 08:13 PM
> To: garry baker
> Subject: 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,
> B r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> B 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 ?*
>
>
> B *BGP Routes received by R6 from R2 :*
>
> B 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,
> B r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
> B 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,
> B r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
> B 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
> >> >>
> >> >>
> _______________________________________________________________________
> >> >> Subscription information may be found at:
> >> >> http://www.groupstudy.com/list/CCIELab.html
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Narbik Kocharians
> >> > CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> >> > www.MicronicsTraining.com
> >> > Sr. Technical Instructor
> >> > YES! We take Cisco Learning Credits!
> >> > Training & Remote Racks available
> >>
> >>
> >> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Sep 19 2011 - 05:42:17 ART