It has been almost 3 years since I wrote Branch Office Connections – GRE over IPSec VPN! For those of you who are familiar with Cisco certification, that means time to renew! Anyway, I’m coming back now and looking at this lab, I noticed that we are preferring the serial link for traffic! In this day and age, the serial link would likely be the fallback, and a faster, cheaper GRE/IPSEC VPN would likely be the preferable route! Anyway, to accomplish this, we need to look at EIGRP and its determination of the best route. EIGRP uses bandwidth, delay, reliability, load, and MTU. Essentially, bandwidth and delay are what we are going to play with here; hopefully your ISP is reliable, and not over-provisioned. Manipulation of bandwidth and delay will affect the feasible route’s metric, and in turn affect which route EIGRP will prefer. Manipulation of these values will not affect the actual throughput or latency on the link, they are purely for manipulating routing decisions, as we are doing here.
When I fired this lab back up, I found that the default bandwidth on the Tunnel interface was 9kbps! Actually, I used bandwidth inherit incorrectly; this configuration does not cause Tunnel0 to inherit the bandwidth of the FastEthernet interface. Bandwidth inherit would be used on sub-interfaces, to inherit the bandwidth of the primary interface. A tunnel is not a sub-interface of the transmitting/receiving PHY’s. Anyway, we should make sure we declare a higher bandwidth and lower delay than the Serial backup on these Tunnel interfaces.
Cisco uses tens of microseconds as unit of measure for delay. **1 millisecond = 1000 **microseconds, so 1 millisecond = 100 tens of microseconds. So lets say you have a 50 millisecond ping between your branch office and HQ, you would use a delay value of 5000. FastEthernet’s default bandwidth is 100,000kbps, so we’ll use that for our tunnel bandwidth.
On R4:
R4’s Routing Table - Before & After
Before
After
At this point, our Branch Office is routing egress traffic destined for the Enterprise Core over the GRE/IPSEC tunnel. Lets go ahead and see what the routing table looks like on the other side, on R2.
Aha! The Enterprise Core is still routing traffic destined for the Branch Office over the Serial link. Why is this? Well, R2 still doesn’t realize that the Tunnel interface has a higher bandwidth and lower latency. Let’s go ahead and fix that.
_**
**_
After
Bingo. We’ve fixed it all up. It is critical that any interface metric manipulations are performed on both sides of the link, otherwise the result is a non-symmetrical traffic pattern, which may result in confusion and difficult troubleshooting weeks, months, or years down the road.