GLBP via L2 switch

[andrewelz]

Currently I have a pair of 3845 routers running GLBP connected via two separate ports of a L2 switch with a third switch port connected to a server.

The server's default gateway is the virtual IP address assigned to the GLBP instance.

The AVG always replies to ARP requests with the MAC address of the forwarder to be used by that particular client.

If the MAC address offered is that of the non AVG router, the switch learns the MAC address on the AVG router's port.

This results in packets from the server being sent through the wrong port (the AVG's) rather than the client's designated forwarder (the non-AVG router).

What is the procedure to work around this problem - I would have thought it would be fairly common.

Thanks.

[Joseph W. Doherty]

"If the MAC address offered is that of the non AVG router, the switch learns the MAC address on the AVG router's port. "

Yes, but the switch learns the AVG frame's SA MAC, not the ARP response MAC (non AVG). Normally, you would expect them to be the same, but if they're not, and the client then uses the ARP response MAC as DA MAC, this would flood until the switch saw a frame from the non AVG router.

[andrewelz]

"the switch learns the AVG frame's SA MAC, not the ARP response MAC (non AVG)"

Hmm, the Cisco documentation says:

"The AVG is also responsible for answering Address Resolution Protocol (ARP) requests for the virtual IP address. Load sharing is achieved by the AVG replying to the ARP requests with different virtual MAC addresses."

Which would indicate to me, that a frame, the ARP reply, will be originated by the AVG with the SA MAC of the non AVG router, so it will learn that address on that port.

[viyuan700]

is there no ip redirect on the router port (active) which is connecetd to the switch.

check with somebody else also is ip redirect is solution to ur problem.

[Jon Marshall]

Andrew

I think Joseph is right here.

An arp reply packet has a src/dst mac-address L2 header but this is not the mac-address that is used by the host that issued the arp request. The mac-addresss that the host uses is in the data portion of the frame.

As Joseph says this would normally be the same as the src mac-address in the ethernet header but it doesn't have to be.

So the switch sees the AVG's src mac but the data portion of the frame contains the src address of the non-AVG and this is what the host uses.

I haven't actually tested this but i can't see how else it would work. As you say this is a fairly common scenario.

Jon

[viyuan700]

Hi Andrew,

Things explained by Joseph and Jon are true.

I know i dont have to explain you guys what is ICMP redirect but trying to explain what is happening in here.

two routers R1 and R2 are connected to the same Ethernet segment as Host H. The default gateway for Host H is configured to use router R1. Host H sends a packet to router R1 to reach the destination on Remote Branch office Host 10.1.1.1(connected to R2).

Please go through the link how Host connecetd to R1 reach connected to Host connecetd to R2

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml

This feature through which router figure out how to reach a host is not activated when HSRP is activated on an interface. I didnot get the same explanation for GLBP but i think it is true for GLBP also.

"When running HSRP, it is important to prevent hosts from discovering the interface (or real) MAC addresses of routers in the HSRP group. If a host is redirected by ICMP to the real MAC address of a router, and that router later fails, then packets from the host will be lost. Previously, ICMP redirect messages were automatically disabled on interfaces configured with HSRP"

Pls see the follwoing link and i think can be the solution for the problem

http://www.cisco.com/en/US/docs/ios/12_1t/12_1t3/feature/guide/dt_hsrpi.html