Cisco BDI not Forwarding L2 Traffic?

Question

I'm new to interface bridging, and I have an ISR4431 running 03.16.04b.S on which I need to bridge between two interfaces for two hosts: One interface is connecting directly to a host, the other to a switch (diagram below). I initially configured it as documented here, but this setup wasn't working in my environment, so I've read everything I can find on BDIs and played with all the related commands for a few days... I could use some input, nothing is working.

I currently have it working so L3 traffic is handled properly (both hosts can reach the BDI IP and can reach/be reached from other subnets), but L2 traffic doesn't seem to work-- the hosts can't reach each other (there was a brief blip twice where ARP resolved on one host for the other, but it went back to "incomplete" when I tried to SSH between them).

If I do a sh mac add add [host1/host2 MAC] on either of the switches, it will show the host's MAC, VLAN111, and interface correctly. I'm guessing something is wrong on the router that's stopping it from forwarding L2 traffic.

Here are the current configs:

Router:

interface GigabitEthernet0/0/2
description DLink Host .2
 no ip address
 negotiation auto
 service instance 111 ethernet
  encapsulation untagged
  bridge-domain 111
 !
interface GigabitEthernet0/0/3
description DLink Host .3 via Switch
 no ip address
 negotiation auto
 service instance 111 ethernet
  encapsulation untagged
  l2protocol peer stp
  bridge-domain 111
 !
interface BDI111
 mac-address 0000.1221.3443
 ip address 1.1.1.1 255.255.255.248
 no cdp enable
end

Top Switch:

interface GigabitEthernet1/1 
description DLink Router G0/0/3
 switchport mode access
 switchport access vlan 111
 no cdp enable
 spanning-tree bpduguard enable
!
interface GigabitEthernet1/2
description DLink Switch2 G1/1
 switchport trunk native vlan 200
 switchport mode trunk
 switchport nonegotiate
!

Bottom Switch:

interface GigabitEthernet1/1
description ULink Switch 1 G1/2
 switchport trunk native vlan 200
 switchport mode trunk
 switchport nonegotiate
!
interface GigabitEthernet1/2
description DLink Host .3
 switchport mode access
 switchport access vlan 111
 no cdp enable

Any help is greatly appreciated, I've been stuck on this for a while and am completely out of ideas.

Update 1: I originally had the following commands entered on the router, but in my testing the seemed to be related to BVIs so I removed them. They've been added back now as it doesn't have any negative impact.

bridge irb
bridge 111 route ip
!Spanning Tree protocol for Bridge Group 7 has not been configured.
bridge 111 protocol  vlan-bridge
!The protocol options I have are dec, ibm, and vlan-bridge

Update 2: I removed the rewrite commands and changed both interfaces to untagged on the router. It's behaving exactly the same without them: Both switches and the router show proper VLAN, interface, and MAC information for each IP, L3 is working, L2 isn't. See the post history for the previous config.

Answer 1

I have a very similar configuration that works fine. A few things stand out to me:

1. The BDI interface (7) doesn't match the bridge domain (111) on the L2 interfaces.
2. On the top switch, you should not have bpduguard enabled on gi 1/1 of the top switch. The router will participate in stp.

Minor things:

• If you don't really need l2protocol peer stp, take it out.

• If you don't really need to set the MAC on the BDI interface, take that out too.

Answer 2

I found the problem, thanks for the help.

These hosts are a vendor's special proprietary blend, which I have next to no control over. With their blessing, I increased the subnet mask on the old host to /29 from /30 so we could add the new host. I reached out to the vendor asking they check if maybe the subnet mask didn't update on the host since there really doesn't seem to be a misconfiguration on my end, and he found that the old host has the wrong broadcast address-- it retained the broadcast for the /30. All these days troubleshooting, and of course it's not a network problem, it's a server issue.

While I'm still waiting for the vendor to fix the broadcast address (rebooting the server didn't do it), I'm confident after all this that the config (once cleaned up again) will work.