I am looking for some guidance related to the EIGRP Site of Origin.
We are setting up a network for an enterprise(acting as a service provider).
The Topology looks like below-
PE1----PE2 We have control over routers PE1-PE4 but not the CE routers. EIGRP used as CE-PE routing protocol.
| \/ |
| /\ |
CE1 and CE2 are two sites for a single customer VPN. What I am seeing is that PE1 is getting the routes for CE2 advertised back from CE1 and that is causing a loop. I understand that we can use Site of Origin to fix this problem. We dont want to use any distribute lists or other conventional filtering.
Does anyone have an expeience on this and can advise as to what would be the best way to set the SOO, which interfaces, what values etc.
Much appreciate any inputs on this.
Here is document with examples for using EIGRP and SOO.
As Reza pointed out, there are good documents already on the Cisco website that do a great job in describing how the SoO for EIGRP works and how it should be configured. Please note that the SoO functionality for EIGRP actually encompasses several features and it's behavior is not entirely trivial. This is my attempt to summarize what's going on.
First of all, the SoO is expressed as a TLV (Type-Length-Value) tag in EIGRP that is added to individual advertised routes. In BGP, the SoO is expressed as an extended community attribute. Assuming we're discussing pure EIGRP PE-CE scenario in MPLS L3 VPNs, the value of the SoO is first determined by the ip vrf sitemap command on the PE interface towards the CE but the first time this value actually appears somewhere is in the moment of EIGRP-to-BGP redistribution when the redistributed routes in BGP will be equipped with the appropriate SoO community attribute. On the far PE, the SoO community is rewritten into SoO TLV during BGP-to-EIGRP redstribution.
With respect to EIGRP operation:
With respect to BGP operation:
The SoO community will be assigned to a BGP route by redistributing the route from EIGRP. The value of the SoO community will be set according to the ip vrf sitemap command on the next hop interface of these EIGRP-learned routes, assuming these routes do not have any SoO TLVs yet. If the EIGRP route already has a SoO TLV, this TLV will be used instead of the ip vrf sitemap when creating the corresponding BGP SoO community.
These facts are derived from the following documents:
Regarding the SoO attribute itself, I had a marvellous discussion about this with Mohamed Sobair and Luc de Ghein here:
Please feel welcome to ask further!
Excellent explaination Peter. Thank You.
Although I am still struggling to figure out what SOO values I should set at the PE1 and PE2 to prevent a loop at the PE3 and PE4 and vice versa.
I did some testing in the lab, please see the attachment at the below link. Not sure if I am missing something here. If you can throw some ideas, I'd really appreciate that.
I have went over your configuration and although I do not have experiences with NX-OS, the configuration seems to be correct.
The Nexus 7000 MPLS Configuration Guide at
For Cisco NX-OS releases prior to 5.2(5), EIGRP site of origin requires an MPLS license and enablement of the MPLS Layer 3 VPN feature. Beginning with Cisco NX-OS Release 5.2(5), the EIGRP site of origin feature does not require an MPLS license.
Could this perhaps be your case?
Its not a licencing issue.
What I am wondering is if the SOO rules still apply if the route is learnt as a result of the EIGRP QUERY/REPLY process, which is my case here. The PE router in question is learning the route after it sends out a QUERY and recieves the route in REPLY from CE. I dont see this documented anywhere though.
I tested this on IOS-based routers, and I can confirm that the SoO applies also to received EIGRP REPLY packets.
Here, I have a directly attached network 192.0.2.0/24 on R4 where EIGRP is running in a VRF. The R4's interface towards a different router R3 is configured with ip vrf sitemap command that associates the interface with the SoO of 1:1. When I disconnect the 192.0.2.0/24 from R4, its sends queries to R3. R3 is configured to advertise the same network 192.0.2.0/24 with the SoO TLV aready set to 1:1, and the R4 drops it. Please observe for yourself:
R4#show run int s1/0
Current configuration : 169 bytes
description => Interface towards R3 <=
ip vrf forwarding V1
ip vrf sitemap SoO
ip address 10.0.34.4 255.255.255.0
serial restart-delay 0
R4#show ip route vrf V1
Routing Table: V1
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
D 10.0.23.0 [90/2681856] via 10.0.34.3, 00:15:14, Serial1/0
C 10.0.34.0 is directly connected, Serial1/0
C 192.0.2.0/24 is directly connected, Loopback0
Enter configuration commands, one per line. End with CNTL/Z.
*Mar 1 00:41:11.839: IP-EIGRP(V1:1): 192.0.2.0/24 - not in IP routing table
*Mar 1 00:41:11.839: IP-EIGRP(V1:1): Int 192.0.2.0/24 metric 4294967295 - 0 4294967295
*Mar 1 00:41:11.859: IP-EIGRP(V1:1): Processing incoming REPLY packet
*Mar 1 00:41:11.863: IP-EIGRP(V1:1): Int 192.0.2.0/24 M 2809856 - 1657856 1152000 SM 2297856 - 1657856 640000- SoO Loop
*Mar 1 00:41:11.915: IP-EIGRP(V1:1): Processing incoming UPDATE packet
*Mar 1 00:41:11.915: IP-EIGRP(V1:1): Int 192.0.2.0/24 M 2809856 - 1657856 1152000 SM 2297856 - 1657856 640000- SoO Loop
So it seems that the SoO protects also the Query/Reply process.
However, can you specify in more detail the routing loop or the redistribution loop your are trying to solve? Perhaps we're approaching the problem from a wrong end. Can you in detail explain what redistribution loop or suboptimal routing you have observed? Thank you!