Local PBR to forward traffic to tunnel on hsrp standby group

[scheng]

Greetings,

Our data center ISP’s internet acces hand-off uses a stub network of private ip to route to the public block on our routers.

Here are the interfaces on my routers -

Router#1 -

gig0/0   172.16.1.5 , standby group 100 , 172.16.1.4  , default gateway --->> ISP gateway 172.16.1.1

gig1/0.10   8.8.8.2, standby  group 10,   8.8.8.1 , crypto map

gig1/0.11   10.3.0.2 , standby group 11,  10.3.0.1   

Router#2 -

gig0/0   172.16.1.6 , standby group 100 , 172.16.1.6   --->> ISP gateway 172.16.1.1

gig1/0.10   8.8.8.3, standby  group 10,   8.8.8.1 , crypto map

gig1/0.11   10.3.0.3 , standby group 11,  10.3.0.1

The typical pure ipsec tunnel terminates on the hsrp standby ip 8.8.8.1.  

The tunnel is used for management of the routers, and other devices in the 10.3.0.0 subnet.

For packet originates from the routers themselves, local PBR is used to forward the packets to interface  gig1/0.10.

This local PBR with route-map, match ACL, set interface gig1/0.10, only works on the hsrp group 10 active router.

To get the standby router on the management station's radar, its  syslog/trap/tacacs packets have to be forwarded to the active router in order to reach the tunnel.

What’s the best way to configure for such topology that can react to hsrp/tunnel failover between the 2 routers ?

Can I expand the local PBR route-map to track some object and effect the necessary set clause? I.e. On active router, set interface gig1.0/10 ; on standby router set ip next-hop 10.3.0.1

TIA!

[Philip D'Ath]

I don't understand why you are using local PBR based on your description.

If the only concern is management, why not build the IPSec VPN to both routers (8.8.8.2 and 8.8.8.3) instead of the HSRP address?  Then you can get directly to each router.

Another option.  Use a dynamic routing protocol between the two routers.  Enable reverse route injection for the VPN, so that both routers will learn a route to the remote VPN destination so it doesn't matter which router has the active VPN.

You can either use the local LAN addresses to communicate with the routers, or add a loopback interface on both routers, and include this in the encryption domain.  Advertise the loopback IP addresses into dynamic routing protocol.

[Richard Burts]

It seems to me that if the IPsec tunnel terminates on the HSRP address of 8.8.8.1 that you force the situation where only one router at a time can be active since 8.8.8.1 is active on one or the other router but not both. This would force the backup router to forward its packets to the active router to access the VPN. If you want both routers to be active on VPN at the same time then I believe that you need two tunnels, one to each router, and should terminate the tunnel on the interface address and not the HSRP address.

HTH

Rick

[eudechime]

Scenario:

Two Data Centers connected via two different MPLS Providers, layer 2 and Layer 3, respectively for redundancy.   Then we decided to be more secured by creating high availability VPN between the data centers to encrypt sensitive traffic going between the two locations. Each location has Cisco ISR 2911 in HSRP. The layer 2 MPLS is configured with dynamic routing (OSPF) and reverse route injection (RRI) though with static for internal network and dynamic routes between the two sites. The layer 3 MPLS is configured with eBGP to peer with provider.

The goal is to use single VPN tunnel for both providers. So if layer 2 MPLS fails, the VPN will failover to layer 3 MPLS. This seems to be working well on OSPF (layer 2 MPLS). But then, we need to redistribute the HSRP (OSPF) traffic to BGP for layer 3 VPN.

I am actually doing similar to Philip's second option above. The layer 2 MPLS is active and Layer 3 is standby. Interfaces are tracked.

However, I am stuck on best way to redistribute the VPN Tunnel HSRP network (OSPF) into BGP without causing network loop. A thought of PBR came into mind which lead me to this post. 

Thanks

EU

[Richard Burts]

EU

If you have a single tunnel and you want it to be able to go over either of the MPLS links then I would suggest that you terminate the VPN tunnel on an interface that is not either of the MPLS interfaces (perhaps a loopback interface). As long as the MPLS routing protocol (OSPF or BGP) knows how to reach the address of the remote peer then the VPN will work without BGP having to know all of the OSPF routes.

HTH

Rick

[eudechime]

Hi Rick,

Thanks for your response. The VPN is being terminated on HSRP VIP. This HSRP is neither of the MPLS.

I want to redistribute 10.130.130.x and 10.129.129.x to BGP network so that VPN tunnel traffic could pass through BGP when failed over to BGP. See attached.

RTR-2 at each site is on standby.

EU