Re: BGP peculiarity

Of the routes your advertising only 3 prefixes are getting sent back:

**>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 ?*

Also only 3 are received by R6 from R2

How are you getting these into your RIB? I see a filter-list on R6, but I
see no network statements. Is R2 originating these routes? Note your Path,
it's ?

Origin is lost. Looks like redistribution or non-origination. Post a show ip
bgp for both routers. This may be normal behavior.

On Fri, Sep 16, 2011 at 2:13 PM, Amit Kumar Lohumi <getakl_at_gmail.com> wrote:

> 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
> >> >>
> >> >>
> _______________________________________________________________________
> >> >> 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 Sun Sep 18 2011 - 09:25:14 ART