L2 switch connected to L3 device - same mac across bridged VLANS

[tekjansen101]

Hello,

I had posted this earlier under the data center section but didnt really get any answers. Figure since the issue is more a L2 bridging issue than ACE specific anyway, I thought I'd ask here. The ACE below could just as easily have been any layer 3 router or MLS and we'd expect to see the same kinda of behaviour.

We have a pair or ACEs peered in our network which is connected via a  series of layer 2 switches. The ACEs are unfortunately running in a  hybrid inline-bridge + one arm configuration. The story goes that the  supplier that undertook the installation configured the boxes to run in  one arm mode with source NAT to ensure return traffic hits the ACE,  however this didnt sit well with certain application administrators that  lost client IP information (setup is in a DMZ). So any how ... we've  migrated 'most all the servers off the client/gateway facing segment to  the server vlan ... (bvi setup now instead of svi)... The ACE is bridging two vlans together for end to end client-server connectivity.

When you look at the cam tables  on the L2 switches that interconnect the aces, servers and gateway  together, often times you see the same mac-address being learnt over  both the vlans that have been bridged together. For instance if in my  case VLAN 18 is the client/gateway facing vlan whereas 118 is the server  side vlan, if server X is connected to vlan 118 access port on the  layer 2 switch, a "show mac-add | inc xxxx" on a layer 2 switch to which  the ace is connected will show

18   xxxx Fa0/Y

118 xxxx Fa0/Y

Fa0/Y being the interface connected to the ACE box.

I  get that the ACE is bridging L2 traffic between Vlans 18 and 118 and  that what happens is that when the switch hears server X speak, it  probably hears it out of both vlans since vlan 118 is bridged to vlan 18  and both frames arrive at the switch, which in turn updates its cam  table in kind.

My  question is ... is this desirable/expected ? And can it lead into any  potential complications like Duplicates or the same request  ingress/egressing the server multiple times ? I have not seen the MAC-address flapping logging message normally associated with these kinds of issues, then again the mac isn't really flapping ..

Is this cause for concern ?  Is bridging really even used anymore or have spanning tree concerns rendered the concept archaic and cumbersome ...

Would appreciate any help over the above.

Regards.

[Giuseppe Larosa]

Hello tekjansen101,

I had a similar setup with CSM load balancer in bridged mode and the behaviour was the same you see in your environment.

the same MAC address can be used in different Vlans without ambiguity

For example, all the SVIs of a C6500 MSFC use the same MAC address unless you configure the mac-address under the SVI.

So I would say that this is not alone an issue.

Hope to help

Giuseppe

[tekjansen101]

Hello,

Thanks for the reply.

Didn't really notice the bit about the MSFC macs since we use HSRP pretty much everywhere. But yeah I see what you're getting at ...

So I get this behaviour for servers bridged by the NLB. What I don't necesarily like is that the gateway for the client-facing VLAN is also learnt over two vlans.

show mac-add | inc 9fe3                           //assuming this is the MAC for the SVI-Gatway for VLAN18
  18    00e0.b603.9fe3    DYNAMIC     Fa0/24               //this goes to the gateway
  30    00e0.b603.9fe3    DYNAMIC     Fa0/23               //this goes towards the NLB

The mac-learning out interface Fa0/24 makes sense since this is the interface going out to the gateway. However seeing the gateway mac learnt over the interface going to the bridging NLB is what makes me cringe.

I'm still trying to understand how exactly this last bit happens. The way I see it, a server in VLAN 30, for instance, does an ARP broadcast to learn the L2 identity of the gateway. The broadcast is propogated outside both VLANs since the ACE bridges it so. The broadcast that goes out to VLAN 18 for instance goes all the way to the gateway and makes it back, hence the switch updates its CAM table with the relevant MAC.

However the broadcast over VLAN 30 is re-bridged out the redundant NLB onto VLAN 18 a second time, which again makes it to the gateway and eventually finds its way back to the originating switch.

There's nothing wrong with the above and we haven't really experienced any trouble as of yet, however I would like to nip this in the bud before it goes out of control.

Do you recommend doing anything at the Layer 2 level to control the same ? Should I statically map the gateway MAC to the CAM table ?

BTW is bridging still a valid technique ? Or would you say its past its prime.

Thanks for your help as always Guiseppe.