IBGP vs EBGP = confused
Thomas Kuborn
I thought IBGP peers never passed prefixes over an IBGP session. However I
found out this :
If 2 neighbors only have an IBGP session between them, they wont pass
prefixes (show ip bgp)
If 2 neighbors have an IBGP session between them & if one of the neighbor
has a EBGP session to another neighbor they will pass prefixes over the IBGP
session (show ip bgp)
If 2 neighbors have an EBGP session between them, they will pass prefixes
(show ip bgp)
Did I do something wrong or this is how it is supposed to work ?
Here's the lab output
cisco-2501A#sh ip bgp sum
BGP router identifier 192.168.254.1, local AS number 65531
BGP table version is 7, main routing table version 7
5 network entries and 8 paths using 773 bytes of memory
6 BGP path attribute entries using 360 bytes of memory
3 BGP AS-PATH entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP activity 5/151 prefixes, 8/0 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
192.168.0.203 4 65531 43 45 7 0 0 00:40:51 0
192.168.0.214 4 65531 46 45 7 0 0 00:41:00 4
192.168.0.253 4 65533 35 36 7 0 0 00:29:22 3
cisco-2501A#sh ip bgp nei 192.168.0.203 routes
Total number of prefixes 0
cisco-2501A#sh ip bgp nei 192.168.0.214 routes
BGP table version is 7, local router ID is 192.168.254.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* i10.0.0.0 192.168.0.253 0 100 0 65533 i
* i20.0.0.0 192.168.0.253 0 100 0 65533 i
*>i172.16.0.0 192.168.0.252 0 100 0 65532 i
* i198.200.10.0 192.168.0.214 0 100 0 i
Total number of prefixes 4
cisco-2501A#sh ip bgp nei 192.168.0.253 routes
BGP table version is 7, local router ID is 192.168.254.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 192.168.0.253 0 0 65533 i
*> 20.0.0.0 192.168.0.253 0 0 65533 i
* 172.16.0.0 192.168.0.253 0 65533 65532 i
Total number of prefixes 3
Thomas
Piotr Marecki
It's actually how it works.Rule states that IBGP speaker can't advertise
route that it has learned from
IBGP neighbor to another IBGP neigbors.It doesn't prohibite from advertising
route learned
from EBGP neighbor to IBGP neighbor.So BGP speaker that peers with peer
outside your AS simply
reflect that route to all of it EBGP and IBGP neighbors(in some
implementations even to peer that it
learned route from) - of course with some attributes updated(AS-PATH and
NEXT-HOP for example).
If it doesn't work like that , lets' assume n BGP speakers within AS and m
BGP speakers outside AS that
will provide EBGP sessions.You will end with m * n ebgp sessions (most of
them multihop) . What a mess :)
Piotr Marecki
"Thomas Kuborn" <thomas...@softhome.net> wrote in message
news:3dbad439$0$5994$ba62...@news.skynet.be...
CCIE 8122
>
> I thought IBGP peers never passed prefixes over an IBGP session. However I
> found out this :
Actually, they never pass prefixes learned from another iBGP peer over
an iBGP session (the exception is when you configure route reflectors).
They WILL pass locally originated iBGP prefixes as well as eBGP prefixes.
> If 2 neighbors only have an IBGP session between them, they wont pass
> prefixes (show ip bgp)
Again, they wont pass iBGP prefixes not originated by themselves.
> If 2 neighbors have an IBGP session between them & if one of the neighbor
> has a EBGP session to another neighbor they will pass prefixes over the IBGP
> session (show ip bgp)
But only eBGP prefixes and locally originated iBGP prefixes.
> If 2 neighbors have an EBGP session between them, they will pass prefixes
> (show ip bgp)
Subject to any filters, of course.
> Did I do something wrong or this is how it is supposed to work ?
>
> Here's the lab output
Cant tell without the configs. But the rule of thumb is that you have
to fully mesh iBGP peers (or configure route reflectors/confederations),
i.e., each iBGP router has to have an iBGP session with each and every
iBGP router on the network.
kr
Thomas Kuborn
Just one question & one request left ....
- with locally originated, I guess you mean via the network statement ?
I came up with this summary ... What do you think ?
Basic rule :
eBGP passes any prefixes (subject to filters)
iBGP is more selective
1. BGP-A <-- iBGP --> BGP-B : the BGP speakers only have an iBGP
connection between them
In that situation, the iBGP peers will :
- pass locally originated prefixes via their iBGP connection (network
statement)
- not pass iBGP prefixes that were not originated locally.
2. BGP-A <-- iBGP --> BGP-B <-- eBGP --> BGP-C : the BGP speakers only
have an iBGP connection between them but one of the 2 speaker also has
an additional eBGP connection.
In that situation, the iBGP peers will :
- pass locally originated prefixes via their iBGP connection (network
statement)
- not pass iBGP prefixes that were not originated locally.
- pass all (subject to filters) eBGP prefixes learnt from another peer :
BGP-B will pass eBGP prefixes learnt from BGP-C to BGP-A
In that situation, the eBGP peers will :
- pass the whole BGP table (suject to filters)
RULE :
iBGP speakers must be fully-meshed : every iBGP speaker must have a
connection to every other iBGP speaker. This rule must be enforced since
iBGP peers do not pass prefixes not-originated locally. If this rule is
not respected, the iBGP speakers that are not fully-meshed will lack
some iBGP prefixes.
Exception to this rule : route reflector / confederation
Synchronization :
Before prefixes received over an iBGP connection are advertised over an
eBGP connection by an eBGP speaker, the eBGP speaker verifies that :
- it has an IGP route to the next-hop in its routing table
- it has the same prefix in its IGP routing table
Therefore, synchronization is an eBGP thing. iBGP speakers don't care
about synchronization.
If iBGP speakers are fully-meshed, synchronization can be safely disabled
Thx again for the help
Thomas
CCIE 8122
> Just one question & one request left ....
> - with locally originated, I guess you mean via the network statement ?
Not just. Locally originated = a) network statement or b)
redistribution from another protocol on this router.
(and I believe that is it -- correct me anyone if I have spaced anything
out here re another source of originating a BGP route)
> I came up with this summary ... What do you think ?
>
> Basic rule :
> eBGP passes any prefixes (subject to filters)
> iBGP is more selective
>
> 1. BGP-A <-- iBGP --> BGP-B : the BGP speakers only have an iBGP
> connection between them
> In that situation, the iBGP peers will :
> - pass locally originated prefixes via their iBGP connection (network
> statement)
> - not pass iBGP prefixes that were not originated locally.
Yep
> 2. BGP-A <-- iBGP --> BGP-B <-- eBGP --> BGP-C : the BGP speakers only
> have an iBGP connection between them but one of the 2 speaker also has
> an additional eBGP connection.
> In that situation, the iBGP peers will :
> - pass locally originated prefixes via their iBGP connection (network
> statement)
> - not pass iBGP prefixes that were not originated locally.
> - pass all (subject to filters) eBGP prefixes learnt from another peer :
> BGP-B will pass eBGP prefixes learnt from BGP-C to BGP-A
Right again
> In that situation, the eBGP peers will :
> - pass the whole BGP table (suject to filters)
>
> RULE :
> iBGP speakers must be fully-meshed : every iBGP speaker must have a
> connection to every other iBGP speaker. This rule must be enforced since
> iBGP peers do not pass prefixes not-originated locally. If this rule is
> not respected, the iBGP speakers that are not fully-meshed will lack
> some iBGP prefixes.
> Exception to this rule : route reflector / confederation
Yes. And this is critical for BGP to work properly (as I can see you
have deduced).
> Synchronization :
> Before prefixes received over an iBGP connection are advertised over an
> eBGP connection by an eBGP speaker, the eBGP speaker verifies that :
> - it has an IGP route to the next-hop in its routing table
> - it has the same prefix in its IGP routing table
> Therefore, synchronization is an eBGP thing. iBGP speakers don't care
> about synchronization.
Correct.
> If iBGP speakers are fully-meshed, synchronization can be safely disabled
No.
iBGP speakers ALWAYS must be fully meshed, no matter what.
Route-reflectors / confederations may be considered to meet the "fully
meshed" requirement, because they both allow iBGP peers to advertise on
behalf of another, and therefore make clients, other confederations
"think" they are peered with every speaker.
Off the top of my head, I can think of four reasons to disable
synchronization: 1) to prevent dampening of routes due to internal
route-flapping, 2) when you are a non-transit network (more on this
below), 3) when all your routers speak BGP, 4) faster BGP convergence
(but beware black hole routing).
Reason #1 is a not the greatest reason to do so, unless you have an
unstable network and for some reason are not aggregating routes in your
eBGP advertisements, but you dont want the flap of a route to be visible
outside. The reason I say this is not a great reason, is you should
investigate and solve the instability, as opposed to masking it w/ BGP.
You would want to enable synchro if you are an ISP. The reason is that
your non-BGP customers will look to the Internet like YOUR network, and
if their access-link to you is down (and say they are dual-homed), you
dont want to be advertising their prefix out since they will want all
traffic to come through the other provider.
You would also enable synchro to prevent black hole routing.
I am sure their are other reasons for both, but none come to mind at the
moment.
> Thx again for the help
>
> Thomas
No problem. Good luck.
kr
Thomas Kuborn
Thomas
"CCIE 8122" <no...@none.com> wrote in message
news:3DBE3D25...@none.com...
Barry Margolin
>You would want to enable synchro if you are an ISP. The reason is that
>your non-BGP customers will look to the Internet like YOUR network, and
>if their access-link to you is down (and say they are dual-homed), you
>dont want to be advertising their prefix out since they will want all
>traffic to come through the other provider.
You don't need synchronization for this. If their link goes down, the
route that points to the link will go away, so it will not be redistributed
into BGP in the first place.
Our customer routes are redistributed *only* into BGP, not OSPF, so we have
to disable synchronization.
Also, dual-homed customers *should* be using BGP, so the scenario you
describe shouldn't even come up. It should not normally be the case that
the same route is being advertised on the Internet with different origin
ASNs (we'll occasionally do it when a customer is switching from one ISP to
another).
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
CCIE 8122
>>your non-BGP customers will look to the Internet like YOUR network, and
>>if their access-link to you is down (and say they are dual-homed), you
>>dont want to be advertising their prefix out since they will want all
>>traffic to come through the other provider.
>
>
> You don't need synchronization for this. If their link goes down, the
> route that points to the link will go away, so it will not be redistributed
> into BGP in the first place.
Youre right. It was late. :)
> Our customer routes are redistributed *only* into BGP, not OSPF, so we have
> to disable synchronization.
>
> Also, dual-homed customers *should* be using BGP, so the scenario you
> describe shouldn't even come up. It should not normally be the case that
> the same route is being advertised on the Internet with different origin
> ASNs (we'll occasionally do it when a customer is switching from one ISP to
> another).
I agree they SHOULD, but they dont always DO. And many ISPs will
accommodate this.
kr