ICMP redirects disabled with secondary addresses

Unanswered Question
May 19th, 2008

I have a address unknown flooding problem that I would like to solve without involving the server admin or hard coding mac addresses in switches.


A PIX is connected to an Cisco 4500 (layer 2 only) access switch and fronts an “outside” subnet that supports several servers. These servers backup to another server on the “inside” subnet of the PIX.

That “inside” subnet is one of several secondary subnets assigned to that VLAN and the VLAN is serviced by two upstream routers and an HSRP group.


When an "outside” device send its backup data, the PIX sends it directly to the backup server since that server is on the same subnet as the PIX's “inside” address. But any reply from the backup server to the “outside” device being backed up goes through the backup server's default gateway which is the HSRP address. Normally the router would send an ICMP redirect to the backup server instructing it to send the response to the PIX but "ICMP redirect is disabled on interfaces with secondary IP address".


I could put a permanent mac address in the switch's forwarding table for the backup server or ask the server admin to install a route for the PIX “outside” subnet but I'd rather use the normal architected processes.


Can I/should I bypass the redirects disabled on interfaces with secondary addresses or have redirects sent for this (PIX “outside”) network only? Or are there other options?


Thanks


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Burts Mon, 05/19/2008 - 04:46

Leonard


I think that you have a slight misunderstanding about why icmp redirect is disabled. You seem to associate disabled redirects with the interface having secondary addressing. But what has disabled redirects is the configuration of HSRP on the interface.


It seems to me that your choices are to have a route installed in the servers so that they will access the outside subnet through the PIX or to enable redirects on the router interface. You will need to evaluate the potential impact on HSRP and the benefit of having redirects for this traffic.


I believe that the reason that HSRP disables redirect is based on this scenario: assume that the standby router has the best path to some destination subnet. Now a server sends a packet toward that destination subnet and sends it to the active router. The active router will determine that the best path is through the standby router and forward the packet to the standby router. If the active router also sent the redirect to the server then the server would forward to the standby router instead of the active router. But if something happened and the standby router was no longer the best path to the destination. But the server continues to forward to the standby router. So HSRP disables redirects so that traffic is always sent to the active router which will decide what to do with it.


I am not clear what impact enabling redirects will have on your HSRP. But I suspect that it would not be great. You would need to evaluate this for your own environment.


The first sentence of your post mentions an address unknown flooding problem. But never mentions anything about that problem. Is there an address unknown flooding problem and how do you think it is related to redirects?


HTH


Rick

lgreenjr Mon, 05/19/2008 - 05:23

Rick,


The ICMP redirect disabled message is a direct copy/paste from a 6500 startup log.


The flooding occurs as such:

the PIX arps for the backup server and on reply, the server's mac address is placed in the access switch's forwarding table. All other responses from the server are sourced from the server's defalt gateway (the router's) mac address. After 5 minutes, the server's mac address is purged from the access switch's forwarding table. Subsequent data through the PIX to the backup server is flooded on the access switch.


Len


Richard Burts Mon, 05/19/2008 - 08:40

Len


Thanks for the additional information. The real cause of the flooding is the mismatch between the timeout of the ARP cache used for layer 3 forwarding which by default is 4 hours, and the timeout of the switch mac-address-table.


As I see things I believe that there are several options which you could use to resolve the flooding issue:

- you could shorten the ARP timout on the PIX to match the mac timeout on the access switch.

- you could lengthen the mac-address-table timeout on the access switch to match the ARP timeout on the PIX.

- you could enable redirects on the HSRP interfaces.

- you could code a route in the server so that it sends to the outside subnet via the PIX rather than its usual default gateway.

- you could code a static MAC on the access switch.


HTH


Rick


Actions

This Discussion