Kyle Brandt

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.

Introduction:
A common practice in networks is to have at least two Exchange servers, a front-end server in the demilitarized zone (DMZ, perimeter network in Microsoft terminology) and a back-end server in the company’s main network.  The front-end server hosts the public SMTP server and web mail.  The back-end server hosts the actual mail (information stores).  There are two firewalls, one between your DMZ and your own network, and the second is between the DMZ and the Internet.

Although the firewall rules are well documented on the web, I ran into a couple of blocks when moving the Exchange front-end server into the DMZ.  I hope in sharing what I encountered helps others find doing the same thing a little less frustrating. My instructions will be specific to my experience in doing this, and is certainly not the only way to do it.

Planning the Firewall Rules:
As I mentioned in previously there are two firewalls in this setup. One is between the Internet and the DMZ and the other is between the DMZ and the internal network. In this example both the firewalls are just the Access Control Lists ( ACLs ) on the Internet interface and the DMZ interface of a Cisco router. The the front-end server is also behind Network Address Translation ( NAT ), so the server gets assigned a local IP.

The logical layout is how to think about the set up.  Firewall 1 is actually an inbound ACL on the Gig 0/0 interface and Firewall 2 is and inbound ACL on the Gig 0/1 interface.  In this usage of inbound, ‘in’ means heading into the interface ( see the actual layout ) and not ‘inbound’ in the sense of inbound traffic from the Internet. Firewall 1 is the firewall between the front-end server and the Internet. Firewall 2 is the firewall between the front-end exchange server and the primary domain controller as well as the back-end Exchange server. The rules on Firewall 2 assume you have bound remote procedure call ( RPC ) to specific port, which I will talk about more in the section about configuring the domain controller. The rules for Firewall 1 use the public Internet IP because that is in front of the NAT, in my example the public IP is 74.125.45.100 and it gets translated to 172.16.1.2 .

Gig 0/0 ACL in ( Firewall 1 ):
permit tcp any host 74.125.45.100 eq 25
permit tcp any host 74.125.45.100 eq 80
permit tcp any host 74.125.45.100 eq 110
permit tcp any host 74.125.45.100 eq 143
permit tcp any host 74.125.45.100 eq 443
Gig 0/1 ACL in ( Firewall 2 ):
permit tcp host 172.16.1.2 host 10.10.1.51 eq 25
permit tcp host 172.16.1.2 host 10.10.1.51 eq 80
permit tcp host 172.16.1.2 host 10.10.1.51 eq 143
permit tcp host 172.16.1.2 host 10.10.1.51 eq 110
permit tcp host 172.16.1.2 host 10.10.1.51 eq 691
permit tcp host 172.16.1.2 host 10.10.1.50 eq 88
permit udp host 172.16.1.2 host 10.10.1.50 eq 88
permit tcp host 172.16.1.2 host 10.10.1.50 eq 389
permit udp host 172.16.1.2 host 10.10.1.50 eq 389
permit tcp host 172.16.1.2 host 10.10.1.50 eq 3268
permit tcp host 172.16.1.2 host 10.10.1.50 eq 53
permit udp host 172.16.1.2 host 10.10.1.50 eq 53
permit tcp host 172.16.1.2 host 10.10.1.50 eq 135
permit tcp host 172.16.1.2 host 10.10.1.50 eq 12125


Active Directory Changes:
There were three changes I had to make in Active Directory. The first was to change the DNS entries for the mail servers. The second, which took me sometime to figure out, was to add the subnet to ‘Active Directory Sites and Services’. I had to do this because this was the first Windows server being deployed in the DMZ. To do this go to Control Panel :: Administrative Tools :: Active Directory Sites and Services :: Right-Click Subnets :: New Subnet and then for our example add ‘172.16.1.1/24′ and assign to whatever site it it is in. You may also need to give it time to replicate. The third change is to bind RPC replication to a specific port so you don’t have to open the firewall between the front-end and back-end servers as much. I chose to bind it to port 12125, if you don’t do this you will have open up TCP ports 1024 and above on the firewall. To bind RPC you need two registry entires, see: http://support.microsoft.com/kb/224196

Changes on the Front End Mail Server:
Besides Assigning the new IP to the front end exchange server, you might need to bind each service to this new IP. This wasn’t apparent to me because I could still connect to the SMTP and 443 ports but I got disconnected immediately. This indicates that even though the service is set not to be listening on that IP, it does listen and just disconnects if the first packets of the session are not destined for the IP the service is bound to. I can’t image how someone at Microsoft thought that this would be a good way to design the network stack on their operating system but that seems to be the way it works. To adjust what IP webmail (ports 80 and 443) are bound to, go to: Control Panel :: Administrative Tools :: Internet Information Services ( IIS ) Manager :: Local Computer :: Web Sites :: Right Click which ever web sites is for web mail :: Web Site Tab and then change the IP to whatever the new IP is for your front-end server, in our example, 172.16.1.2. Then to change the SMTP port and other service are bound to, go to: Exchange System Manager :: Administrative Groups :: Your Administrative Group ( i.e. First Administrative Group ) :: Servers :: The Front-End Server :: Protocols and then expanded each protocol, right click the virtual server, and change the IP in the General Tab.

Changes on the Back End Mail Server:
When I did this I did not have to make any changes to the back end server, but you can check the references section for things you may need to do. Also, this is windows, so you should probably reboot the server for good measure, and maybe several times.

Conclusion:
Although your experience may be different I hope this helps people trying to do a similar thing.

References:
http://technet.microsoft.com/en-us/library/aa997436(EXCHG.65).aspx
http://windowsitpro.com/article/articleid/46571/what-ports-do-you-need-to-open-to-allow-communication-between-a-microsoft-exchange-server-back-end-server-and-an-exchange-front-end-server.html

Introduction:
GNS3 is a graphical network simulator that is integrated with the Cisco router emulator Dynamips.  In this tutorial I will explain how to connect your Linux host to an emulated 7200 series router, then that router to another 7200 router, and finally that second router will be connected to a Linux VM running in VMware Server.  In this lab environment we will also configure access control lists ( ACLs ), Network Address Translation ( NAT ), and a site-to-site Internet Security Protocol Virtual Private Network ( IPsec VPN ) tunnel between the two routers in Part 2.

Pre-Requists:
• VMware Server
• A Cisco 7200 router firmware image ( You will have to get this on your own, I don’t want to step on Cisco’s copyright )
• This tutorial assumes the Linux host and the virtual machine are running Ubuntu 8.10

Getting Started:
1. Install GNS3: sudo apt-get install gns3 dynamips
2. Start GNS3 and follow the setup wizard, you will want to load the 7200 .bin files
3. Install VMware server: You will need to patch it see here ( http://ubuntu-tutorials.com/2008/11/01/vmware-server-107-on-ubuntu-810-intrepid-2627-7-generic/ ) before installing.  Make sure to allow host-only networking ( You can chose to install all the different networking options ).
4. Create a Ubuntu 8.10 VM with host only networking in VMware server.

Setting up our layout in GNS3:
1. Start gns3 as root: gksudo gns3
2. Create two Cisco 7200 by dragging the icon over from the left.
3. Right click each router, click on the slots tab, and change slot0 to C7200-IO-2FE and slot1 to PA-2FETX ( this will give each router 4 Fast Ethernet interfaces ).
4. Right click each router and change the host names to lab1 and lab2.

Basic configuration for each router:
1. Right click lab1 and chose start.
2. Right click lab1 and chose console.
3. You should see ‘Self Decompressing the Image’, we are now in the emulated IOS terminal connection.

a. Chose yes for ‘initial configuration dialog’.
b. Chose yes for ‘basic management setup’.
c. Call the router lab1.
d. Enter passwords when asked.
e. chose no to SNMP management.
f. Chose FastEthernet0/0 for ‘management network from the above interface summary’.
g. Chose Use the 100 Base-TX (RJ-45) connection.
h. Select no for full duplex.
i. Chose yes to Configure IP on that interface.
j. For the interface IP, chose a s /24 subnet that is not being used in your network or by VMWare ( run ifconfig on your host machine and look at what the vmnet interfaces are to see what VMWare is using ). For my example it is going to be 192.168.1.1
k. Accept the 255.255.255.0 subnet mask.
l.  Press 2 to save.
m. Then go into enable mode by typing ‘enable‘ and then type ‘copy run start‘.
n. Save your work so far in GNS3 by choosing ‘Save as’ and also extract all your configurations by pressing the yellow arrow.

4. Repeat steps 1-3 above for the lab2 router but for step j:

i. Start your VMware Linux VM that was set up with host only networking.
ii. Look at what IP you have  been given, for my example it is was 192.168.21.128
iii. Configure the F0/0 on this router to match that network, in my case it would be 192.168.21.1 with a subnet mask of 255.255.255.0

Getting the Routers to talk to each Other:
1. On lab1:

a. Open up the console for lab1.
b. Run the following commands in the lab1 console:
enable
conf t
int F1/0
ip address 12.12.12.1 255.255.255.252
< ctrl-z >
copy run start

2. On Lab2:

a. Do the same as above but with: ip address 12.12.12.2 255.255.255.252

3. In GNS3 click the icon that looks like an Ethernet cable, chose fast ethernet and connect f1/0 of lab1 to f1/0 of lab2 by clicking on a router and then clicking the other router. Expand the ‘Topology Summary’ for each router so you can verify that the correct interfaces are connected to each other. Do verify that you got the interfaces specified, I found this to be a bit buggy to get the interfaces I wanted.
4. Log into the console of each router and ping the other to make sure the connection is working.

Connect your Host Machine to the Virtual Network:
1. In GNS3 Create a cloud by dragging it from the left.
2. Right click the cloud and chose configure.
3. Click on the NIO TAP tab, type in ‘tap0′ to the field and click ‘Add’ and then ‘Apply’.
4. From your Linux host open up a terminal:

a. Install the utilities that let you create tap interfaces: sudo apt-get install uml-utilities
b. Become Root: sudo su -
c. Load the tun module: modprobe tun
d. Create the tunnel interface: tunctl
c. Give the tap interface an IP that matches your network for lab1’s f0/0, i.e. : ifconfig tap0 192.168.1.100 netmask 255.255.255.0 up
d. If using iptables you may need to add some rules like: iptables -I INPUT 1 -i tap0 -j ACCEPT

5. In GNS3 click the Ethernet icon and select fast ethernet.  Then click Lab1 first and the cloud and select the tap0 interface.
6. Verify you can reach the IP of Lab1’s FastEthernet 0/0 ip by pinging it from you Linux Host.

Connect your Virtual Machine to the Virtual Network:
1. In GNS3 create a cloud by dragging it from the left.
2. Right click the cloud and chose configure.
3. Click on the NIO ETHERNET tab and then ‘Linux Ethernet NIO’, select the vmnet interface that corresponds to the host only networking and click ‘Add’ and then ‘Apply’.  In my example it is vmnet1.
4. In a terminal on your Linux host note the IP of the vmnet interface of the previous step and then remove the ip by entering: sudo ifconfig vmnet1 0.0.0.0 #if vmnet1 was the interface from step 3. The IP is removed because that is the IP we gave the FastEthernet interface on Lab2.
5. In GNS3 connect the cloud to the cloud by clicking the Ethernet icon, selecting fast ethernet, clicking lab2, and then selecting the nio_linux_eth:vmnet1 interface of the cloud.
6. Verify that you can reach the IP of Lab2’s FastEthernet 0/0 by pinging it from the Linux VM.
7. To be able to reach the VM from the Linux host throught the virtual network add the following route to the Linux host: sudo route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.1.1

Conclusion:
You should now have a basic network with two routers that you can practice with.  In the second article we will configure NAT, IPsec, and ACLs on the routers.  Please do comment on any confusing steps in this tutorial, I wrote it after doing this myself and not as I did it, so something might be missing.

Reference:
http://www.blindhog.net/tutorials/linux-loopback-tap0.htm
Lab1 Router Configuration
Lab2 Router Configuration

I was lucky enough to be loaned a couple of CISCO 1720 routers by my office today. Connecting to them was pretty straight forward.

What you will need:

1. A roll-over cable (aka Cisco Console Cable). These are usually RJ-45 on the router side and serial on the PC side.

2. If your computer doesn’t have a serial port (like mine) you can get a 9-pin D-sub serial to USB cable. I got the Gigaware cable from RadioShack for thirty dollars.

Get Connected:

The following worked for me with Hardy Heron installed on my MSI Wind.

1. Connect all the cables: USB — > Serial –> Crossover –> Console Port
2. Download and install Minicom: sudo apt-get install minicom
3. Make sure that the USB to serial cable is recognized. lsusb should list something like Bus 001 Device 002: ID 05ad:0fba Y.C. Cable U.S.A., Inc.
4. Type ls /dev/tty* to make sure /dev/ttyUSB0 or something similar is listed.

Update: In my search to reset the password to the router, I needed to send a break to the console. I was finally able to do this using GNU screen. Screen is easier than minicom, all you need to do is type screen /dev/ttyUSB0 instead of the remaining steps five through eight. I was then able to send my break using [meta-command]-B or [meta-command]-b (Not sure which it was).

5. Start minicom with minicom and hit CTRL-A and then O to open the options. (All commands in minicom start with CTRL-A, like GNU Screen).
6. Enter A to change the serial device setting to /dev/ttyUSB0 or whatever you found in step 4.
7. Select “Save setup as dfl”
8. Hit CTRL-A X to exit and then restart minicom, the port should be displayed as /dev/ttyUSB0
9. When it restarted all I had to do was hit enter to get the prompt of my CISCO 1720

I have seen a lot of posts out there about people having headaches connecting to Cisco VPNs using the Cisco VPN Client, mostly because they have trouble compiling it in Ubuntu Feisty Fawn. I recommend using the open source alternative vpnc. Vpnc works with the following according to the previous link:

• Cisco VPN concentrator 3000 Series
• Cisco IOS routers
• Cisco PIX / ASA Zecurity Appliances
• Juniper/Netscreen

Supported Authentications: Pre-Shared-Key + XAUTH, Pre-Shared-Key
Supported IKE DH-Groups: dh1 dh2 dh5
Supported Hash Algo (IKE/IPSEC): md5 sha1
Supported Encryptions (IKE/IPSEC): (null) (1des) 3des aes128 aes192 aes256
Perfect Forward Secrecy: nopfs dh1 dh2 dh5

If your workplace or school has given you .pcf file to use with your vpn, it shouldn’t be too hard to get you on your vpn:

1. Install the vpnc client: In the terminal enter “sudo apt-get install vpnc.” Or use the synaptic package manager.
2. Save this script to your hard drive without any extension (Such as .html). (This script was written by Stefan Tomanek, and updated by Wolfram Sang.)
3. Make the script executable by navigating to the directory you saved it in the terminal and type “chmod +x pcf2pvnc“.
4. Copy your pcf file to the directory of that script, in the terminal enter “./pcf2pvnc YourPcfFile.pcf NewPvncFile.conf” substituting YourPcfFile.pcf and NewPvncFile.conf with the appropriate file names for your files.
5. Finally, in the terminal enter “sudo vpnc NewPvncFile.conf“. If all goes well it will connect to your vpn server and ask you for your user name and password.