01-16-2012 03:03 PM
Dear friends,
I have been trying to get a good understanding of the BGP Site of Origin attribute (not the EIGRP SoO). I understand its idea and implications but there is an issue I could not wrap my head around yet.
Quoting from RFC 4364, Section 8:
We add one more restriction on the distribution of routes from PE to CE: if a route's Site of Origin attribute identifies a particular site, that route must never be redistributed to any CE at that site.
My understanding of this statement is that a site should be identifiable by a particular value of the SoO attribute, or in other words, there should be a way to assign a particular value of the SoO attribute to the entire site. Then, knowing the value of the SoO for the entire site, a route once originated at this site should never be advertised back to it.
This is where my troubles start. We know that there is not a strict one-to-one mapping between a site and a VRF. A site may consist of one or more VRFs and is not actually represented by a single object in the IOS - rather, it is just a collection of VRFs that share routing information in such a way that for mutual communication, the usage of the backbone is not required. There is no representation of the site as a single object in IOS and hence there is no way to assign a particular SoO to the site as a whole. Moreover, the SoO attribute is not even configured on a per-VRF basis, rather, it is pushed onto individual routes received from CE using either a route-map or a per-neighbor configuration. What is the SoO attribute on a particular prefix compared to, then? I simply do not see how an entire VRF or an entire site gets assigned its own unique SoO value for comparison purposes, in a way similar to assigning route distinguishers or route targets on a per-VRF basis.
So my question is: if the SoO attribute is pushed onto routes received from a CE and these routes are advertised to another PE at the same site, how does the another PE know the proper site-wide value of the SoO so that it can compare it to the SoO on received prefixed and not advertise the routes back to the site where they came from? Does the VRF simply "inherit" the SoO of the individual routes as they are received and processed by a route-map set-ting the SoO?
Any help and clarification is much appreciated!
Best regards,
Peter
Solved! Go to Solution.
01-17-2012 04:40 AM
Hi Peter,
SoO for BGP is "linked" to CE-neighbor. So, when a prefix needs to be advertised to a CE neighbor, we check the SoO of the prefix with the SoO of the BGP neighbor. For anything else, it is linked to interface.
The configuration can be done in four ways (the setting of the SoO and the check for the SoO is linked to that) :
1) "route-map in" on CE BGP neighbor command
2) directly on the CE BGP neighbor command
3) sitemap on VRF interface and redistribution of IGP (static) into BGP and IGP (static) routes point to this interface
4) sitemap on VRF interface and network command
General principle (but you know this):
Using a route-map and setting different SoO's for different prefixes coming from the same BGP neighbor does not make much sense, so I guess we were never bothered with the possible non-uniqueness in the configuration when looking at what a "site" is.
Thanks,
Luc
01-17-2012 04:40 AM
Hi Peter,
SoO for BGP is "linked" to CE-neighbor. So, when a prefix needs to be advertised to a CE neighbor, we check the SoO of the prefix with the SoO of the BGP neighbor. For anything else, it is linked to interface.
The configuration can be done in four ways (the setting of the SoO and the check for the SoO is linked to that) :
1) "route-map in" on CE BGP neighbor command
2) directly on the CE BGP neighbor command
3) sitemap on VRF interface and redistribution of IGP (static) into BGP and IGP (static) routes point to this interface
4) sitemap on VRF interface and network command
General principle (but you know this):
Using a route-map and setting different SoO's for different prefixes coming from the same BGP neighbor does not make much sense, so I guess we were never bothered with the possible non-uniqueness in the configuration when looking at what a "site" is.
Thanks,
Luc
01-17-2012 01:48 PM
Hello Luc,
Thank you very much for responding! I will need some time to digest all of this, and I may come up with additional questions. Naturally, what you say makes sense - I just need to put it into perspective in my head
Once again - thank you!
Best regards,
Peter
01-17-2012 01:27 PM
Hi Peter,
The BGP-SOO is a community attributes that assigned to prefixes recieved from the CE router by the PE in order to prevent those routes from being advertised to the same CE.
The BGP- SOO is a loop prevention mechanism for MULTIHOMED Site to the MPLS backbone, or for a sites that are single homed to the MPLS Backbone but share a backdoor link between them.
The answer to your question is straight forward, if the CE is dual homed to two different PE routers at the Same site, then the SOO community attribute has to be configured at both PEs connected to the Same CE, because as highlited, its configured per BGP neighbor.
In this case, the attribute is attached to the prefixes recieved by the CE on both PEs, and none of the PEs would send the route back to the same originating CE.
Let us know if this answered your question,
Regards,
Mohamed
01-17-2012 03:16 PM
Hi Mohamed,
Thanks so much for answering!
The answer to your question is straight forward, if the CE is dual homed to two different PE routers at the Same site, then the SOO community attribute has to be configured at both PEs connected to the Same CE, because as highlited, its configured per BGP neighbor.
This statement implicitly assumes that the site has a single CE and multiple PEs. In reality, the SoO is supposed to protect against routing loops even if the site has multiple distinct CEs and they are connected to multiple distinct PEs - do we both agree on this fact?
In this case, the attribute is attached to the prefixes recieved by the CE on both PEs, and none of the PEs would send the route back to the same originating CE.
This is what all books say - and precisely this is what I can not translate into a clear algorithmic description when visualizing this process as a sequence of exact steps.
Let's break it down:
Best regards,
Peter
01-17-2012 11:03 PM
Hello Peter,
It good to hear from you again.
Now, lets elaborate on the first part of your sentence. The BGP-SOO is a loop prevention mechanism for a single site that is dual homed to the MPLS Backbone ORR multiple CEs single homed but have a BACKDOOR link between them.
If you have multiple CEs connected to multiple PEs, and those CEs DONT have or SHARE a Backdoor link and any routing protocol on that link between them, there wouldnt be a routing loop, hence there is no need for BGP-SOO. I have elaborated on that on my first Post if you refer to it.
Now, let come to your questions:
(((
Now, think of a particular prefix X on PE2 that is received both from PE1 (preferred) and CE2.
Why exactly does not PE2 advertise X to CE2? Is it because prefix X from PE1 has the same SoO as prefix X from CE2?)))
Answer:
PE2 will simply not advertise the (X) prefix to CE2 because (CE2) has an SOO value assigned to that prefix when it was originally advertised by CE2. THE PE2 assign an SOO value to Prefix x when its recieved from CE2.
When PE2 recieves the Same Prefix from PE1 with similar SOO value that has been assigned from CE2 (on the link between CE2 and PE2), PE2 WILL NEVER advertise this Prefix Back to CE2 since it contains the SOO value which was already assigned to it. This is actually the NEED and IMPORTANCE of Assigning the Same SOO for Sites has multiple links to the MPLS Provider.
(((Furthermore, assume that CE1 advertises a prefix Y to PE1, however, because of some filtering policies, this prefix is not advertised from CE2 to PE2. Prefix Y including its SoO is subsequently advertised from PE1 to PE2. Now, this prefix should again not be advertised from PE2 to CE2.
However, how is PE2 going to know that?
The prefix Y on PE2 is learned only from PE1 and hence cannot be compared to any other prefix.
To what value should the SoO of the prefix Y be compared on PE2, then?)))
Answer:
Here Peter, if the prefix is not advertised by CE2 due to some filtering Policies, Its Obvious that PE2 will NEVER use CE2 as a transit or next-hop fortraffic any traffic destined to Prefix Y. The Routing Policies are always checked and triggered first. Why Do I need to forward Packet to a device that I have never learned any thing from in the first place?
Does That Make Sense to You,
Regards,
Mohamed
01-18-2012 03:37 AM
Hello Mohamed,
Thank you for responding.
Now, lets elaborate on the first part of your sentence. The BGP-SOO is a loop prevention mechanism for a single site that is dual homed to the MPLS Backbone ORR multiple CEs single homed but have a BACKDOOR link between them.
RFC 4364 does not specifically talk about "backdoors" with respect to SoO. However, within this context, we can safely assume that the two CEs from my previous example do have iBGP peering, or that they redistribute BGP into their internal IGP and vice versa. This can be considered a backdoor in my opinion.
PE2 will simply not advertise the (X) prefix to CE2 because (CE2) has an SOO value assigned to that prefix when it was originally advertised by CE2. THE PE2 assign an SOO value to Prefix x when its recieved from CE2.
When PE2 recieves the Same Prefix from PE1 with similar SOO value that has been assigned from CE2 (on the link between CE2 and PE2), PE2 WILL NEVER advertise this Prefix Back to CE2 since it contains the SOO value which was already assigned to it.
The ambiguosity of RFC 4364, and also of this explanation, is that it essentially talks about comparing the SoO value of the prefix to an identifier of the site itself - but it is not clear how should a site be assigned its identifier value. IOS configuration allows you to set SoO value only for prefixes, not for a site, neighbor or a VRF. Even if you configured the SoO value in BGP neighbor command, it was - strictly speaking - not a SoO value of the CE router, only a convenient way to assign the SoO extended community attribute to all routes received from that particular neighbor (similar to, say, per-neighbor weight configuration). That was my problem all along.
From Luc's explanation I now understand that when PE adds a particular SoO attribute to prefixes received from a CE, it also internally marks the CE with the same SoO value (presumably as an internal local variable associated with the particular CE). This is obviously done automatically, without any way to externally influence it. This truly per-neighbor value is then used when doing the SoO check to not re-inject routes into the same site where they came from.
Here Peter, if the prefix is not advertised by CE2 due to some filtering Policies, Its Obvious that PE2 will NEVER use CE2 as a transit or next-hop fortraffic any traffic destined to Prefix Y.
That is not my point. What can happen is a circular propagation of the prefix in the sequence CE1 -> PE1 -> PE2 -> CE2 -> internally within the site -> CE1, with the data traffic looping in the opposite direction, i.e. CE2 -> PE2 -> PE1 -> CE1 -> CE2.
You could argue that this scenario is too artificial. Perhaps so but not at all difficult or improbable to encounter especially within more complex prefix filtering scenarios. Also, it may cover various race condition scenarios where an identical set of prefixes is advertised from CE1 and CE2 to their respective PEs, but for whatever reasons, the prefix Y gets advertised and processed significantly sooner via the CE1 -> PE1 -> PE2 sequence of routers than it is received/processed between CE2/PE2. Luc's explanation seems to cover also this case: as a SoO value will be internally assigned to the CE2 thanks to the per-neighbor route-map or per-neighbor soo command, the SoO check will again work.
However, I believe that things are finally starting to make sense. As soon as a per-neighbor route-map or per-neighbor soo configuration declares a particular SoO value for prefixes received from a CE neighbor, this neighbor is marked with its pertinence to a particular site with the same SoO value. This is even visible in the show ip bgp vpnv4 all neighbor command output:
PE2#show ip bgp vpnv4 all neighbors 192.168.34.4
BGP neighbor is 192.168.34.4, vrf P1, remote AS 64512, external link
BGP version 4, remote router ID 192.168.34.4
BGP state = Established, up for 00:05:32
Last read 00:00:31, last write 00:00:31, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 3 3
Notifications: 0 0
Updates: 3 0
Keepalives: 20 21
Route Refresh: 1 0
Total: 27 24
Default minimum time between advertisement runs is 0 seconds
For address family: VPNv4 Unicast
Translates address family IPv4 Unicast for VRF P1
BGP table version 3, neighbor version 3/0
Output queue size: 0
Index 2, Offset 0, Mask 0x4
2 update-group member
route-map Site-of-Origin is SoO:1:1
Overrides the neighbor AS with my AS before sending updates
Inbound path policy configured
The checks of SoO attribute are then performed between the SoO on a particular prefix and the SoO value assigned to a particular BGP neighbor.
Thanks to Luc and Mohamed for helping me clear out my doubts!
Best regards,
Peter
08-30-2015 08:35 AM
Hi Guys,
I know this is an old post but it makes me wonder.
On CE1, route selection would depend first and foremost on AD (assuming equal prefix length).
So, there are 3 scenarios.
1) CE1 learnt the prefix via eBGP. In this case, AD of 20 will beat AD of 200 (route learned from CE2 would be iBGP) and so router will not choose CE2 as next-hop.
2) CE1 learnt the route from an IGP or route is directly conected --> As all IGP-s have a lower AD than iBGP, router will not choose CE2 as next-hop.
3. CE1 learnt the route from a iBGP neighbor. This is where there may be issues.
Let's look.
If router CE1 cannot reach CE2's WAN ip address, CE2 will not be chosen (next-hop self on CE2 or underlying IGP would be needed).
If CE1 can reach CE2's WAN ip address, and local preference is not configured, the router will look at AS path. Let's assume that AS ovverride is configured (otherwise CE2 would have discarded the route).
If AS ovveride is configured, AS path is examined. The prefix coming through CE2 will have a longer AS path (MPLS cloud AS) than the path that CE1 originally knows and so, CE2 will not be chosen.
I wonder if the reasoning holds up?
Let me know.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide