cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
807
Views
3
Helpful
4
Replies

MPLS failover

reachonenetadm
Level 1
Level 1

For simplicity's sake let's say that i have 2 7206VXRs running advip-12.4(9)T2. They're in separate cities, each has a direct Internet feed plus a L2 feed between them. Each one is a PE, and running L3VPNs for customers. I use OSPF as an IGP. Everything's working great, but I want to build VPN failover in case the L2 feed between them goes down. I assume the best plan to build a GRE tunnel between them over the Internet and include it in OSPF. That way if the L2 feed fails, OSPF swings the route to the MP-BGP peer (and therefore the LSP?) over to the tunnel and it stays up? Or is it better to maintain a peer with a loopback address in the tunnel and let BGP handle the failover? Do I need to wade into MPLS-TE? Any advice or examples would be very helpful. I realize that the direct internet feed has an MTU of only 1500 so they'll be some pretty serious customer experience issues, but it's better than nothing...

4 Replies 4

wong34539
Level 6
Level 6

The failover configuration requires two identical FWSMs connected to each other through a dedicated failover link and, optionally, a state link. The health of the active interfaces and units is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs.

The following URL may help you:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/configuration/guide/fail_f.html#wp1051895

The following URL gives example configuration:

http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/configuration/guide/exampl_f.html#wpxref97572

wong34539,

Thanks for the reply, but your solutions indicate the need for FWSM which I'm not using. I have a 7206-VXR at both ends. I'm getting closer to the GRE/OSPF/MP-BGP solution but the mtu is going to be painfully low....

reachonenetadm
Level 1
Level 1

It seems to work tolerably well in the LAB using OSPF over GRE tunnels. When the backbone feed goes down, OSPF moves the BGP peer address over to the tunnel. The only tricky part is making a static route for the opposite end of each tunnel, so you don't end up with the tunnel flapping (See %TUN-5-RECURDOWN). Also, the MTU issue seems to be nicely overcome using:

int Tunnel 0

ip address x.x.x.x

ip mtu 1508

mpls ip

mpls mtu 1508

This forces GRE to fragment every packet and reassemble at the other end of the tunnel. While it's hard to tell how much extra load that might be in the real world, it works pretty well in the lab. Yay for GNS3...

Is anyone using the Tunnel mtu parameters? Any issues?

Hi,

I use the "ip mtu" command on tunnels on a 3662 platform. It works fine, without any performance issues (only 10-15 mbit/s traffic..)

The "dont't fragment" value from the original ip header is not copied in header of the gre encapsulated packet. In this header it is 0.

If the router hast to send out the tunnel interface a 1524 byte packet (24 byte GRE overhed), have to fragment the packet..

You can also set the mtu to a higher value, if you may need another MPLS Label Stack.

If you need a fast convergenge,you can use the BFD feature. Very Simple to implement and very effective. BFD can trigger OSPF. The traffic "swap" in 150-200ms. :)

I have tested it with isis (c7201 12.2(33)SRC1)

In addition, bfd is not cpu intensive.

Attention: When you use BFD "echo-mode" , you have to disable the icmp redirects on that interface (no ip redirects)!

Look this link:

http://www.cisco.com/en/US/technologies/tk648/tk365/tk480/technologies_white_paper0900aecd80244005_ps6599_Products_White_Paper.html

Regards,

Tom

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: