SoO is a BGP extended community attribute and stands for Site of Origin. SoO uniquely identifies the site that has originated the route.
SoO is also useful to prevent routing loops and sub-optimal routing, especially used to prevent routing loops on dual homed sites.
SoO 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
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.
BELOW IS A SCENARIO WHICH WILL HELP UNDERSTAND MORE ON HOW SOO WORKS AND ITS CONFIGURATION –
In the topology below the CE 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 an SoO on the incoming update.
When this routing update is passed onto PE2 it checks the SoO tag for this prefix already configured on itself. If the SoO 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 SoO value 200:1 to the incoming update.
PE2 isn’t having any SoO 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 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 SoO 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 SOO is applied to any other routing protocol than BGP, the route-map configured is called with a ip vrf site-mapcommand.
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
