Mailing List Archive

HSRP & Sonicwall problem
Hello,
I have the following setup:
2811-1
-- Cisco 2950 -- Sonicwall Firewall
2811-2

The issue is that the Sonicwall stops communicating with the HSRP Active
router. I have tried setting a static ARP entry for the VIP, however the
communication will still cease. At this point, the static ARP entry must
be deleted, then I have to initiate a ping from the Sonicwall to the VIP
to get things going again.
Here is the config snip from the HSRP interface in question:

interface FastEthernet0/0
description Uplink to Sonicwall
ip address 192.168.0.4 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nbar protocol-discovery
ip route-cache flow
duplex full
speed 100
no mop enabled
standby version 2
standby 10 ip 192.168.0.2
standby 10 timers msec 500 msec 1500
standby 10 preempt
standby 10 authentication ntw-admi
standby 10 track FastEthernet0/1

Is there anything from this config that could be tweaked, or any
suggestions for the Sonicwall to fix this issue?

FYI, I have a similar setup in another location, exact HSRP config on
the 2811, but using a Pix firewall in place of the Sonicwall. This setup
works flawlessly.

Thanks,
Eric
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: HSRP & Sonicwall problem [ In reply to ]
On 5/2/06, Eric Helm <helmwork@ruraltel.net> wrote:
>
> Hello,
> I have the following setup:
> 2811-1
> -- Cisco 2950 -- Sonicwall Firewall
> 2811-2
>
> The issue is that the Sonicwall stops communicating with the HSRP Active
> router. I have tried setting a static ARP entry for the VIP, however the
> communication will still cease. At this point, the static ARP entry must
> be deleted, then I have to initiate a ping from the Sonicwall to the VIP
> to get things going again.
> Here is the config snip from the HSRP interface in question:
>
> interface FastEthernet0/0
> description Uplink to Sonicwall
> ip address 192.168.0.4 255.255.255.0
> no ip redirects
> no ip unreachables
> no ip proxy-arp
> ip nbar protocol-discovery
> ip route-cache flow
> duplex full
> speed 100
> no mop enabled
> standby version 2
> standby 10 ip 192.168.0.2
> standby 10 timers msec 500 msec 1500
> standby 10 preempt
> standby 10 authentication ntw-admi
> standby 10 track FastEthernet0/1
>
> Is there anything from this config that could be tweaked, or any
> suggestions for the Sonicwall to fix this issue?
>
> FYI, I have a similar setup in another location, exact HSRP config on
> the 2811, but using a Pix firewall in place of the Sonicwall. This setup
> works flawlessly.
>
> Thanks,
> Eric
> _______________________________________________
> cisco-nsp mailing list cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

I am not an expert at HSRP, but I thought it used proxy arp to update the
hosts with the new mac addess.

"standby ip" syntax
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d2d21.html#wp1049563

" When the *standby ip* command is enabled on an interface, the handling of
proxy ARP requests is changed (unless proxy ARP was disabled). If the Hot
Standby state of the interface is active, proxy ARP requests are answered
using the MAC address of the Hot Standby group. If the interface is in a
different state, proxy ARP responses are suppressed."
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: HSRP & Sonicwall problem [ In reply to ]
Also, can you ping the physical addresses of the 2800's when the HSRP
address is unreachable? As far as the proxy arp issue, hardcoding the
MAC address should allow you to connect. Since you cant connect even
with hardcoding the MAC, it seems resolving ip to MAC may to be the
issue.


--
infosec
------------------------------------------------------------------------
infosec's Profile: http://www.CertificationChat.com/member.php?userid=24
View this thread: http://www.CertificationChat.com/showthread.php?t=48995

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: HSRP & Sonicwall problem [ In reply to ]
"RawCode" <gonnason@gmail.com> wrote:
> I am not an expert at HSRP, but I thought it used proxy arp to update the
> hosts with the new mac addess.
>
> "standby ip" syntax
> http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d2d21.html#wp1049563
>
> " When the *standby ip* command is enabled on an interface, the handling
> of
> proxy ARP requests is changed (unless proxy ARP was disabled). If the Hot
> Standby state of the interface is active, proxy ARP requests are answered
> using the MAC address of the Hot Standby group. If the interface is in a
> different state, proxy ARP responses are suppressed."

HSRP creates a virtual mac address that does not change during failovers, so
there is no need to update hosts during failovers. What you pasted is how
HSRP changes proxy arp behavior. For any IPs that are to be proxy arped, it
will respond with the redundant virtual mac instead of the non-redunant
physical interface MAC. As far as I know, proxy arp is not related to this
issue in any way. Also note proxy arp is disabled on his config snippit.

While I don't know what is causing this issue, I can say that I have several
hundred Sonicwalls speaking to HSRP default gateways on 6509 switches. I
have recently converted much of this from HSRP to GLBP and had no issue
either way.

The snippit says "standby 10 ip 192.168.0.2". Just to confirm, the
Sonicwall has an IP within 192.168.0.0/24 and a default gateway of
192.168.0.2, correct? I have had strange problems when attempting to put
multiple servers in multiple subnets behind the same sonicwall. The
sonicwall doesn't seem to like servers behind it using a default gateway
outside the sonicwall's own subnet (or something like that).

Newer sonicwalls let you see the arp table (wow fancy). During the broken
time, I wonder if there is no ARP for the gateway or if there is a wrong arp
for the gateway. If your sonicwall supports displaying the ARP table, this
would be worth checking.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: HSRP & Sonicwall problem [ In reply to ]
Also note that sonicwall gear, especially the pro 5060 has broken arp in
general. I've had many interoperability problems with 5060's and Cisco
including 26xx's 17xx's and 65xx's.

The fix for us was to update to their latest firmware and it's helped
(sonicwall firmware upgrade).

On the pro 5060 I'd suggest sonicos enhanced 3.1.0.14-49E


-----Original Message-----
From: cisco-nsp-bounces@puck.nether.net
[mailto:cisco-nsp-bounces@puck.nether.net] On Behalf Of Matt Buford
Sent: Wednesday, May 03, 2006 1:22 PM
To: RawCode; Eric Helm
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] HSRP & Sonicwall problem

"RawCode" <gonnason@gmail.com> wrote:
> I am not an expert at HSRP, but I thought it used proxy arp to update
the
> hosts with the new mac addess.
>
> "standby ip" syntax
>
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_
guide09186a00801d2d21.html#wp1049563
>
> " When the *standby ip* command is enabled on an interface, the
handling
> of
> proxy ARP requests is changed (unless proxy ARP was disabled). If the
Hot
> Standby state of the interface is active, proxy ARP requests are
answered
> using the MAC address of the Hot Standby group. If the interface is in
a
> different state, proxy ARP responses are suppressed."

HSRP creates a virtual mac address that does not change during
failovers, so
there is no need to update hosts during failovers. What you pasted is
how
HSRP changes proxy arp behavior. For any IPs that are to be proxy
arped, it
will respond with the redundant virtual mac instead of the non-redunant
physical interface MAC. As far as I know, proxy arp is not related to
this
issue in any way. Also note proxy arp is disabled on his config
snippit.

While I don't know what is causing this issue, I can say that I have
several
hundred Sonicwalls speaking to HSRP default gateways on 6509 switches.
I
have recently converted much of this from HSRP to GLBP and had no issue
either way.

The snippit says "standby 10 ip 192.168.0.2". Just to confirm, the
Sonicwall has an IP within 192.168.0.0/24 and a default gateway of
192.168.0.2, correct? I have had strange problems when attempting to
put
multiple servers in multiple subnets behind the same sonicwall. The
sonicwall doesn't seem to like servers behind it using a default gateway

outside the sonicwall's own subnet (or something like that).

Newer sonicwalls let you see the arp table (wow fancy). During the
broken
time, I wonder if there is no ARP for the gateway or if there is a wrong
arp
for the gateway. If your sonicwall supports displaying the ARP table,
this
would be worth checking.

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: HSRP & Sonicwall problem [ In reply to ]
Matt Buford wrote:
> "RawCode" <gonnason@gmail.com> wrote:
>> I am not an expert at HSRP, but I thought it used proxy arp to update the
>> hosts with the new mac addess.
>>
>> "standby ip" syntax
>> http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d2d21.html#wp1049563
>>
>>
>> " When the *standby ip* command is enabled on an interface, the
>> handling of
>> proxy ARP requests is changed (unless proxy ARP was disabled). If the Hot
>> Standby state of the interface is active, proxy ARP requests are answered
>> using the MAC address of the Hot Standby group. If the interface is in a
>> different state, proxy ARP responses are suppressed."
>
> HSRP creates a virtual mac address that does not change during
> failovers, so there is no need to update hosts during failovers. What
> you pasted is how HSRP changes proxy arp behavior. For any IPs that are
> to be proxy arped, it will respond with the redundant virtual mac
> instead of the non-redunant physical interface MAC. As far as I know,
> proxy arp is not related to this issue in any way. Also note proxy arp
> is disabled on his config snippit.
>
> While I don't know what is causing this issue, I can say that I have
> several hundred Sonicwalls speaking to HSRP default gateways on 6509
> switches. I have recently converted much of this from HSRP to GLBP and
> had no issue either way.
>
> The snippit says "standby 10 ip 192.168.0.2". Just to confirm, the
> Sonicwall has an IP within 192.168.0.0/24 and a default gateway of
> 192.168.0.2, correct? I have had strange problems when attempting to
> put multiple servers in multiple subnets behind the same sonicwall. The
> sonicwall doesn't seem to like servers behind it using a default gateway
> outside the sonicwall's own subnet (or something like that).

The Sonicwall IP and default route in the 2811 is 192.168.0.1/24

>
> Newer sonicwalls let you see the arp table (wow fancy). During the
> broken time, I wonder if there is no ARP for the gateway or if there is
> a wrong arp for the gateway. If your sonicwall supports displaying the
> ARP table, this would be worth checking.

It does appear in the ARP table when the traffic stops passing.
Additionally, I have tried adding a static arp entry (even fancier) to
the sonicwall that points the Virtual MAC address to the Virtual IP, and
it still quits passing traffic, usually after 3-4 hours.
Another odd thing is, that I totally powered down the standby router,
just to be sure there wasn't some odd HSRP issue here, and it still breaks.

/Eric
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: HSRP & Sonicwall problem [ In reply to ]
> Newer sonicwalls let you see the arp table (wow fancy).
> During the broken
> time, I wonder if there is no ARP for the gateway or if there
> is a wrong arp
> for the gateway. If your sonicwall supports displaying the
> ARP table, this
> would be worth checking.
>
FYI - Older Sonicwall's (Gen 1,2 with the 6.xx firmware) have had an ARP
listing, just not through the regular menu GUI options. If you type in
http://<sonicwall_ip>/diag.html it gives you advanced options including the
ARP table.

Eric


_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/