L3 Switch Routing issue

[Mitchell Theriot]

I have a setup where two servers are on the same network are plugged into a L3 switch.  Off that switch there is a WAN Optimizer device which is inline going to the MPLS cloud.  Also off that switch is an ASA firewall which leads to the Internet for the location.  When the two servers communicate with each other i would think the traffic would only go through the L3 switch between the two servers.  I am seeing traffic between these two servers hitting the WAN optimizer for some reason.  I would think being that these two servers are on the same network the traffic between them would stay at Layer 2.  routing is enabled on the switch because of other vlans on the network.  Any idea what would cause the traffic between the two servers to leave the switch and go up to the optimizer?  Below is a diagram that shows the basic setup.  Thanks.

[Giuseppe Larosa]

Hello Mitchell,

check the ARP table of each server,

if they see the other server IP address with a MAC address = MAC addres of the optimizer this could explain what you see.

The L3 switch may play no role here, all three devices are in the same IP subnet with the optimizer that can be a sort of man in the middle.

Hope to help

Giuseppe

[Mitchell Theriot]

I have looked at the arp tables on both servers and they have the correct mac addresses entered.  However when I look at the switch the mac address for one of the servers is off.  Using the drawing above, on the switch the mac address for the 172.16.1.15 server is showing as xxxx.xxxx.xxx8 but if you look on the server itself the mac address is xxxx.xxxx.xxxc.  If I go on the 172.16.1.10 server is is showing the correct xxxx.xxxx.xxxc mac address for the 172.16.1.15 server.  Could that way this is going up to layer 3 and be routed to the optimizer?

[Mitchell Theriot]

I have also discovered this are VM servers so that may explain the mac address being different on the switch.  But still don't know why the traffic is making it up to the optimizer.  On a different note I noticed on the switch the default route is pointed to the firewall which is correct but they also have ip default-gateway configured pointing to the firewall.  When ip routing is enabled you shouldnt used ip default-gateway correct?

[Richard Burts]

It is a somewhat interesting question about whether you should configure ip default-gateway on a router or a layer 3 switch which will have routing enabled. I think that the first thing in trying to answer the question is to be clear that when ip routing is enabled that the ip default-gateway will have not effect.

Then the question becomes is there any benefit in having both ip routing and ip default-gateway? I would suggest that for some people there may be some benefit in having both. In normal operation the default-gateway is not used. But what about in some failure scenarios? What would be the result if for some reason ip routing was disabled? For some people configuring ip default-gateway is an insurance policy.

When we have insurance policies we hope that we do not need to use them. But when something goes wrong we may be glad that we have that insurance policy. I look at ip default-gateway as that kind of insurance policy and I sometimes go ahead and configure it on layer 3 switches and routers.

HTH

Rick

[Mitchell Theriot]

Thanks Richard.  I just wasn't sure if having them both configured at the same time would cause any kind of conflicts in routing.  I still don' know what is causing the LAN devices that are on the same network to send traffic to the WAN optimizer when they are communicating amongst themselves.  I have not seen anything that stands out on the network yet.

[Richard Burts]

There is no conflict in routing when you have both ip routing and ip default-gateway. Having both does no harm and potentially might have a benefit. Many people eliminate the default-gateway on the grounds that it is superfluous.

I wonder if the mac address is not right if it might cause unicast flooding and explain how the traffic is getting to the optimizer.

HTH

Rick