BGP Site of Origin attribute

Answered Question
Jan 16th, 2012

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

I have this problem too.
0 votes
Correct Answer by Luc De Ghein about 2 years 3 months ago

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):

http://www.cisco.com/en/US/partner/docs/ios/ios_xe/iproute_bgp/configuration/guide/irg_neighbor_soo_xe.html

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

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.7 (4 ratings)
Correct Answer
Luc De Ghein Tue, 01/17/2012 - 04:40

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):

http://www.cisco.com/en/US/partner/docs/ios/ios_xe/iproute_bgp/configuration/guide/irg_neighbor_soo_xe.html

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

Peter Paluch Tue, 01/17/2012 - 13:48

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

Mohamed Sobair Tue, 01/17/2012 - 13:27

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

Peter Paluch Tue, 01/17/2012 - 15:16

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:

  1. We have two CEs at the same site, and each of them is connected to a distinct PE. Both PEs are configured to set a single particular SoO value on all prefixes received from CE routers.
  2. PE1 runs the BGP best path algorithm and selects the CE1 as the next hop towards the site's prefixes. Then, PE1 advertises these prefixes to PE2.
  3. PE2 receives these prefixes and because of its routing policies, it prefers PE1 to reach the site.
  4. In the BGP database of PE2, there are now two alternatives - prefixes received from PE1 and prefixes received from CE2. Under ideal circumstances, these sets of prefixes are identical (i.e. the same set of prefixes is advertised from CE1 to PE1 and subsequently from PE1 to PE2, and from CE2 to PE2). Both these sets of prefixes carry the same SoO value.
  5. 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?
  6. 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?

Best regards,

Peter

Mohamed Sobair Tue, 01/17/2012 - 23:03

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

Peter Paluch Wed, 01/18/2012 - 03:37

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

Actions

Login or Register to take actions

This Discussion

Posted January 16, 2012 at 3:03 PM
Stats:
Replies:6 Avg. Rating:4.66667
Views:9736 Votes:0
Shares:0

Related Content

Discussions Leaderboard