01-30-2011 11:56 AM - edited 03-06-2019 03:16 PM
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.
01-30-2011 12:22 PM
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
01-30-2011 10:35 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide