L2 switch connected to L3 device - same mac across bridged VLANS
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 ...
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.
Cisco recently announced the availability of the IOS-XE train – IOS-XE Cupertino 17.7.1. This is a standard maintenance release supporting switching, wireless, SP-Access, Routing as well as IoT (Internet of things) platforms with a sustaining support life...
What is AppQoE?
AppQoE is a WAN optimization stack and optimizes WAN traffic for different use cases for applications that are deployed on-prem or in cloud.
What are the benefits of using AppQoE?
AppQoE improves application experience by d...
The application delivery challenges have been the enemy of network since the advent of Internet. So, what are these application delivery challenges that can bring down a network to its heels?
Above are some of the common problems faced not only by tradit...
It is our pleasure to officially announce the finalists in the 2021 IT Blog Awards. Now we are looking to YOU, our amazing tech community, to weigh in. Check out the amazing educational content we've uncovered and vote for your favorites before Friday, Fe...