A branch office with two WAN routers is a good design. Two routers, two circuits, no single point of failure. It is also the exact topology that creates one of EIGRP's nastiest failure modes: the site learns its own prefixes back from the WAN, and under the right circumstances starts routing its own local traffic out over the WAN and back in again.
Site of Origin (SoO) is the mechanism designed to stop that. It is an extended community that stamps each route with the identity of the site it came from, and any router at that site drops routes carrying its own stamp. This article covers what SoO does, how it is configured, and - importantly - what we found when we actually tried it on IOS XE 17.18 in a global-table DMVPN. For the fundamentals, start at the complete EIGRP guide.
The problem, seen in a real topology
Our lab is a dual-hub DMVPN. Site A has two spoke routers, SPOKE1 and SPOKE2, both attached to the same site LAN (10.1.1.0/24) and both with tunnels to both hubs. It is the classic dual-homed branch.
Both spokes advertise the site LAN into the WAN. Which means SPOKE1's advertisement travels up to the hubs and back down to SPOKE2 - and SPOKE2 now has a route to its own directly-connected LAN pointing across the WAN:
SPOKE2#show ip eigrp topology 10.1.1.0/24
Descriptor Blocks:
0.0.0.0 (Ethernet0/1), from Connected, Send flag is 0x0
Originating router is 12.12.12.12 <-- its own LAN, connected
10.0.0.11 (Tunnel0), from 10.0.0.2, Send flag is 0x0
Hop count is 2
Originating router is 11.11.11.11 <-- the SAME LAN, back from the WAN via HUB2
10.0.0.11 (Tunnel0), from 10.0.0.1, Send flag is 0x0
Hop count is 2
Originating router is 11.11.11.11 <-- and again via HUB1Right now the connected route wins, so nothing is broken. That is what makes this dangerous: it is a latent fault. It becomes an outage the moment the local path degrades:
- SPOKE2's LAN interface flaps. Its connected route disappears. It installs the WAN copy. Now traffic destined for hosts on its own LAN goes out over the WAN, to a hub, back down to SPOKE1, and onto the LAN. Latency goes up by a factor of fifty and the WAN circuit carries traffic that should never have left the building.
- Worse: while doing that, SPOKE2 is still advertising the LAN. Depending on metrics and timing, the two spokes can settle into a state where each believes the other is the way to the LAN. That is a routing loop, and EIGRP has no AS-path to catch it.
This is the gap SoO fills. BGP has an AS-path, so a route that leaves an AS and comes back is rejected automatically. EIGRP has no such marker. It will happily accept its own route back.
What SoO is
Site of Origin is a BGP extended community (the same wire format as an MPLS L3VPN route target) reused by EIGRP. Every site is given an identity - 100:1, 100:2, and so on. Routes learned from a site are stamped with that site's SoO. Routes arriving at a site carrying that site's own SoO are dropped before they enter the topology table.
The mechanism is deliberately simple: if this route claims to have come from where I am, it has been around a loop, and I want nothing to do with it.
The configuration is a route-map that sets the extended community, applied to the WAN-facing interface:
route-map SITE-A permit 10
set extcommunity soo 100:1
!
interface Tunnel0
ip vrf sitemap SITE-AOne command on the interface, applied identically on every router at that site. Same SoO value, different SoO values per site. That is the whole design.
What actually happened on IOS XE 17.18
We configured exactly that on both spokes, cleared the EIGRP neighbours, and looked for the SoO tag. It was not there.
SPOKE1#show running-config interface Tunnel0 | include sitemap
ip vrf sitemap SITE-A <-- the command is accepted
HUB1#show eigrp address-family ipv4 topology 10.1.1.0/24 | include Extended|SoO|Descriptor|Originating
Descriptor Blocks:
10.0.0.11 (Tunnel0), from 10.0.0.11, Send flag is 0x0
Originating router is 11.11.11.11
... <-- no SoO extended community anywhereNo tag at the hub. No tag at the receiving spoke. The WAN copies of 10.1.1.0/24 were still sitting in SPOKE2's topology table exactly as before.
The reason is in the command name. ip vrf sitemap is part of Cisco's MPLS VPN Support for EIGRP Between Provider Edge and Customer Edge feature. It is designed and implemented for EIGRP running inside a VRF, on a PE router facing a CE, where the SoO extended community rides alongside the VPNv4 route targets that are already there. That is the context Cisco documents, tests, and supports.
In a global-table DMVPN, with no VRF anywhere in the path, the command is parsed and stored but produces no visible extended community on this release. We are not going to pretend otherwise, and we are not going to show you output we did not get.
So if you are running EIGRP in a VRF on a PE, SoO is your tool and it works. If you are running a global-table DMVPN, you need the equivalent - and there is one.
The global-table equivalent: route tags
The logic of SoO is "stamp on the way out, reject on the way in". EIGRP route tags do exactly that, and they work in the global table on every platform.
On every router at Site A:
route-map TAG-SITE-A permit 10
set tag 1001
!
route-map BLOCK-SITE-A deny 10
match tag 1001
route-map BLOCK-SITE-A permit 20
!
router eigrp DMVPN
address-family ipv4 unicast autonomous-system 100
topology base
distribute-list route-map TAG-SITE-A out Tunnel0
distribute-list route-map BLOCK-SITE-A in Tunnel0Read it and it is SoO in different clothing. Everything this site sends into the WAN is tagged 1001. Anything arriving from the WAN tagged 1001 is dropped, because it can only have come from here.
The result, on the same router, in the same lab:
SPOKE2#show ip eigrp topology 10.1.1.0/24
Descriptor Blocks:
0.0.0.0 (Ethernet0/1), from Connected, Send flag is 0x0
Originating router is 12.12.12.12 <-- ONLY the connected path
SPOKE2#show ip eigrp topology 11.11.11.11/32 | include Descriptor|Tunnel0|Ethernet0
Descriptor Blocks:
10.1.1.11 (Ethernet0/1), from 10.1.1.11, Send flag is 0x0 <-- only across the site LANThe WAN copies are gone. SPOKE2 will never again install a WAN path to its own LAN, no matter what happens to its local interface. The loop is structurally impossible, not merely unlikely.
Note that SPOKE1's loopback is now only reachable across the site LAN, not via the WAN. That is intentional and correct: if the site LAN between the two spokes is down, they are, for routing purposes, two separate sites, and they should not be papering over that with a WAN hairpin. If you do want that hairpin as a last resort, tag the LAN interconnect prefixes separately and let those through - but do it deliberately, with your eyes open.
Per-site tag allocation
Give each site a tag and never reuse one:
The one rule that matters: every router at a site must use the same value, and it must be applied on every WAN-facing interface. One router with the tag missing, or with the wrong value, and the loop is back - and it will only bite you during a failure, which is exactly when you can least afford it.
When you do not need this
- Single-homed sites. One router, one circuit, no backdoor. No loop is possible. (Tag them anyway - see above.)
- Sites where the two routers have no L2 path between them. If SPOKE1 and SPOKE2 are not on a common LAN, there is no backdoor and no loop.
- BGP-based WANs. BGP's AS-path already does this. That is precisely why SoO exists only for the protocols that lack one.
Troubleshooting
- Configured SoO and nothing changed? Check whether EIGRP is in a VRF. On IOS XE,
ip vrf sitemapis a VRF/PE-CE feature. In the global table, use route tags instead. - Routes disappearing that should not be? Your inbound deny is matching too much. A tag-based filter with a missing terminating
permitclause blocks everything - the same implicit-deny trap that catches people in BGP. - Loop still occurring on one router. Confirm the tag is applied on every WAN interface of every router at the site. One gap defeats the whole scheme.
- Backup path gone when you wanted it. That is the design working. If a site genuinely needs a WAN hairpin as a last resort, permit specific prefixes through rather than removing the filter.
Key takeaways
- A dual-homed site running EIGRP will learn its own prefixes back from the WAN. The connected route wins - until it does not, and then you have a hairpin or a loop.
- EIGRP has no AS-path. Nothing in the protocol prevents a route from coming home.
- SoO stamps routes with a site identity and drops any route arriving at a site with that site's own stamp.
- On IOS XE 17.18,
ip vrf sitemapproduced no SoO extended community in the global routing table. EIGRP SoO is implemented for the VRF / MPLS-VPN PE-CE context. - The global-table equivalent - and it works, and we verified it - is a route tag set outbound and denied inbound on the WAN interface, applied identically on every router at the site.
- Apply it consistently. One router without the tag re-opens the hole.
Next: EIGRP summarisation with leak maps. The full cluster index lives on the EIGRP pillar guide, and the DMVPN side of this topology is on the DMVPN pillar.
