This is an interesting scenario to me. I really like this, and when I did this, I thought this was not going to be possible. I certainly learned something this day. Lets do a dual ISP redundancy thing, with MetroE and DSL as a backkup, plus a private LAN on the public network. Wow, this already sounds fishy, but its pretty cool. Ok, so here is how this thing works. Under normal operation, all the traffic goes out the MetroE (since its the more reliable network connection, plus more bandwidth). According to the diagram below, I have a 2911 Cisco router that has a Pix connected to Gig0/0 (which goes to the internal network of the customer), a 10Meg MetroE connected to Gig0/1, and a DSL modem connected to Gig0/2.
Notice these things:
1. Public IP on Gig 0/0 and Gig0/1
2. Private IP on Gig0/2 ---> What???
Ok, what doesn't make sense here? A private IP on a public network? Well, this customer wanted to be able to do two things:
1. Be able to have ISP fail over should the MetroE go down.
2. Use the DSL wireless and wired ports anytime they chose to for testing, guest wireless, etc.
Man, this customer really challenged me on this one (Thanks Ty!). At first, I told the customer that this couldnt be done. But, then the customer said something to me that made me really have to think about this: "I just thought someone as smart as you could make that work". Ok, challenge on. And no, Im not that smart, but thanks. So, here is what happens. As I stated earlier, under normal operation, all the traffic goes out the MetroE (unless you are tied to the DSL modem ports (you know how they have a built in switch and wireless)). So, Im happy going out the MetroE. I have a public IP address of the Pix interface when my packet goes out, and all is good.
Now, what happens when the MetroE goes down? Well, Cisco has this technology called "object tracking". Its pretty cool. The results are the same as a routing protocol (like BGP or OSPF) would do, however it operates differently. What happens is that the 2911 Cisco router is monitoring two destinations. See the below:
ip sla 1
icmp-echo 4.2.2.2 source-ip 77.77.77.94
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.1 source-interface GigabitEthernet0/2
frequency 5
ip sla schedule 2 life forever start-time now
ip route 4.2.2.1 255.255.255.255 10.0.0.1 permanent
ip route 4.2.2.2 255.255.255.255 77.77.77.93 permanent
Ok, above we have this: 4.2.2.2 is being tracked on interface 77.77.77.94 (Gig0/1). 4.2.2.1 is being tracked on interface Gig0/2. If you look at the "ip sla 1", every 5 seconds it sends out a ping to 4.2.2.2. It does this forever. If you look at the "ip sla 2", every 5 seconds it sends out a ping to 4.2.2.1. It does this forever. Both sla's are looking for a response from the two sites it sends to. Its tracking its "reachability". Oh, and the two static routes say that 4.2.2.1 ALWAYS goes out to 10.0.0.1 and 4.2.2.2 ALWAYS goes out to 77.77.77.93 (as far as packets destined for the two addresses).
Now, notice this entry:
track 10 ip sla 1 reachability
delay down 2 up 2
!
track 20 ip sla 2 reachability
delay down 2 up 2
This above says that "track 10" will be tracking the reachability of "ip sla 1" (4.2.2.2). "Track 20" will be tracking the reachability of "ip sla 2" (4.2.2.1). If one of the sites goes down after "2" failures of a ping response, do something (we will get to that "do something" in a minute). If the reachability is now accessable again after being down, and it can get to the destination "2" more times, "do something else" after the "2" times is reached. Ok, what happens is this. Look at the routing table:
ip route 0.0.0.0 0.0.0.0 77.77.77.93 track 10
ip route 0.0.0.0 0.0.0.0 10.0.0.1 5 track 20
ip route 4.2.2.1 255.255.255.255 10.0.0.1 permanent
ip route 4.2.2.2 255.255.255.255 77.77.77.93 permanent
Notice that there are two static routes that are permanent. These two, no matter what, always exist (because they are permanent). Its by design because of this object tracking feature. They reflect what we are tracking and out the interface we want them to go out. Now, the other two static routes say that the default route should go out two different interfaces. Notice that they say "track 10" and "track 20". Also notice that "ip route 0.0.0.0 0.0.0.0 10.0.0.1 5 track 20" has an AD of 5, not 1 like in the "ip route 0.0.0.0 0.0.0.0 77.77.77.93 track 10" statement. So, that means first that the default "default route" is the one with an AD of 1. Then the second default "default route" is the one with an AD of 5. (Man, this could be confusing.) In other words, use the first default route if available. "If available" meaning, if you can reach it in the "ip sla 1" command (if you can reach 4.2.2.2). If you cant, then failover to the second default route, which tracks 4.2.2.1 in "ip sla 2" (across the DSL). You see how this is going to work now as far as the tracking goes? Pretty cool. Now, if the MetroE is out, and traffic is being routed across the DSL, then you still have Internet traffic (you also have to be thinking about external DNS weights on your www servers, etc). When the MetroE comes back up, after two successful pings of the "ip sla 1" and "track 10" statements, the route is put back in.
Under normal operation, the routing table looks like this:
router#sh ip route
Gateway of last resort is 77.77.77.93 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 77.77.77.93
4.0.0.0/32 is subnetted, 2 subnets
S 4.2.2.1 [1/0] via 10.0.0.1
S 4.2.2.2 [1/0] via 77.77.77.93
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet0/2
L 10.0.0.2/32 is directly connected, GigabitEthernet0/2
69.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C 77.77.77.92/30 is directly connected, GigabitEthernet0/1
L 77.77.77.94/32 is directly connected, GigabitEthernet0/1
C 55.55.55.0/28 is directly connected, GigabitEthernet0/0
L 55.55.55.1/32 is directly connected, GigabitEthernet0/0
When the MetroE goes down, the routing table looks like this:
router#show ip route
Gateway of last resort is 10.0.0.1 to network 0.0.0.0
S* 0.0.0.0/0 [5/0] via 10.0.0.1
4.0.0.0/32 is subnetted, 2 subnets
S 4.2.2.1 [1/0] via 10.0.0.1
S 4.2.2.2 [1/0] via 77.77.77.93
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet0/2
L 10.0.0.2/32 is directly connected, GigabitEthernet0/2
69.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 55.55.55.0/28 is directly connected, GigabitEthernet0/0
L 55.55.55.1/32 is directly connected, GigabitEthernet0/0
The routing table changes all by itself. Pretty cool. Now, there is the issue of the whole "private IP range on a public network thing" that we need to address. There is no NAT'ing on the MetroE side. Its already NAT'ed from the Pix thats behind the router (to the customer internal network). However, there are two other scenarios that play out. Number 1: What happens to the traffic going across the private network if the MetroE goes down? and Number 2: What happens to the traffic thats connected directly to the DSL modem or wireless DSL traffic?
Number1: If the MetroE goes down, then traffic is routed out the DSL link. But, you say, the 55.55.55 network cant go out the DSL link, because the traffic would just go out the DSL and come back to the MetroE side (which is down) because the MetroE ISP has that 55.55.55 range. Well, ok. Lets NAT it (do a double NAT). So if you look at this statement below, it says to NAT the traffic that matches the route-map and its applied to Gig0/2. Use Gig0/2's PRIVATE IP address. Wow, on the public network? Yep. But remember, at this point, you are on the PRIVATE DSL internal side of the DSL network. The packet just got NAT'ed from a 55.55.55 public IP to a 10.0.0 private IP. So when the packet gets to the DSL modem (which has the public IP address on its external interface), then it NATs the packet a third time (TRIPLE NAT!?!?!? --> Yep!).
So, lets look:
ip nat inside source route-map dialer interface GigabitEthernet0/2 overload
(this first "deny" says DONT NAT this criteria)
access-list 101 deny ip host 55.55.55.1 host 4.2.2.1
(these below say to NAT this criteria)
access-list 101 permit ip host 55.55.55.1 any
access-list 101 permit ip host 55.55.55.2 any
access-list 101 permit ip host 55.55.55.3 any
access-list 101 permit ip host 55.55.55.4 any
access-list 101 permit ip host 55.55.55.5 any
access-list 101 permit ip host 55.55.55.6 any
access-list 101 permit ip host 55.55.55.7 any
access-list 101 permit ip host 55.55.55.8 any
access-list 101 permit ip host 55.55.55.9 any
access-list 101 permit ip host 55.55.55.10 any
access-list 101 permit ip host 55.55.55.11 any
access-list 101 permit ip host 55.55.55.12 any
access-list 101 permit ip host 55.55.55.13 any
!
(The route-map says if you match ACL 101 AND go out Gig0/2, then apply to the "ip nat" statement above (its a match)):
route-map dialer permit 10
match ip address 101
match interface GigabitEthernet0/2
Number 2: If you are connected directly to the DSL modem, then it just NATs at the DSL modem. It never hits this router anyway. So, no worries there.
Here is what the config looks like. Ive taken out anything that doesn't really apply.
track 10 ip sla 1 reachability
delay down 2 up 2
!
track 20 ip sla 2 reachability
delay down 2 up 2
!
interface GigabitEthernet0/0
description PORT TO CUSTOMER PIX
ip address 55.55.55.1 255.255.255.240
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface GigabitEthernet0/1
description Metro-E ISP
ip address 77.77.77.94 255.255.255.252
duplex auto
speed auto
no cdp enable
no mop enabled
!
interface GigabitEthernet0/2
description TO DSL MODEM
ip address 10.0.0.2 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
no mop enabled
!
interface Dialer0
no ip address
ip flow ingress
ip nat outside
ip virtual-reassembly
encapsulation ppp
shutdown
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname xxxxxxxx
ppp chap password 0 xxxxxxxxx
ppp pap sent-username xxxxxxxx password 0 xxxxxxxxx
!
ip forward-protocol nd
!
ip http server
ip http access-class 23
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip nat inside source route-map dialer interface GigabitEthernet0/2 overload
ip route 0.0.0.0 0.0.0.0 77.77.77.93 track 10
ip route 0.0.0.0 0.0.0.0 10.0.0.1 5 track 20
ip route 4.2.2.1 255.255.255.255 10.0.0.1 permanent
ip route 4.2.2.2 255.255.255.255 77.77.77.93 permanent
!
ip sla 1
icmp-echo 4.2.2.2 source-ip 77.77.77.94
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 4.2.2.1 source-interface GigabitEthernet0/2
frequency 5
ip sla schedule 2 life forever start-time now
access-list 23 permit 10.10.10.0 0.0.0.7
access-list 101 deny ip host 55.55.55.1 host 4.2.2.1
access-list 101 permit ip host 55.55.55.1 any
access-list 101 permit ip host 55.55.55.2 any
access-list 101 permit ip host 55.55.55.3 any
access-list 101 permit ip host 55.55.55.4 any
access-list 101 permit ip host 55.55.55.5 any
access-list 101 permit ip host 55.55.55.6 any
access-list 101 permit ip host 55.55.55.7 any
access-list 101 permit ip host 55.55.55.8 any
access-list 101 permit ip host 55.55.55.9 any
access-list 101 permit ip host 55.55.55.10 any
access-list 101 permit ip host 55.55.55.11 any
access-list 101 permit ip host 55.55.55.12 any
access-list 101 permit ip host 55.55.55.13 any
!
route-map dialer permit 10
match ip address 101
match interface GigabitEthernet0/2
!