Original computing articles by a systems administrator

SOPA and Protect IP are a large concern for those of us who work in industries that are based on the Internet. It is important to really try to understand what is happening, what these laws are about, and why people are trying to pass it. As someone that is in part responsible for a large Internet property (The “Stack Overflow Network”, currently 167 largest in the U.S. reaching nearly 7 million people a month to Quantcast) I have an interest in the Internet remaning an open global global network, and since my company is about the free exchange of knowledge, regulation generally goes against those interests. In particular, the DNS filtering system proposed and legal risk is of concern to the Internet industry.

However, the U.S. Government, in theory, should be concerned with the health of industry as a whole in the United States, not just the entertainment industry or the Internet industry. It is their difficult job to balance the concerns of two entire industries, the awesomeness of this responsibility should not be taken lightly by anyone. If a politician considers both industries, then I would consider them to be honorable regardless of their conclusion, if they only focus on the concerns of a particular industry then they failing to represent the people of the United States justly. So for myself, dismissing the concerns of the entertainment industry offhand can not lead to a just opinion. However, when looking at what SOPA does for the entertainment industry and piracy prevention I still feel strongly that SOPA and Protect IP are not in the best interest of the United States.

The Entertainment Industry’s Concern

At face value the concern seems pretty obvious, that the entertainment industry, distributors, and the government are losing money and tax revenue due to the piracy of intellectual property. Although the extent is difficult to pin down, that the concern is a legitimate and the loss is substantial seems to be true. When it comes to SOPA and Protect IP the concern is not piracy as a whole, but rather a subset of piracy.

Policy Institutes or “think tanks” are often good sources for briefs on the basis policies or ideologies being carried out in the United States. Both the RIAA and MPAA have sited the Institute for Policy Innovation (IPI) as a source of information regarding IP theft (the MPAA has also disputed findings from the IPI but still frequently cites them). Therefore the IPI’s “Protecting Propery Rights on the Web: Thoughts on the Protect IP Act” seems to be a reasonable source for the motives behind SOPA and Protect IP. The following excerpt points to the issue that SOPA and Protect IP primarily attempt to address:

The very successful Digital Millennium Copyright Act of 1998 (DMCA) and the recent PRO-IP Act of 2008 have given lawmakers tools to combat online piracy and counterfeiting for websites hosted within the reach of U.S. law. The track records of both laws demonstrate that they have succeeded in carefully targeting illegal behavior without creating hardships or unintended consequences for the Internet ecosystem. So U.S. law enforcement officials already have tools to deal with rogue websites hosted domestically. But, of course, rogue websites residing on offshore servers or otherwise hosted by overseas companies remain safely outside the reach of these U.S. laws. And we’re all familiar with how easy it is to move a website to an offshore server in order to escape the reach of domestic law.

The scope of the problem that SOPA/Protect IP is attempting to address is vital to understanding this legislation. It is trying to limit Intellectual Property (IP) theft by U.S. citizens using foreign websites as their source. DMCA already addresses sites hosted within the U.S., and obviously that law has no effect when the person downloading the content is outside of the U.S. SOPA itself also describes this:

A service provider shall take technically feasible and reasonable measures designed to prevent access by its subscribers located within the United States to the foreign infringing site (or portion thereof) that is subject to the order, including measures designed to prevent the domain name of the foreign infringing site (or portion thereof) from resolving to that domain name’s Internet Protocol address.”

The reason why understanding the scope of SOPA is important because if you are going to weigh the concerns of these two industries, you need to understand the cost and gains to both of them, not just one or the other. To understand how this benefits the entertainment industry you have to estimate the damages to the industry that fit this specific scenario or scope. This then needs to be weighed against the concerns of web industry and the burnden it puts on the justice system and the Internet Service Providers (ISPs).

Scope of the Bill and the Entertainment Industry’s Concerns

The MPAA says the total economic output lost because of Piracy is $58 Billion. For this they cite the IPI’s “The True Cost of Copyright Industry Piracy to the U.S. Economy” which in turn cites a study done by LEK Consulting. I was able to find this PDF file which looks like it is from LEK. When talking about the losses to the U.S. motion picture studios it estimates about 20% of the 6.1 billion (1.3 billion) are piracy losses in the U.S. (I believe that this means the consumers are in the U.S., not the source of the pirated goods). Further narrowing that, they state that of the total, only 2.3 billion was via the Internet, making the U.S. losses for Internet piracy in their estimate to be $447 million. Another interesting point is that 44% of the U.S. losses in this case are college students.

When estimating the damages this bill would save, there is one other factor in terms of scope that needs to be accounted for. If the DNS filtering is done in a way that doesn’t inspect packets, but rather prevents DNS entries for rogue sites from resolving to an IP address, this will only stop yet another subset of pirates. For illustrative purposes, let us break people into three groups: “The Geeks”, “The Tech Savy”, and “Mom & Pop”. When it comes to piracy, if the geeks want to pirate stuff then stopping them, at least in a systematic way, is futile. You can certainly find and arrest them on a case-by-case basis, but as a group they are ahead of the technology curve — it is like thinking locks will stop locksmiths intent on breaking a lock. Next there is the “Tech Savy”, they are not experts in technology but can figure out how to do a lot of things. Lastly, you have “Mom & Pop” who can’t do much without the help of their tech savy relatives and friends. In terms of DNS filtering without packet inspection, to bypass it all you have to do is change your DNS server to one located in another country, this is so trivial (just a network setting) it won’t even slow down people in the tech savy group. Going back to the LEK study:

The 16-24 age group is particularly high in the category of internet piracy, … It is even higher in the US, where the same age range represents 71 percent of downloaders.

If for an estimate, we conservatively accept that the tech savy are mostly in that age group, then we are left with 29% of $447 million or $129 million losses for all the movie studios in the MPAA by their own study. I think this same subset will apply everywhere in the entertainment and software industries.

Missing from the report is the basis for this calculation, which in my mind would be the most important piece of information, as the results from the survey multiply this. For instance, if they assume that everything that is pirated would have been bought, this assumes price would not impact buying decisions (in particular for 16-24 years old with limited disposable income), which would greatly inflate the numbers. Making the $129 million, already a small fraction of the “billions” being frequently cited even smaller.

Taking all of this into account, SOPA does seem to address the Industry’s concern regarding piracy, but only a very small subset of it: Illegal downloads by Non-Tech Savy Users in the United States using sources outside of the United States.

The Concerns Internet Industries

SOPA is legislation that will attempt to regulate a complex technical system. Some of the foremost experts in this system, many the creators of core components that make the Internet work, have spoken out against SOPA. The consequences for the technical foundation of the Internet are huge. In addition to this, many innovators on the Internet such as the founders of Google, Twitter, LinkedIn, YouTube, PayPal, Craigslist, and Yahoo have also raised objections because they feel it will harm innovation on the Internet.

The people above and news blogs like techdirt have covered the concerns of the Internet industry well, so I won’t repeat them here.

Conclusion

In the one hand, there are legitmate concerns from the entertainment industry and other industries that suffer losses due to Internet piracy. In the other, there is the web industry where SOPA could harm innovation on the Internet and also fracture parts of the Internet’s fundamental structure (namely DNS). There are also the free speech concerns attached to any form of censorship — that it could be abused.

If these two are weighed fairly, the huge impact this could have to the ecosystem of the Internet outweighs the relatively small subset of piracy SOPA might help prevent: downloads by non-tech savy users in the United States using sources outside of the United States. Therefore in this instance the Internet and web industry should be favored and this bill should not pass in its current form.

Although wireshark is a very useful tool there are some limitations that bother me:

I have found that scapy and pylab can fill some of the gaps. Here is an example using the python interactive interpreter:

from scapy.all import IP,TCP,rdpcap
from pylab import *
#Import the Capture File
a = rdpcap('smaller-out_00000_20110214101853')
#Filter the Capture File
b = [ pkt for pkt in a if IP in pkt and
      (pkt[IP].src == '10.7.0.12' or pkt[IP].dst == '10.7.0.12') ]
#Create an array of TCP Window sizes from the capture
wins = [ int(win[TCP].window) for win in b if TCP in win ]
#Create the Histogram
hist(wins, bins=100)
#Display it
ylabel('Frequency')
xlabel('TCP Window Size')
show()

I have switched jobs and am now working for Stack Overflow. This is an exciting position for me as I have been following the two co-founders Jeff Atwood and Joel Spolsky for a while now. As part of my new job I will be writing articles on the Official Serverfault Blog and already wrote my first article about using fault tree analysis as a system administrator.

Server Fault is a question answer site for system administrators and has built a nice community of some dedicated system administrators who are serious about what they do. Next time you have a system administration or networking questions I recommend you head over there and ask a question!

Introduction:

From what I have learned there are at least two typical scenarios for WAN level redundancy with BGP that you would use in a co-location environment. The first is when you get an AS from ARIN, and advertise your IP block to two different providers so you become an edge (aka border) router on the Internet receiving full BGP Internet routing tables. The other scenario is when you get a private AS from your hosting provider, and the hosting provider is the actual edge router that is multi-homed to different ISPs. This lab is about the second scenario.

A Brief Introduction to BGP:
BGP stands for Border Gateway Protocol. If there is a key concept to understand, it is that with BGP the goal is no longer to build the routing table based on each single IP network and hop (at least with eBGP), but rather between Autonomous Systems (AS). An autonomous system is a network, or a group of networks, under the control of a single organization. An example of an autonomous system might be an entire ISP, or the northeast region of an ISP, and each AS on the Internet is given a number called an ASN. So the Border in BGP is the border between these autonomous systems (Between ISPs for example). So with BGP, routing tables are built based on the number of AS hops (or in real life, many other factors), not IP hops so BGP in effect provides a macro view of the entire network (ie the Internet) leaving out the details of all the hops within an AS. The routers that live on these borders are called border or edge routers, and they speak BGP to each other.

What I just described is external BGP (eBGP), there is also internal BGP (iBGP) which is used to communicate between routers within an AS. Routers that speak BGP to each other are neighbors, and these neighbors are manually entered on each router. If the neighbors have the same AS number (ASN) then it is iBGP, if they are different, then it is eBGP.

The way that Autonomous Systems and IP networks work together is that an AS has a summary of all the networks under it’s control. Border routers announce the networks in their AS to their neighbors and then those neighbors pass it on so it reaches every border router on the Internet. As the routing information passes through a neighbor to another neighbor , the neighbor appends its AS number to the route in the AS_PATH attribute. This resulting list of AS numbers ends up being a possible route that router can use to build its routing table.  It is important to understand that the the BGP table and the routing table are different, the BGP table is used to build the routing table. This attribute also prevent routing loops because by not allowing information to enter into the BGP tables that has its own AS in the AS_PATH. So BGP does need to know the next hop IP address, but only the next hop ip for the next hop AS.

Two last things I should mention are that BGP routes have attributes attached to them, and that a router attached to only one AS is called a stub. Example attributes are AS Path, Next Hop, and Local Preference.

Exploring BGP:
If you like to get to ‘touch’ the things that you learn, there are a couple of things I recommend with BGP. With traceroute, you can display the ASN numbers (at least with the one that comes with Ubuntu) by using the -A switch. So you can see where there border routers are and how the packets travel with an ASN. Some major ISPs also operator “Looking glass routers” that you can telnet into and use some show commands. For example:

$ telnet route-server.ip.att.net
...
User Access Verification
Username: rviews
route-server>show ip bgp 24.61.0.0/15
BGP routing table entry for 24.60.0.0/15, version 5701270
Paths: (18 available, best #14, table Default-IP-Routing-Table)
Not advertised to any peer
7018 7922 7015, (received & used)
12.123.25.245 from 12.123.25.245 (12.123.25.245)
Origin IGP, localpref 100, valid, external
Community: 7018:5000 7018:34011

You can find a list of these routers that you can log into here.

Introduction to HSRP:
HSRP stands for Hot Standby Router Protocol and it is designed to provide LAN redundancy by providing a backup of the default gateway that each machine on the LAN has set. The typical setup is that you have two routers and each has an interface on the LAN.  On each of these interfaces, they get an ip that is on the lan, but they get an additional virtual IP that will be the gateway for machines on the LAN.  This IP is held by one of the routers at a time, the routers send messages to each other, and if one of the routers goes down and that router had the gateway IP, the other router will pickup the gateway IP.

The Dynamips/Dynagen Lab:

You know the cliche about pictures, so let me start with this diagram:

So in this lab, Provider1 and Provider2 are the two routers by the same provider.  Mine1 and Mine2 are the routers that a client would own.  The two Autonomous Systems are 1500 and 64512.  64512 falls into the range of Private ASNs, so true edge routers don’t worry about them, they know how to get to 1500, so it is loosely analogous to NAT. There were two main objectives to this lab. My first objective was to make it so that any one router or switch in the lab can fail, and traffic would still continue to route.  The second objective was to make it so Mine1 is always preferred as long is it is up and running.  The configuration on the provider routers are probably an over simplification of what is going on, but the configuration is functional for the purpose of this lab. The final thing I need to point out before going into the configuration was that the switches and the bonded nics are not actually part of the lab because they are beyond the capability of dynamips.

The Router and Lab Configurations:
I am going to assume that you already know how to use Dyanagen and Dynamips and how to assign ip addresses to interfaces.  If you don’t know how to use Dynagen you can go through a tutorial here.  I have posted the Dynagen configuration for this lab here , and the complete configurations for all the routers in the lab are posted here.

The BGP Configuration:

Neighbor Relationships:

The first step after creating the lab and setting up the ip addresses is to set up the neighbor relationships.  These are created by manually entering in each side of a neighbor relationship on the routers. There are 4 of these neighbor relationships, two iBGP sessions with one between Mine1 and Mine2 and the other between Provider1 and Provider2, and two eBGP sessions with one between Mine1 and Provider1, and the other between Mine2 and Provider2. So For example, to configure the iBGP session between Mine1 and Mine2 we do the following:

Mine1(config)#router bgp 64512
Mine1(config-router)#neighbor 192.168.8.2 remote-as 64512

Mine2(config)#router bgp 64512
Mine2(config-router)#neighbor 192.168.8.1 remote-as 64512

Notice that on each router the bgp AS number, 64512, is the same as the configured router, so this is iBGP. When we set up these neighbor relationships, the ip of the other side is specified. Also, 64512 falls in the range of 64512-65534 which means it is a private autonomous system number. In order to verify the relashionship is established do the following:

Mine1#show bgp sum
BGP router identifier 192.168.8.1, local AS number 64512
BGP table version is 4, main routing table version 4
2 network entries using 234 bytes of memory
3 path entries using 156 bytes of memory
5/2 BGP path/bestpath attribute entries using 620 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1034 total bytes of memory
BGP activity 2/0 prefixes, 5/2 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.8.1      4  1500    2775    2777        4    0    0 1d22h           1
192.168.8.2     4 64512    2800    2798        4    0    0 1d22h           1

The last line should an up time for the 192.168.8.2 neighbor relationship (In this I had already set up the eBGP neighbor relationship as well). BGP isn’t the fastest routing protocol, so if it isn’t up you may want to wait about 30 seconds. Also, if you haven’t edited the logging at all, you should see a message printed to the console when it is established. If it still isn’t working, double check your ASN and IP numbers, that you can ping the neighbor ip from both routers, and also that you are not filtering TCP port 179 with an ACL because this is what BGP uses.

Setting up a eBGP session is essentially the same:

Mine1(config)#router bgp 64512
Mine1(config-router)#neighbor 172.16.8.1 remote-as 1500

Provider1(config)#router bgp 1500
Provider1(config-router)#neighbor 172.16.8.2 remote-as  64512

This time and the neighbor remote AS is different, so it is eBGP.

Injecting Routes:

The main point of BGP is to advertise your IP range to the Internet, to do this you inject the routes into BGP. In this lab the Provider has given us a range of 12.12.12.0/27. This range doesn’t appear on any of the router interfaces because all of those IP addresses are NAT’d to the 192.168.1.1/30 network. Since 192.168.1.1/30 is accessible from both routers we want 12.12.12.0/27 to be available from both routers, so we announce the route from both Mine1 and Mine2. The BGP configuration to announce a route is straight forward:

Mine1(config)#router bgp 64512
Mine1(config-router)#network 12.12.12.0 mask 255.255.255.224

The one caveat is that a route will not be announced unless the it is in the routing table and since we don’t have a directly connected route because no interface has that route we need to add a null route:

Mine1(config)#ip route 12.12.12.0 255.255.255.224 Null0

When traffic destined for the 12.12.12.0 arrives from the Provider network, it doesn’t go to NULL because NAT happens before routing (There might be a better explanation for this however, this is just how I think of it, either way, it works). After doing this, you can verify that the provider network sees the network with the following:

Provider1#show ip bgp
BGP table version is 2, local router ID is 172.16.8.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 12.12.12.0/27    172.16.8.2               0             0 64512 i

This same configuration is then repeated on Mine2 changing the neighbor accordingly.

Achieving WAN Redundancy:

The steps we have taken so far fail to provide redundancy for the WAN. An example of why this is can be seen by shutting down Mine 1. Before we do this, let us look at the BGP table and the routing table on Provider 1.

Provider1#show ip bgp
...
Network          Next Hop            Metric LocPrf Weight Path
* i12.12.12.0/27    172.16.8.6               0    100      0 64512 64512 i
*>                  172.16.8.2               0             0 64512 i
Provider1#show ip route
....
172.16.0.0/30 is subnetted, 1 subnets
C       172.16.8.0 is directly connected, FastEthernet0/0
10.0.0.0/30 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet1/0
12.0.0.0/27 is subnetted, 1 subnets
B       12.12.12.0 [20/0] via 172.16.8.2, 1d23h

With BGP, only one route to a destination will be entered into the routing table from the BGP table.  The current route to 12.12.12.0/27 is via 172.16.8.2. If we look at the second route in BGP it is via 172.16.8.6.  However there is a problem with this, if you look at the routing table there is no route to 172.16.8.6 in the routing table.  So lets look at the tables after we shutdown Mine 1.

Provider1#
*Mar  3 00:22:42.223: %BGP-5-ADJCHANGE: neighbor 172.16.8.2 Down BGP Notification sent
*Mar  3 00:22:42.223: %BGP-3-NOTIFICATION: sent to ...
... neighbor 172.16.8.2 4/0 (hold time expired) 0 bytes
Provider1#show ip bgp
...
   Network          Next Hop            Metric LocPrf Weight Path
* i12.12.12.0/27    172.16.8.6               0    100      0 64512 64512 i
Provider1#show ip route
...
Gateway of last resort is not set
     172.16.0.0/30 is subnetted, 1 subnets
C       172.16.8.0 is directly connected, FastEthernet0/0
     10.0.0.0/30 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet1/0

There is now no route on Provider 1 to the 12.12.12.0 network even though there is an entry in the BGP table. The reason for this is that routes will not go from the BGP table into the routing table if the next hop can not be reached. The solution to this problem is to use the next-hop-self command. What this does is change the next-hop attribute to be the router that shares this information. To set this up on the provider side we do the following:

Provider1(config)#router bgp 1500
Provider1(config-router)#neighbor 10.0.0.2 next-hop-self

Provider2(config)#router bgp 1500
Provider2(config-router)#neighbor 10.0.0.1 next-hop-self

Then if you clear the iBGP session with you can see that the next hop has changed on Provider 1:

Provider1#clear bgp all 1500
Provider1#show ip bgp
...
   Network          Next Hop            Metric LocPrf Weight Path
*>i12.12.12.0/27    10.0.0.2                 0    100      0 64512 64512 i

Because the next hop is now reachable, there is now a route in route table for Provider 1 for the 12.12.12.0/27 network. The same thing should be done for the iBGP session between Mine1 and Mine2 as well. This problem could also be solved by using an Interior Routing Protocol as well. At this point if you are following along you can start Mine 1 again.

Configuring the Default Gateway:

Since the Mine 1 and Mine 2 routers are not getting full Internet tables from the provider, they will need a default gateway. BGP can supply a default gateway to its neighbors. To configure this is easy, you just use the default-originate command on each of the Provider routers.

Provider1(config)#router bgp 1500
Provider1(config-router)#neighbor 172.16.8.2 default-originate

Provider2(config)#router bgp 1500
Provider2(config-router)#neighbor 172.16.8.6 default-originate

Setting the Preferred Route:

The other objective I stated is that I want Mine 1 to be the preferred router as long as it is up and running. To accomplish this I use two tools, local-preference to set the preferred egress path from network, and AS_PATH appending to tell AS 1500 the preferred ingress route to use.

A higher local preference means the path is more favorable. For this portion, I have Mine 1 tell Mine 2 that Mine 1 is best way to go. This is done with a route map:

Mine1(config)#route-map LOCALPREF permit 10
Mine1(config-route-map)#set local-preference 200
Mine1(config-route-map)#exit
Mine1(config)#router bgp 64512
Mine1(config-router)#neighbor 172.16.8.1 route-map LOCALPREF in

This sets it so Mine1 will mark any routes it has learned about with a higher local preference when sending them to Mine 2:

Mine2#show ip bgp
...
   Network          Next Hop            Metric LocPrf Weight Path
*>i0.0.0.0          192.168.8.1              0    200      0 1500 i
*                   172.16.8.5               0             0 1500 i
* i12.12.12.0/27    192.168.8.1              0    100      0 i
*>                  0.0.0.0                  0         32768 i

So now if any egress traffic ends up Mine 2 that would be use the default route, it will go through Mine 1.

To tell the Provider routers that Mine 1 is preferred, we have Mine 2 prepend the AS number again so routes coming from it have a longer AS_PATH and therefore will be less preferred. Again this is done with a route map:

Mine2(config)#route-map AS_PATH_APPEND permit 10
Mine2(config-route-map)#set as-path prepend 64512
Mine2(config-route-map)#exit
Mine2(config)#router bgp 64512
Mine2(config-router)# neighbor 172.16.8.5 route-map AS_PATH_APPEND out

Now on Provider 2, the routes that Mine 2 announced will seem longer than the route to Mine 1 from Provider 2 so the route to 12.12.12.0/27 via Provider 1 is preferred:

Provider2#show ip bgp
...
   Network          Next Hop            Metric LocPrf Weight Path
*>i12.12.12.0/27    10.0.0.1                 0    100      0 64512 i
*                   172.16.8.6               0             0 64512 64512 i

To get a feel for all of this, I recommend taking down the routes and/or interfaces, and then running traceroutes to see how all the traffic then goes once the BGP updates have been received by neighboring routers (BGP isn’t that fast, so wait for the log messages to show up).

The HSRP Configuration:

A basic HSRP set up is actually pretty simple. Each LAN interface gets its own IP and they share a Virtual IP that computers on the LAN use as their gateway. The virtual IP is held by one router at a time only as long as both routers can still send broadcasts to each other over the LAN. In this lab, the virtual gateway IP address is 192.168.1.1:

Mine1(config)#int FastEthernet2/0
Mine1(config-if)#ip address 192.168.1.2 255.255.255.0
Mine1(config-if)#standby ip 192.168.1.1
Mine1(config-if)#standby priority 110
Mine1(config-if)#standby preempt delay reload 20
Mine1(config-if)#standby track FastEthernet0/0

Mine2(config)#int F2/0
Mine2(config-if)#ip address 192.168.1.3 255.255.255.0
Mine2(config-if)#standby ip 192.168.1.1
Mine2(config-if)#standby priority 109
Mine2(config-if)#standby track FastEthernet0/0

So each interfaces does get it’s own IP, but the virtual IP is shared by both. The track command makes it so that if the WAN side of either of the Mine routers goes down the gateway will follow. I have set it up so this doesn’t need to happen because traffic can enter Mine 1 on the LAN side, and leave Mine 2 on the WAN side, but I figure it makes more sense to have them stay together. The preempt command makes it so that if Mine 1 has failed, but comes back up, it will become primary again. The higher priority also makes sure that it is primary.

Conclusion:

The parts that are left out of the lab are a server with bonded nics, and the switches. The switches should be connected together with a couple of connections and be running some version of Spanning Tree Protocol (STP). The simplest set up for the bonded NICs if you are using Linux would be Active-Backup mode as it doesn’t require special configuration on the switches. I included the basic NAT configuration in the complete router configurations, however, stateful NAT would be an option for more rapid fail over because both routers would share the NAT table. With this setup there is no longer a single point of failure on the network at the device, port, or cable level. A router, switch, or network card can fail and the network should recover on its own.

I remotely administer Cisco routers, which can be a bit stressful since I need make sure not lock my self out by do something like removing a NAT command, editing ACL, or screwing up a VPN tunnel. A Cisco support person pointed out to me that I can use the reload command to schedule reboots, so if I lock myself out, I just have to wait until that timer runs out. If I don’t need it, I can cancel the scheduled reload. So, before you start running, copy the running configuration if you are happy with it using ‘copy run start’. Then you can use this trick as follows:

Lab1#copy run start
Destination filename [startup-config]?
Building configuration...
[OK]
Lab1#reload in 8
Reload scheduled in 8 minutes by console
Reload reason: Reload Command
Proceed with reload? [confirm]y
Lab1#
Lab1#show reload
Reload scheduled in 7 minutes by console
Reload reason: Reload Command
Lab1#reload in 12
Reload scheduled in 12 minutes by console
Reload reason: Reload Command
Proceed with reload? [confirm]y
Lab1#show reload
Reload scheduled in 11 minutes by console
Reload reason: Reload Command
Lab1#reload cancel
***
*** --- SHUTDOWN ABORTED ---
***
Lab1#show reload
No reload is scheduled.
Lab1#

Notice in line 13 you can reset or bump up the timer. And you can always use ‘show reload’ to see how much time you have. Of course, now you have to be careful not to let the timer run out or forget to remove it.