Site of Origin - SOO
SOO identifies the
site that has originated a prefix. It is a BGP extended
community(notation AS:Sequence number) that prevents
routing loops or sub-optimal routing to happen in dual homed sites. If
SOO(say x:y) is configured for a prefix when its update received on PE
from a CE and a VPNv4 route is also received for same prefix on that PE
with same SOO(x:y), the PE doesn’t advertise that prefix back to the CE.
SOO is necessary when we have applied as-override command on PE on the neighborship with CE.
Let’s understand the concept of SOO with help of 2 scenarios:
SITE OF ORIGIN (SOO) - Scenario1 - SOO not applied
Consider the below Diagram:
Without SOO applied on PEs PE1(R9)
and PE2(R10), We’ll see that CE1 advertises LAN Prefix 9.9.112.0/24 to
PE1 (R9), R9 advertises the prefix to RR(R1), R1 further advertises the
prefix to PE2(R10) and R10 advertises the prefix back to CE2.
R11#sh ip bgp neighbors 9.9.110.10 routes | i 9.9.112.0
* 9.9.112.0/24 9.9.110.10 0 100 100 i >>> CE2(R11) receives the prefix 9.9.112.0 from PE2(R10) and keeps it in the BGP table as non best route.
R11#show ip bgp 9.9.112.0 best
BGP routing table entry for 9.9.112.0/24, version 8
Local
0.0.0.0 from 0.0.0.0 (11.11.11.11)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best >>>>>> best path is local.
rx pathid: 0, tx pathid: 0x0
Generally CE R11 will not receive
the LAN network 9.9.112.0/24 from PE2(R10) because it will reject the
prefix seeing its own AS in the AS path [example 100, 65000].
But with as-override command configured on CE-PE neighborship,
the CE2 will accept the prefix 9.9.112.0/24 because AS-path for prefix
will be [100,100]. But it will select the locally connected prefix as
best route for 9.9.112.0/24.
R10#sh ip bgp vpnv4 all neighbors 9.9.110.11 advertised-routes | i 9.9.112.0
*>i 9.9.112.0/24 9.9.0.9 0 200 0 65000 i >>> PE R10 advertising route back to CE R11.
R11#sh ip bgp neighbors 9.9.110.10 routes | i 9.9.112.0
* 9.9.112.0/24 9.9.110.10 0 100 100 i >>> CE2(R11) receives the prefix 9.9.112.0 from PE2(R10) and keeps it in the BGP table as non best route.
R11#show ip bgp 9.9.112.0 best
BGP routing table entry for 9.9.112.0/24, version 8
Local
0.0.0.0 from 0.0.0.0 (11.11.11.11)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best >>>>>> best path is local.
rx pathid: 0, tx pathid: 0x0
SITE OF ORIGIN (SOO) - Scenario2 - SOO is applied
We have applied SOO 100:65000 at PE1(R9) and PE2(R10) to prefix 9.9.112.0/24 when update is received from CE1 and CE2 respectively.
Consider the below Diagram:
R10#show ip bgp vpnv4 vrf red 9.9.112.0 best
BGP routing table entry for 10:20:9.9.112.0/24, version 18
65000, imported path from 10:10:9.9.112.0/24 (global)
9.9.0.9 (metric 40) from 9.9.0.1 (9.9.0.1)
Origin IGP, metric 0, localpref 200, valid, internal, best
Extended Community: SoO:100:65000 RT:100:100
Originator: 9.9.0.9, Cluster list: 9.9.0.1
mpls labels in/out nolabel/25
rx pathid: 0, tx pathid: 0x0
With SOO applied on both PEs PE(R9) and PE2(R10), R10 will not advertise now the prefix 9.9.112.0/24 back to CE R11.
R10#sh ip bgp vpnv4 all neighbors 9.9.110.11 advertised-routes
Total number of prefixes 0 >>>>>>>> No prefixes advertised by PE2(R10) to CE2.
Consider the below Diagram:
BGP routing table entry for 10:20:9.9.112.0/24, version 18
65000, imported path from 10:10:9.9.112.0/24 (global)
9.9.0.9 (metric 40) from 9.9.0.1 (9.9.0.1)
Origin IGP, metric 0, localpref 200, valid, internal, best
Extended Community: SoO:100:65000 RT:100:100
Originator: 9.9.0.9, Cluster list: 9.9.0.1
mpls labels in/out nolabel/25
rx pathid: 0, tx pathid: 0x0
With SOO applied on both PEs PE(R9) and PE2(R10), R10 will not advertise now the prefix 9.9.112.0/24 back to CE R11.
R10#sh ip bgp vpnv4 all neighbors 9.9.110.11 advertised-routes
Total number of prefixes 0 >>>>>>>> No prefixes advertised by PE2(R10) to CE2.
