OSPF over GRE tunnels across IPSec tunnel

[jamesgef]

We have a network consisting of many remote sites located around the world that connect to 2 main sites through VPN connections (2 main sites are connected through non-VPN connection). All the VPN connections are established with PIX firewalls. Behind (inside interface) of each PIX, we do have routers. In order to minimize the size of static routes and provide automatic redunandancy in case 1 main site goes down, we would like to implement dynamic routing.

Any experiences with creating GRE tunnels over IPSec connections and running OSPF across tunnel interfaces? Issues regarding MTU as frames will need to be fragmented?

Thanks in advance!

James

[ruwhite]

As far as OSPF goes, just make certain your tunnel mtu is set low enough to keep from refragmenting packets through the tunnel at the physical interfaces, and make certain your tunnel interface mtu matches on both ends. One thing to note is that fragmentation is a slow'ish procedure, if you can filter the fragmentation back to the hosts shipping traffic through the tunnel as much as possible, you'll probably get a bit better performance, I think.

Make certain, of course, that you have good routes to the other tunnel end point. You can run OSPF either in point-to-point mode, or as nonbroadcast, with manual neighbors configured. Point-to-point's going to be default.

Russ.W

[kirkster]

I have done this and it works fine. You will see that the OSPF routes in the route tables originate from the tunnels and not the physical interfaces. Since you have two head end sites, you may need to adjust the cost of one of the tunnels from each remote site to influence which tunnel gets used for the primary. Do this with a simple "ip ospf cost" command against the tunnel interface. You could also use a bandwidth statement. I have tested this redundancy and it again works perefctly.

As far as MTU is concerned you need to change the ip tcp adjust-mss to 1402 bytes on every tunnel interface in your network. If you don;t it has a dratsic effect on throughput and a security issue too since the fragment does not get encrypted. This can be done live. You need to do this since you are adding headers for IPSEC and GRE which equates to an extra 58 bytes. The deafult max tcp segment is 1460 bytes.

This all works fine and is stable as anything with hardware acceleration.

Steve

CCIE #11330