BGP SoO is a BGP extended community attribute and stands for BGP Site of Origin. Site of Origin uniquely identifies the site that has originated the route.
Site of Origin is also useful to prevent routing loops and suboptimal routing, especially used to prevent routing loops on dual-homed sites.
Site of Origin can be used even when IGP is used between PE-CE routers and can also be used when BGP is used between PE-CE routers.
SoO value needs to be defined in one of the below Naming Conventions –
- A 16-bit autonomous system number, a colon, and a 32-bit number, for example, 45000:3
- A 32-bit IP address, a colon, and a 16-bit number, for example, 192.168.10.2:51
BGP SoO Rule of Operation
SOO is applied on updates coming to PE1 from CE router and when these routes are advertised as VPNV4 route to PE router PE2, the PE2 router doesn’t advertise the routes back to the CE router hence avoiding the routing loop.
Site of Origin Works & Configuration
Below is a scenario which will help understand more on how Site of Origin works and configured:
In the topology below the CE, a router is dual-homed to two service provider PEs (PE1 & PE2). When the routing update of 9.9.0.1 is received on PE1 it imposes Site of Origin on the incoming update.
When this routing update is passed onto PE2 it checks the Site of Origin tag for this prefix already configured on itself. If the Site of Origin tag matches the route is not propagated back to the CE.
SCENARIO 1:
Routing update of 9.9.0.1 is propagated to PE1 and an inbound route-map is applied to set Site of Origin value 200:1 to the incoming update.
PE2 isn’t having any Site of Origin value configured for 9.9.0.1 and is seen to be advertising the route back to CE.
Note: As we have configured AS override the CE may accept the route from PE2 if it has the prefix 9.9.0.1 from a source which is less preferred than an update from PE2.
Configuration:
PE1:
neighbor 9.9.13.1 activate neighbor 9.9.13.1 send-community neighbor 9.9.13.1 as-override no neighbor 9.9.13.1 route-map Inbound-SoO in exit-address-family route-map Inbound-SoO permit 10 set local-preference 200 set extcommunity soo 200:1
PE2:
#No SoO applied#
neighbor 9.9.13.1 activate neighbor 9.9.13.1 send-community neighbor 9.9.13.1 as-override exit-address-family
verify on PE2 if it is advertising the 9.9.0.1 prefix back to CE without an SoO value configured which could possibly create routing loops.
Paths: (2 available, best #1, table ABC)
Advertised to update-groups:
1
Refresh Epoch 2
100
9.9.13.1 from 9.9.13.1 (9.9.13.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:23:23
mpls labels in/out 16/nolabel
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 2
100
9.9.0.2 (metric 3) from 9.9.0.4 (9.9.0.4)
Origin IGP, metric 0, localpref 100, valid, internal
Extended Community: SoO:200:1 RT:23:23
Originator: 9.9.0.2, Cluster list: 9.9.0.4
mpls labels in/out 16/16
rx pathid: 0, tx pathid: 0
SCENARIO 2:
We apply the Site of Origin on the router PE2 for 9.9.0.1 prefix and can see now PE2 now doesn’t advertise the 9.9.0.1 update back to the CE router.
neighbor 9.9.13.1 activate neighbor 9.9.13.1 send-community neighbor 9.9.13.1 as-override neighbor 9.9.13.1 route-map Inbound-SoO in exit-address-family
Output :
If Site of Origin is applied to any other routing protocol than BGP, the route-map configured is called with a ip vrf site-map command.
Example:
Ip vrf site-map Inbound-SoO
You can also set SoO for connected and static routes when they are redistributed.
Example :
Redistribute static route-map Inbound-SoO
