Policy Based Routing

[EtherNation_Use]

Create Date: Jan 11 2013 11:44AM

Hello all,

I'm having a strange issue with Policy Based Routing. I have two SummitStack switches, each stack is 2x x460 with standard Edge licensing throughout. There are about 5 VLANs that are common to both switches, and each VLAN has a default gateway (currently only on switch 1, but will change to VRRP). So far so good. One of the VLANs is a voice peering VLAN, and is addressed with /28. The gateway address is (anonymised) 1.1.1.65/28. On this are two SBCs, with a VIP that migrates between them of 1.1.1.68, and these have a default gateway of 1.1.1.65. All good there - these can access the Internet OK and set up voice calls to remote hosts via the net.

Going into switch 1 is a fibre from a 3rd party, the other end of which is addressed with a static IP from our peering vlan, their address is 1.1.1.75. We need to have a SIP trunk going via this address rather than the 1.1.1.65 address, and for some reason the SBCs cannot have static routes for the SIP media. So I have put in place a policy route:

if match all {
source-address 1.1.1.1.68 /32 ;
destination-address /32 ;
}
then {
redirect 1.1.1.75 ;
count nap ;
}
}
This has been installed on the ports connecting to each SBC. When the SBC is on switch 1, this works like a dream. Traffic flows, SIP trunks work, etc. When we fail the SBC to the one connected to switch 2, it does not work. When applying the ACL I can see the log on switch 2 says:

01/11/2013 19:36:25.40 Slot-1: Policy:bind:nap_route:vlan:*:port:1:39:
01/11/2013 19:36:25.39 Slot-1: Cannot find the next hop entry for the redirect IP 1.1.1.75. - Ok
01/11/2013 19:36:25.38 Slot-1: The arp entry for 1.1.1.75 is not yet installed in the HW tables. Policy Based Routing will not take effect until this is resolved. Once resolved, Policy Based Routing will start automatically.
01/11/2013 19:36:25.37 Slot-1: Loaded Policy: nap_route number of entries 1
01/11/2013 19:36:25.37 Slot-1: Loading policy nap_route from file /config/nap_route.pol

Which makes precious little sense - I can see that there is a valid ARP entry for the VLAN:

VR-Default 1.1.1.68 00:08:25:05:82:2f 2 NO peering 400 1:39
VR-Default 1.1.1.75 10:8c:cf:28:0a:40 2 NO peering 400 2:48

MAC is the same as on switch 1, I can ping the 1.1.1.75 address just fine from switch 2, and I'm swiftly approaching my wits end. If I enable IP Forwarding for the peering VLAN on switch 2, the line in the logs about the ARP entry goes away, but I'm still left with this entry:

Slot-1: Cannot find the next hop entry for the redirect IP 1.1.1.75. - Ok

And a non working service. Why does it need a next hop? It is on the same VLAN/subnet as the source. Any thoughts?

Thanks in advance,
Bryn

(from Bryn_Sadler)

[EtherNation_Use]

Create Date: Jan 14 2013 1:46PM

Hey Sadlerb

So I read your post and had a few questions. The default gateway is switch 1 correct? When you have switch 2 trying to do the redirect is switch 1 still active?

Did you try this after enabling vrrp and failing the master to switch 2?

Thanks
P (from Paul_Russo)

[EtherNation_Use]

Create Date: Jan 11 2013 12:14PM

A further update - I've still not fixed the issue on switch 2, but I've solved my overall problem by applying the access list to the port on switch 1 that links to switch 2. Bit of a hack, but it works. Would still be interested in knowing the reason behind the behavior of switch 1, if anyone does know and can share. (from Bryn_Sadler)

[EtherNation_Use]

Create Date: Jan 11 2013 12:06PM

Just a quick addendum - I have tried fixing the ARP entry statically, that had no effect. Also, I tried setting up a flow-redirect, and it too moaned about not having a next-hop:

conf flow-redirect "nap" nexthop 1.1.1.75 ping health-check interval 5 miss 2
Error: nexthop is not found (from Bryn_Sadler)