> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Service-Side BGP and Route Redistribution Loops - URL: https://www.pinglabz.com/sd-wan-bgp-service-side/ - Published: 2026-11-06T06:12:33.000Z - Updated: 2026-11-06T16:45:55.000Z - Description: Two edges at one site can loop prefixes between BGP and OMP. Cisco documents SoO plus a shared site-id as the brake. Our edges are different sites and report BGP not active. - Author: Jaime - Tags: SD-WAN, Cisco OSPF is the usual conversation with a campus LAN. BGP is the usual conversation with a data-center or CE router that already has an AS number. The dangerous case is not a single edge speaking BGP to one CE. It is two edges at the same site, both redistributing between BGP and OMP, so that a prefix that left through one edge comes back through the other and goes around again. This post explains that loop and the Site of Origin fix Cisco documents for it. The lab underneath is Cisco Catalyst SD-WAN 20.18.2.1 with two C8000v routers on IOS XE 17.18.02, built in my home lab. Those two edges are at different sites and do not run BGP. I did not build a dual-edge data-center just to create a loop. This is part of the [Cisco SD-WAN series](https://www.pinglabz.com/cisco-sd-wan/). Previous: [Service VPN with OSPF on the LAN](https://www.pinglabz.com/sd-wan-ospf-service-side/). That post is the service-VPN baseline this one builds on. Next: [TLOC extension between two WAN edges](https://www.pinglabz.com/sd-wan-tloc-extension/). For SD-WAN Manager (formerly vManage) and the other old names, see the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/). ## The problem: two doors into the same LAN Give a site two WAN edges for extra capacity or extra transports. Both speak BGP to the LAN, or to each other, and both redistribute BGP into OMP and OMP back into BGP. A prefix learned from a remote site arrives on edge A via OMP. Edge A redistributes it into BGP toward the LAN. Edge B hears that BGP route, redistributes it into OMP, and sends it back into the overlay as if this site had originated it. Edge A may then prefer the BGP copy, or the pair may bounce the prefix between OMP and BGP. Think of two reception desks that both photocopy every letter and put the copy back in the outgoing bag. Without a stamp that says "this already came from this building," the mailroom never stops. ## What the lab can show today The two edges are not that topology. edge1 is site 100, edge2 is site 200\. Each has its own VPN 10 LAN. They share prefixes only through OMP, and they do it by advertising connected routes, not BGP. ``` edge1#show ip bgp summary % BGP not active ``` edge2 says the same. The service VPN still works: ``` edge1#show ip route vrf 10 C 192.168.10.0/24 is directly connected, GigabitEthernet4 m 192.168.20.0/24 [251/0] via 10.0.0.2 ``` That `m` route is the far LAN, administrative distance 251, next hop edge2's system-ip. OMP already has an origin: the prefix is tied to a TLOC and a site-id. BGP on the LAN does not see that origin unless we redistribute and carry it as an extended community. I left BGP disabled. Starting a session toward an address that does not exist would only add noise, and moving both edges to one site-id would collapse the two-branch design this series has been using. The unused configuration group in Manager still has no service profile and no devices, so it does not change this picture. [![Sites 100 and 200 show BGP not active; the SoO loop is from Cisco docs, not reproduced](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-bgp-service-side.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-bgp-service-side.png?ref=pinglabz.com) ## How Cisco says the loop starts, and how SoO stops it Cisco's document "Resolve BGP-OMP Routing Loop when BGP Routing and SoO Are Used" walks through a site with two IOS XE edges and a BGP LAN. The sequence, in plain terms: 1. A remote site advertises a prefix into OMP. 2. Both local edges learn that OMP route. 3. Each redistributes OMP into BGP toward the LAN (`redistribute omp` under the VRF address-family). 4. If the two edges also speak BGP to each other, or the LAN reflects the route, one edge can learn the prefix again as BGP. 5. That edge redistributes BGP back into OMP (`advertise bgp` under OMP). The overlay now has a second, worse copy, and a loop is in business. Cisco documents that OMP does not advertise BGP routes automatically. You have to configure it, which is one reason a stub lab can run for a long time without ever hitting this: ``` omp address-family ipv4 advertise bgp advertise connected ``` I did not add those lines. The built-in brake is Site of Origin (SoO). When an edge redistributes an OMP route into BGP, Cisco associates the BGP SoO extended community with the SD-WAN site-id. A neighboring edge at the same site that sees its own site-id in SoO must not advertise that prefix back into OMP. Two details matter, and both come from that Cisco document rather than from this lab: - Both edges at the dual-edge site must use the **same site-id**. Ours do not: 100 and 200 are two branches, not a pair. - The iBGP (or BGP) neighbor between those edges must send extended communities: `neighbor send-community both` under the VRF address-family. Without that, SoO never arrives and the brake never fires. Cisco also notes a race where BGP installs before OMP on the second edge. The SoO check still applies once the community is present. If you want a tighter filter, set tags or route-maps on `advertise bgp` and `redistribute omp`, but start with matching site-ids and `send-community both`. ## When you would add BGP here A later lab with a LAN CE, or a second edge moved into site 100, would be the right place to turn this into show-command proof. The commands I would start from, and would then have to revert, look like this (not committed on either box): ``` router bgp 65010 address-family ipv4 vrf 10 neighbor 192.168.10.2 remote-as 65011 neighbor 192.168.10.2 activate neighbor 192.168.10.2 send-community both redistribute omp ``` `192.168.10.2` would be the CE, which we do not have. `advertise bgp` under OMP would complete the other direction. Until that topology exists, treat every BGP redistribution example you see in an older vEdge guide as something to proofread against site-id and SoO before you paste it. ## Verify what you can without BGP | Check | Command | This lab | | -------------------------------- | -------------------------------- | -------------------------- | | Is BGP running? | show ip bgp summary | BGP not active | | Service prefixes without BGP | show ip route vrf 10 | Connected plus OMP | | Site-id, which becomes SoO later | show sdwan running-config system | 100 on edge1, 200 on edge2 | | Ownership | show sdwan system status | Still CLI-managed | If you do build the dual-edge site later, add `show bgp vpnv4 unicast vrf 10` (or `show ip bgp vpnv4 vrf 10`) and look for the SoO extended community that matches the site-id before you enable `advertise bgp`. ## What breaks - **Two edges, two different site-ids, one LAN.** SoO will not match, and the Cisco loop brake will not treat them as one site. - **Forgetting \`send-community both\`.** SoO stays on the originating edge. The peer redistributes BGP back into OMP. - **Enabling \`advertise bgp\` "just in case" on a site that already redistributes OMP into BGP.** That is the missing half of the loop. Add it only when you intend LAN prefixes to enter the overlay, and only after SoO is in place. - **Testing this on the two-site lab without redesigning it.** edge1 and edge2 are separate branches. Do not change their site-ids lightly; templates, OMP, and BFD all use them. ## Key takeaways - Service-side BGP is how an SD-WAN edge talks to a CE or data-center LAN that already speaks BGP. Redistributing in both directions on two edges at one site is the loop Cisco warns about. - The documented fix is a shared site-id plus BGP SoO, which requires `send-community both` toward the peer. - This lab's edges sit in different sites, advertise connected LAN prefixes into OMP, and do not run BGP. I confirmed `BGP not active` rather than staging a loop. - Keep VPN 10 as it is until you have a LAN BGP speaker and a real dual-edge site to measure.