Two Bridge-Domains in One IOS XR Group Are Not One LAN

Two hosts on the same IOS XR router cannot ping each other, and the configuration looks like they should. Both subinterfaces appear under the same bridge group, the names are one letter apart, and the commit went through without complaint. What is missing is one level of the hierarchy: the bridge group is a container, and each bridge domain inside it is its own broadcast domain with its own membership. Add a third host and the picture usually gets worse rather than clearer.

Start from the symptom and read upward

Hosts that fail inside one subnet while the interfaces report up and the ARP entries never populate is the signature of a domain-membership problem, not a routing one. Routing problems usually give you an ICMP unreachable or a next hop that exists; a missing broadcast domain gives you silence at layer two. Check whether the two attachments are in the same bridge domain before you look at a single IP address. If they are not, no amount of addressing work will join them.

The bridge group is a container, nothing more

In the IOS XR layer 2 VPN hierarchy a bridge group holds one or more bridge domains, and the group itself does not switch anything. Two domains under one group are siblings, not members of one LAN, even though the configuration reads as though they were nested. That layout is deliberate: the group is where you organise services, and the domain is where forwarding actually happens.

Cisco's multipoint layer 2 services guide describes a bridge domain as a broadcast domain holding physical or virtual ports, switching by destination MAC, learning source addresses and flooding unknown unicast, broadcast and multicast within that domain only. Read the hierarchy in that guide before you read your own configuration.

The bridge domain owns forwarding and learning

MAC learning is scoped to the domain, so a station learned in one domain is invisible in its sibling. Flooding follows the same boundary, which is why a broadcast sent by one host never reaches a host in the other domain. Split-horizon groups inside a domain, member state and any configured forwarding controls then narrow the eligible outputs further.

A pseudowire or a virtual forwarding instance is a service attachment to a domain. It is not a synonym for the parent bridge group, and treating it as one is how a provider edge ends up with two services that were meant to be isolated and are not.

The attachment decides which frames arrive at all

Below the domain sits the attachment: the interface or subinterface, the encapsulation it matches, any tag operation, and the domain it joins. A subinterface whose number happens to look like the VLAN is not a frame contract, and the same physical port can feed two domains with two different matches. Write down ingress interface, matched tag, tag action and target domain, then write the egress side separately.

Compare that contract between the two services before you move configuration around. When both domains sit under one group and only one of them carries traffic, the difference is almost always in the attachment rather than in the domain.

If the design also routes between subnets, the layer 3 attachment is a further object with its own gateway address and policy. A bridge domain name explains nothing about which gateway serves it.

Verify with the deployed release before reorganising

Use the release's own operational commands to look at the domain rather than at the running configuration. show l2vpn bridge-domain detail reports the domains and their attachment state, and show l2vpn forwarding bridge-domain with the MAC options shows what has been learned where. If a MAC address appears in one domain and not its sibling, the hierarchy is doing exactly what it was configured to do.

Then inventory every domain and attachment under the group before changing anything, and preserve the existing configuration for comparison. One familiar object name is not evidence that every nested service shares its scope.