Nexus 9504 not forwarding GBPT frames

[whalen24]

In the scenario I have, there are RAD Communications cpe performing tunneling and de-tunneling of L2 control protocols. Topology is customer switch->RAD cpe->Nexus 9504->RAD cpe->customer switch. The RAD receives L2CP at it’s customer facing ports. When the RAD receives L2CP packets it replaces the destination MAC with what I believe to be a standard MAC used for tunneling (01:00:0C:CD:CD:D0).   The expectation is for the Nexus 9504 to just forward that mac-swapped/tunneled L2CP traffic like it would any other frame.  That doesn’t appear to be happening, however, as the traffic doesn’t leave the 9504 switch.  The 9504 isn't expected to do the tunneling of the L2CP traffic in this scenario, just forward it.  When tunneled L2CP reaches the RAD network facing ports the RADs switch the destination MAC address back to its’ original dest MAC (eg cdp dest MAC 01:00:0c:cc:cc:cc).  It is a two port point to point scenario from the perspective of the 9504.

[whalen24]

The desired behavior is that when a customer issues, for example, a “show cdp neighbor” command from their switch (93180 "cen13" in the attached drawing), it should show the other 93180 customer switch "cen70" as a neighbor.  Vice versa should happen if the same command is initiated from the 93180 customer switch "cen70".  The destination MAC swap has to happen or else the 9504 cen10 would respond to the “un-tunneled” (non mac-swapped) cdp traffic and thus it would show as neighbor.  We want the customers pt to pt circuit from 93180 to 93180 to look like a wire to them.  More importantly than cdp, we need the same functionality to work with stp.  We don’t want the customer receiving our stp and we don’t want to receive there’s.  This can cause loops that will likely result in ports going errdisable and this customer (and potentially other customers) circuit going down completely.