Re: BGP peculiarity

I've seen different scenarios based on what you have described.
For example, IOS XR does not send the routes, while IOS does. And it does
depend on the version you're running.
Both methods can withstand the scrutiny under RFC. Sometimes the routes are
sent because the update group is easier to build that way (e.g. have one
update group for 10 neighbors, with some useless routes is more efficient,
than have precise update set pre neighbor, but use more update groups (which
eats up CPU)).
Also, there are commands avaiable to steer the behaviour in the way you need
to. E.g. make IOS XR send the route anyway, even though normally it wouldn't
send it.

On Fri, Sep 16, 2011 at 2:09 PM, 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
>
>
>
>
>
>
>
>

-- 
Pavel Bykov
Blogs and organic groups at http://www.ccie.net