EIGRP Redistribution - Default Metrics of Connected and Static Routes

I wanted to do some analysis of the EIGRP topology table last night, so I fired up a small lab. I was especially interested in how external routes appear there and compare to internal entries. Like all good scientific endeavors, the whole thing got derailed when I made a realization.

Here’s the lab I set up. You can ignore the IPv6 info for this exercise.

eigrp1

It’s a simple little thing.  All the networks you see are included in EIGRP 100 for simplicity.  I limited the network statements to 192.0.2.0/24 to keep my options open. I went ahead and added Loopback100 on R3 with an address of 3.3.3.3/32 and added a redistribute connected with a route-map to get the route out in the wild.  Here’s what I had.

SLA Monitoring on the PIX/ASA

We’re working on an data center design for a customer, and they’ve dropped in two ISP links - each with it’s own managed router and public IP space off one of the Ethernet interfaces.  The idea is that they want to use the Internet links in an active-passive setup without getting their own IP addresses to avoid running BGP with the ISPs.  To top it off, the headend of their control is an ASA cluster, so we wind up with two interface on the Internet to treat with a local security level.  Oh, the joys of doing network design.

Reliable Static Routing

Here’s a scenario I ran into long ago. We had several sites that had a frame relay link back to headquarters and a DSL line. Each link was terminated into a different router on a flat LAN with the users. The DSL was for Internet access, but also terminated a VPN as a backup to the frame circuit. The requirements were something like this.

  • Corporate traffic had to go across the frame relay link during normal operations.
  • Internet traffic had to go across the DSL line during normal operations.
  • If the DSL circuit went down, Internet traffic should be moved over to the frame relay circuit to use the corporate Internet link.
  • If the frame went down, traffic should be sent out the VPN tunnel for access to corporate stuff.

We set the default routes of the machines (via DHCP) to the frame relay router. That router’s default route sent traffic to the DSL router, which, of course, had a default route towards the provider. Both routers were participating in EIGRP with the rest of the corporate network, so they all knew where to route traffic destined for corporate traffic. If there was a frame outage, the default routes kicked in and sent traffic to the DSL router, which had the VPN tunnels. The problem came when there was a DSL outage.