Showing posts with label CCNA. Show all posts
Showing posts with label CCNA. Show all posts

Wednesday, November 23, 2016

IPv6 Intro: Access Control Lists

Way back in CCNA Lesson 13, we introduced Access Control Lists (ACL's) on Cisco routers. Since Cisco has re-vamped the CCNA test to include IPv6, it is probably worth adding another lab to revisit ACL's when using IPv6. The good news is, ACL's in IPv6 are very similar to IPv4 ACL's, but not quite as complicated. Forget all of that jazz about named ACL's, numbered ACL's, standard ACL's and extended ACL's -- in IPv6, you get named ACL's...period. Ready to take a peek? Let's get started!

Suppose you have two routers, R1 and R2. R1 has two clients connected to it, Clone 1 and Clone 2. R2 has two servers connected to it, CentOS and CentOS_Clone. Since I happen to like coffee, and I don't like remembering long strings of hexadecimal digits, I have based my addressing scheme in this lab on the base address 2001:C0:FFEE::x/y :


Since we are using SLAAC to configure our host IP addresses, we will still have to deal with some ugly addressing, but at least the routers won't be too terribly bad.

So...suppose we want to allow Clone 2 to log in to our routers, but we don't want any other network hosts to log in. Just as we would do in IPv4, we will create an access list to filter incoming traffic, then apply it to the "line vty 0 4" configuration. First, we need the IPv6 address of Clone 2:


...then, we create an access control list to permit this traffic:
R2(config)#ipv6 access-list ?
  WORD        User selected string identifying this access list
  log-update  Control access list log updates

R2(config)#ipv6 access-list PROTECT-CP ?
  <cr>

R2(config)#ipv6 access-list PROTECT-CP
R2(config-ipv6-acl)#permit ipv6 host 2001:C0:FFEE:1:A00:27FF:FE47:85D3 host 2001:C0:FFEE:254::2
R2(config-ipv6-acl)#

Then, we apply the ACL to the "line vty 0 4" configuration:
R2(config-ipv6-acl)#line vty 0 4
R2(config-line)#access-class PROTECT-CP in

Pretty easy! Let's test it...:


Good...but does the ACL deny traffic from other hosts? Let's check it from Clone 1 and see:


Perfect! Let's see if we can control access to the web servers behind R2 with ACL's. We'll start by creating a new ACL to filter HTTP traffic to CentOS6, but not to CentOS6_Clone:
R2(config)#ipv6 access-list NO-HTTP-ACCESS
R2(config-ipv6-acl)#deny tcp host 2001:C0:FFEE:1:A00:27FF:FED3:7C8F host 2001:C0:FFEE:2:A00:27FF:FE7D:F08D eq 80
R2(config-ipv6-acl)#permit ipv6 any any
R2(config-ipv6-acl)#exit
R2(config)#int fa1/0
R2(config-if)#ipv6 acc?
% Unrecognized command
R2(config-if)#ipv6 ?  
IPv6 interface subcommands:
  address         Configure IPv6 address on interface
  cef             Cisco Express Forwarding for IPv6
  dhcp            IPv6 DHCP interface subcommands
  enable          Enable IPv6 on interface
  mfib-cef        MFIB CEF-based forwarding
  mld             interface commands
  mtu             Set IPv6 Maximum Transmission Unit
  nd              IPv6 interface Neighbor Discovery subcommands
  ospf            OSPF interface commands
  pim             PIM interface commands
  redirects       Enable sending of ICMP Redirect messages
  rip             Configure RIP routing protocol
  traffic-filter  Access control list for packets
  unnumbered      Preferred interface for source address selection
  verify          Enable per packet validation

Despite so much of our understanding of IPv4 transferring directly (or nearly so...) to IPv6, this is where things change a little. In IPv6, we use a different statement to apply an IPv6 ACL to an interface:
R2(config-if)#ipv6 traffic-filter NO-HTTP-ACCESS in
R2(config-if)#exit

Don't ask me; I didn't create the syntax ;)

Let's see if it works. On Clone 1:


As you can see in the screenshot, there are two browser windows open. In the browser window trying to connect to the web server that we filtered on R2 (IPv6 address ...F08D), the browser has returned an error message stating that it cannot create a connection to the web server. In the browser window connected to the second web server (IPv6 address ending in ...31B9), we are able to load an image gallery. "But," I can hear you object, "all that proves is that we have blocked access to a particular server. The point was to block access to that server from a selected host." So, let's see if we can access both servers from a second client:


As you can see, Clone 2 has unrestricted access to both web servers, proving that the ACL is indeed restricting access from Clone 1 to CentOS6, as required (yes, I could have simply removed the ACL from the router before trying Clone 2, and the only way you'll know for sure is to fire up your own router or simulator and try it yourself! ;)

Thursday, October 27, 2016

IPv6 Intro: BGP, OSPF and IPv6...or Maybe Just EIGRP and IPv6, smh

Being a network engineer is kind of like being Sisyphus. Just when you think you you're starting to get to the top of your game, someone moves the target on you. In fact, a writer by the name of Spencer Johnson (M.D.) wrote a book on that subject not quite 20 years ago, and even though I've never read the book, I'd guess that it's at least as relevant today as it was then. Case in point, even though I've used IPv4, OSPF, and EIGRP professionally for years, I don't have a lot of professional experience with IPv6 or BGP. To address that problem, I set up the following network in GNS3 for playing with IPv4 and IPv6 with multiple routing protocols on emulated Cisco 7200 routers:

We have R1, R2 and R3 as routers within an autonomous system, R4 a random (IPv4-only) Internet router and R5 as another (IPv6-only, this time) random Internet router. My intent was to set up BGP peering between R1, R4 and R5, and to have R1, R2 and R3 share routes via OSPF. Sounds easy enough, right?

Hahaha...no.

In a previous lab, we set up OSPFv3 (OSPF for IPv6) on Cisco 3640 routers, so I used those instruction to (try to) set up OSPFv3 on the 7200 routers:
R1(config)#int gig0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
                   ^
% Invalid input detected at '^' marker.

R1(config-if)#ipv6 o?
% Unrecognized command
R1(config-if)#ipv6 ?
IPv6 interface subcommands:
  address             Configure IPv6 address on interface
  authentication      authentication subcommands
...
  multicast           multicast
  nat                 Enable IPv6 NAT on interface
  nd                  IPv6 interface Neighbor Discovery subcommands
  next-hop-self       Configures IP-EIGRP next-hop-self
  policy              Enable IPv6 policy routing
  redirects           Enable sending of ICMP Redirect messages
  rip                 Configure RIP routing protocol
...

Okay...is OSPFv3 not supported on this router? As it turns out, I think it actually is, but I'll save that for another lab.

Edit: no, it's not. I mean, it is, but it isn't. The "hooks" are there to configure OSPFv3 using "ipv6 ospf <process ID>" in global configuration, but you have to have an Advanced IP Services image to run it. The SP Services image I am running isn't licensed for it, because after all, what service provider would run OSPF on their network (answer: every one I've ever worked at), grrr...

For now, I decided to try to set up EIGRP for IPv6 since, 1) it *is* supported on the 7200, and 2) it did not seem to be supported on the 3640's:
R1(config)#int gig0/0
R1(config-if)#ipv6 router eigrp 10
R1(config-rtr)#int gig1/0
R1(config-if)#ipv6 router eigrp 10
R1(config-rtr)#exit
R1(config)#exit
R1#sho run int gig0/0
Building configuration...

Current configuration : 201 bytes
!
interface GigabitEthernet0/0
ip address 66.223.227.5 255.255.255.252
duplex full
speed 1000
media-type gbic
negotiation auto
ipv6 address 2001:C0:FFEE:2::1/126
ipv6 enable
ipv6 eigrp 10
end
R1#sho ipv6 route
IPv6 Routing Table - Default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       M - MIPv6, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
C   2001:C0:FFEE::/126 [0/0]
     via GigabitEthernet1/0, directly connected
L   2001:C0:FFEE::1/128 [0/0]
     via GigabitEthernet1/0, receive
C   2001:C0:FFEE:2::/126 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:C0:FFEE:2::1/128 [0/0]
     via GigabitEthernet0/0, receive
LC  2001:C0:FFEE:254::1/128 [0/0]
     via Loopback0, receive
C   2016:FA:1::/64 [0/0]
     via FastEthernet6/0.20, directly connected
L   2016:FA:1::1/128 [0/0]
     via FastEthernet6/0.20, receive
L   FF00::/8 [0/0]
     via Null0, receive
R1#

Weird...why are none of my EIGRP routes showing up? I could ping across the interfaces and my IPv4 routing protocols were working as expected, but I could not get EIGRP in IPv6 to form neighbor adjacencies. What gives?

I started troubleshooting EIGRP using essentially the same toolkit I would use for IPv4...:
R1#sho ipv6 eigrp 10 neigh
IPv6-EIGRP neighbors for process 10
% EIGRP 10 is in SHUTDOWN
R1#sho ipv6 eigrp 10 int
IPv6-EIGRP interfaces for process 10
% EIGRP 10 is in SHUTDOWN
R1#

"EIGRP...is in SHUTDOWN?" I'm not familiar with that error message. WWGS ("What Would Google Say")? I quickly found a couple of tutorials on-line which showed that setting up EIGRP in IPv6 on a 7200 is a little different than setting OSPFv3 on a 3640 (go figure). Whereas OSPFv3 on a 3640 is entirely configured on the interface, EIGRP for IPv6 is a mix of interface-level commands and global config commands:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ipv6 router eigrp 10
R1(config-rtr)#router-id 10.254.254.1
R1(config-rtr)#redistribute connected
R1(config-rtr)#passive-int default
R1(config-rtr)#no passive-int gig0/0
R1(config-rtr)#no passive-int gig1/0
R1(config-rtr)#no shut
02:35:27: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::C802:7FF:FE00:70 (GigabitEthernet1/0) is up: new adjacency
R1(config-rtr)#
02:35:38: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 10: Neighbor FE80::C801:6FF:FEF0:70 (GigabitEthernet0/0) is up: new adjacency
R1(config-rtr)#exit
R1(config)#exit

After making eseentially the same changes on R2 and R3 (the interface names were different, but...), I saw my routes as expected:
R1#sho ipv6 route
IPv6 Routing Table - Default - 12 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       M - MIPv6, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
C   2001:C0:FFEE::/126 [0/0]
     via GigabitEthernet1/0, directly connected
L   2001:C0:FFEE::1/128 [0/0]
     via GigabitEthernet1/0, receive
C   2001:C0:FFEE:2::/126 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:C0:FFEE:2::1/128 [0/0]
     via GigabitEthernet0/0, receive
D   2001:C0:FFEE:3::/64 [90/28416]
     via FE80::C802:7FF:FE00:70, GigabitEthernet1/0
LC  2001:C0:FFEE:254::1/128 [0/0]
     via Loopback0, receive
D   2001:C0:FFEE:254::2/128 [90/130816]
     via FE80::C801:6FF:FEF0:70, GigabitEthernet0/0
D   2001:C0:FFEE:254::3/128 [90/130816]
     via FE80::C802:7FF:FE00:70, GigabitEthernet1/0
D   2001:C0:FFEE:2222::/64 [90/28416]
     via FE80::C801:6FF:FEF0:70, GigabitEthernet0/0
C   2016:FA:1::/64 [0/0]
     via FastEthernet6/0.20, directly connected
L   2016:FA:1::1/128 [0/0]
     via FastEthernet6/0.20, receive
L   FF00::/8 [0/0]
     via Null0, receive
R1#

Well that was more cumbersome than it should have been, but <shrug>. At least we've got EIGRP working now. BGP via IPv4 is nothing new, so I won't waste a lot of time discussing the BGP configuration for R1-R4. However, the IPv6 configuration between R1 and R5 had me swearing at Cisco:
R1(config)#router bgp 65511
R1(config-router)# neighbor 2016:FA:1::5 remote-as 65515
R1(config-router)# address-family ipv6
R1(config-router-af)#  network 2001:C0:FFEE:254:0:0:0:1/128
R1(config-router-af)#  network 2001:C0:FFEE:254:0:0:0:2/128
R1(config-router-af)#  network 2001:C0:FFEE:254:0:0:0:3/128
R1(config-router-af)#  network 2001:C0:FFEE:2:0:0:0:0/126
R1(config-router-af)#  network 2001:C0:FFEE:0:0:0:0:0/126
R1(config-router-af)#  network 2001:C0:FFEE:2222:0:0:0:0/64
R1(config-router-af)#  network 2001:C0:FFEE:3:0:0:0:0/64
R1(config-router-af)#  neighbor 2016:FA:1::5 activate
% BGP context not been initialized properly.
R1(config-router-af)# exit
R1(config-router)#exit
R1(config)#exit
R1#sho bgp ipv6 unicast neighbors

R1#sho run | begin router bgp
router bgp 65511
bgp router-id 10.254.254.1
bgp log-neighbor-changes
neighbor 2016:FA:1::5 remote-as 65515
neighbor 209.193.4.4 remote-as 65514
!
address-family ipv4
  neighbor 209.193.4.4 activate
  no auto-summary
  no synchronization
  network 10.254.254.1 mask 255.255.255.255
  network 10.254.254.2 mask 255.255.255.255
  network 10.254.254.3 mask 255.255.255.255
  network 66.223.224.0 mask 255.255.255.224
  network 66.223.224.32 mask 255.255.255.224
  network 66.223.227.0 mask 255.255.255.252
  network 66.223.227.4 mask 255.255.255.252
  network 209.193.4.0
exit-address-family
!
ip forward-protocol nd
...

Wait, where's my "address-family ipv6" entries, and what's with that "BGP context has not been initialized properly" error message? I went back to the Great Oracle of Google, where I found this little tidbit of information:
Q. Error message: "% BGP context not been initialized properly." when Configuring neighbor under address-family IPv6

A. The issue is with the feature set. If the feature set is SP services, the following services are not supported.

  • IPv6 Routing: Multiprotocol BGP Extensions for IPv6
  • IPv6 Routing: Multiprotocol BGP Link-local Address Peering

To use these features,change the feature set to Advanced Enterprise Services.

Okay, let's check the code version on my routers:
R1#sho ver
Cisco IOS Software, 7200 Software (C7200-SPSERVICESK9-M), Version 12.4(24)T4, RELEASE SOFTWARE (fc2)

Well, <expletive deleted>! Since I don't have an Advanced IP Services image laying around, that pretty much kills the BGP portion of this lab for now.

I went ahead and removed the BGP portion and played with EIGRP across the network, but I'm slightly miffed by the fact that I couldn't do any testing with BGP or OSPF under IPv6, since IPv6 is now a part of certification testing. With adoption of IPv6 "in the wild" still lagging, it would be nice to be able to mock such networks up in a lab without spending a fortune in hardware and software licensing.

Sunday, October 23, 2016

Lesson 16: VRRP

In the last lesson that I wrote while working on my CCNA certification, I introduced the concept of router redundancy via a Cisco proprietary protocol known as HSRP, or "Hot Standby Router Protocol." However, HSRP is not the only way to create a redundant data connection for your office. In this lab, we'll look at a second, similar protocol known as VRRP, or "Virtual Router Redundancy Protocol."

Disclaimer:
The configuration document I used to play with VRRP in this lab didn't work exactly as advertised on the routers I was emulating. In fairness, Cisco 3640 routers are decidedly, ummmm, "old-school" (read that: obsolete), so it's entirely possible that the syntax has changed on more modern platforms that are running more recent versions of IOS. However, what I present here should be close enough to get you started. Here (pdf) is the link to the Cisco document with the slightly different syntax.

As usual, we'll start with the network diagram:


We'll set up lo0 and fa1/0 on R1 and R2 as normal, R4 exists only to act as a DHCP server, and R3 serves as a destination network provider. We'll establish OSPF between R1, R2 and R3, using network statements for 100.64.1.0/30 and 100.64.2.0/30 and using "redistribute connected subnets." On our client, "Knoppix Clone 1," we'll set the default gateway to 100.64.0.1/29. So far, nothing unexpected, right?

Just to recap, the problem we want to solve is, what happens when fa0/0 goes down on our default gateway? If R2 did not exist in this network, then R1 is our single point of failure. If we lose R1, then the clients on our LAN can no longer reach the servers hanging off of R3. To address this, we set up two routers in parallel so that we have a redundant path to R3. However, there is no way to tell a client PC (or router or...) to use multiple default gateways. HSRP and VRRP were designed to address this problem. In both scenarios, you configure a single default gateway on your client network, then use either HSRP or VRRP to shuffle that default gateway address between multiple routers. To set it up, you...:

  1. Enter configuration mode;
  2. Switch to the interface facing your client LAN;
  3. Add an IP address within the subnet of your client LAN;
  4. Configure a meaningful description of the VRRP group;
  5. Configure the client's default gateway address in the VRRP group;
  6. Set the VRRP priority for the router (a higher value takes priority over a lower value);
  7. Set the VRRP advertisement and preempt delay timers.


Here's how the configuration looks on R1...:
interface FastEthernet0/0
ip address 100.64.0.2 255.255.255.248
vrrp 10 description VRRP Group
vrrp 10 ip 100.64.0.1
vrrp 10 preempt delay minimum 3
vrrp 10 priority 254
end

...and on R2:
interface FastEthernet0/0
ip address 100.64.0.3 255.255.255.248
vrrp 10 description VRRP Group
vrrp 10 ip 100.64.0.1
vrrp 10 preempt delay minimum 3
vrrp 10 priority 128
end


NOTE:
I also added the following line to the config...:
R1(config-if)#vrrp 10 timers advertise 1

...to set VRRP to send an "advertisement" every second. However, this is the default behaviour for VRRP, and therefore, it didn't show up in the config until I changed it for testing. Anyway, does it work?

Let's traceroute from R4 to R3:
R4#traceroute 10.254.254.3

Type escape sequence to abort.
Tracing the route to 10.254.254.3

  1 100.64.0.2 4 msec 4 msec 4 msec
  2 100.64.1.2 12 msec 8 msec 8 msec
R4#

Now, if I shut down fa0/0 on R1, I should see a short interruption in service, followed by R2 picking up the traffic:
R4#ping 10.254.254.3 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.254.254.3, timeout is 2 seconds:
!!!!!!!!!!!!!..!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 97 percent (97/100), round-trip min/avg/max = 4/11/36 ms
R4#traceroute 10.254.254.3

Type escape sequence to abort.
Tracing the route to 10.254.254.3

1 100.64.0.3 8 msec 4 msec 8 msec
2 100.64.2.2 8 msec 12 msec 8 msec
R4#

Notice how the first hop originally was 100.64.0.2, but now it's 100.64.0.3? VRRP has failed over the virtual 100.64.0.1 IP address from R1 to R2, which is reflected in the traceroute output.

With a little effort, we can see what's happening at the Ethernet level, too, and it's even more interesting. We'll start by verifying our configuration. R1 is currently the VRRP master (i.e., it's hosting the IP address 100.64.0.1), and R2 is the backup:
R1#sho vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Fa0/0              10  254 3007       Y  Master  100.64.0.2      100.64.0.1    
R1#
----------------------------------------------------------------------------

R2#sho vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Fa0/0              10  128 3500       Y  Backup  100.64.0.2      100.64.0.1    
R2#

First, we'll clear the arp table on Knoppix Client 1:

Now, we'll ping 10.254.254.3 (lo0 on R3) from Knoppix Clone 1:

Next, we shut down fa0/0 on R1, and verify that R2 is now the VRRP master:
R1#sho vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Fa0/0              10  254 3007       Y  Init    0.0.0.0         100.64.0.1    
R1#

----------------------------------------------------------------------------

R2#sho vrrp brief
Interface          Grp Pri Time  Own Pre State   Master addr     Group addr
Fa0/0              10  128 3500       Y  Master  100.64.0.3      100.64.0.1    
R2#

...and ping R3 again:

Hmmm...since the VRRP virtual MAC address moves with the router, that doesn't give us much insight into what was actually happening here. Fortunately, I was running tcpdump to capture the Ethernet frames while running this test. After exporting the PCAP file to Wireshark, we can get a little better understanding of what happened here.

Note:
To keep the Wireshark screen captures relevant, I filtered out some of the chatter. We configured VRRP to send advertisements every second, for example, so I filtered out the VRRP protocol data. These routers were also running CDP, so I filtered that as well.

At the very beginning of the capture, we can see Knoppix Client 1 ("CadmusCo_d3:7c:8f") send an arp request for 100.64.0.1, and we can see R1 (cc:00:2a:af:00:00) send an arp reply, stating that the VRRP virtual MAC address "00:00:5e:00:01:0a" is associated with 100.64.0.1:

Then, we ping R3 through R1. As you can see, we sent the ICMP request to the VRRP virtual MAC...:

...but received the reply from the MAC of fa0/0 on R1 (cc:00:2a:af:00:00):

At this point, we shut down fa0/0 on R1, and allowed R2 to take ownership of 100.64.0.1. Since VRRP also transports the virtual MAC, our next ping will still be sent to 00:00:5e:00:01:0a...:

...but this time, our reply has come from the MAC address of fa0/0 on R2 (cc:01:2a:af:00:00):

Because the MAC address doesn't change, we don't have to wait until the arp cache on connected devices times out for traffic to use the new path. This can be a serious problem, in some cases. For example, if you are using a Cisco ASA to connect to a (non-VRRP) "highly-available" system, the default arp cache timeout period is FOUR HOURS, which means it can take up to four hours for your "highly-available" (cough) system to recover from a failover! This isn't just an academic, theoretical point, either. I am currently working a trouble ticket in my day job where this is exactly what's happening. Unfortunately, just shortening the arp cache timeout period can drive up CPU load and memory requirements on busy devices, so there is a balancing act to be found between automatic fail-over times and system resource utilization. VRRP neatly solves that problem by sidestepping the whole issue.

Monday, September 26, 2016

IPv6 Intro: Global Unicast Address, Link-Local Addresses, and a Brief Intro to Static Routing

In the last lab, we configured a link between R1 and R2, using the IP addresses "2001:co:ffee::4:1" and "2001:co:ffee::4:2," respectively.  Let's try something:
R1#sho ipv6 interface brief
FastEthernet0/0            [up/up]
    FE80::CE00:6BFF:FE8E:0
    2001:C0:FFEE::4:1
Loopback0                  [up/up]
    unassigned
R1#

Well, that's odd! I don't know about you, but I only recall configuring a single IPv6 address on Fa0/0 on R1, but the "sho ipv6 interface brief" command is displaying two addresses.

Actually, it's not odd at all. When you enable IPv6 on an interface, it automatically configures a special class of IPv6 addresses on the interface. Notice how the extra address begins with "FE80?" An IPv6 address that begins with FE80 is a "link-local" address, and they are automatically configured on every interface using IPv6. The IPv6 address that we manually added to the routers is called a "global unicast" address. At this point, you are probably wondering why we bothered to assign an IPv6 address to the interface if the router would automatically assign one, too. There's a hint buried within the names of these address types: "Link-local" and "global-unicast." "Link-local" addresses are locally scoped (where "locally" means local to that one interface), whereas "global-unicast" addresses are, well, globally-scoped. Try to ping the link-local address on R1 from R2:
R2#ping ipv6 fe80:0:0:0:ce00:6bff:fe8e:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/16/36 ms
R2#

Interesting...notice how the router prompted you to specify an output interface? Since link-local addresses are locally-scoped to one specific interface, you have to specify which interface the ping command should use to reach the destination address. Just for giggles, let's add a new interface, Fa1/0, to R2, and connect a third router to that interface:



We'll add the new IPv6 addresses on both R2 and R3 as we've done in the past, and we'll add a static route so that R3 knows how to reach the 2001:co:ffee::4:0/126 network:
R3(config)#ipv6 route 2001:00c0:ffee:0:0:0:4:0/126 2015:0:0:0:0:0:0:1
R3(config)#exit
R3#ping ipv6 2001:00c0:ffee:0:0:0:4:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/36 ms
R3#

Good! Let's add a static route for the link-local address on R2, Fa0/0:
R3(config)#ipv6 route fe80:0000:0000:0000:ce01:6bff:fe8e:0/126 2015:0:0:0:0:0:0:1
% Invalid prefix
R3(config)#

"Locally-scoped" means you can't route these addresses. The only place they are valid is on the interface directly connected to the destination address. Therefore, you can't create a static route for a link-local address. Let's try one more thing, just for the fun of it:



We'll configure the subnet 2001::0/125 on each of these interfaces:
R1(config-if)#int fa0/0
R1(config-if)#ipv6 addr 2001:0:0:0:0:0:0:1/125
R1(config-if)#no shut

R2(config-if)#int fa0/0
R2(config-if)#ipv6 addr 2001:0:0:0:0:0:0:2/125
R2(config-if)#no shut

R3(config-if)#int fa0/0
R3(config-if)#ipv6 addr 2001:0:0:0:0:0:0:3/125
R3(config-if)#no shut

Now, let's make sure each router can ping the other two routers:
R1#ping ipv6 2001:0:0:0:0:0:0:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/36 ms
R1#ping ipv6 2001:0:0:0:0:0:0:3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/19/36 ms
R1#

(I've omitted the output from R2 and R3 for the sake of brevity, but I did test them)

What about the link-local interfaces? Can we ping them? Let's find out:
R1#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE00:6BFF:FE8E:0
    2001::1
<...snip...>
R2#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE01:6BFF:FE8E:0
    2001::2
<...snip...>
R3#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE03:6BFF:FE8E:0
    2001::3
<...snip...>

Now that we have the link-local addresses on each router, we'll try the ping test:
R1#ping ipv6 FE80::CE01:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/22/40 ms
R1#ping ipv6 FE80::CE03:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE03:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/36 ms
R1#
<...snip...>

R2#ping ipv6 FE80::CE00:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
R2#ping ipv6 FE80::CE03:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE03:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/20 ms
R2#
<...snip...>

R3#ping ipv6 FE80::CE00:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE03:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/14/40 ms
R3#ping ipv6 FE80::CE01:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE03:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/15/36 ms
R3#
<...snip...>


As you can see, the link-local interface is not limited to point-to-point networks; it will also work on multipoint networks.

One other interesting point to raise about IPv6 addresses: there is no broadcast address, as there is in IPv4. Instead, IPv6 uses multicast to replicate the functionality of IPv4 broadcast addresses. In additon to global unicast, link-local and multicast addresses, IPv6 also supports a few other special classes of addresses, but we will save them for another day. With what we have covered in this lab and the previous lab, we now have enough grounding to start playing with routing...but I'll save that for the next lab.

IPv6 Intro: Address Format and Subnetting

A couple of years ago, I created a lab, Advanced Cisco Routing: Implementing OSPF in IPv6. I probably got the cart before the horse when I created that lab, since that was the only in this blog (so far) where we even discussed IPv6. Ideally, I should have given an intro to IPv6 addressing and networking before creating a lab where we implemented a routing protocol in IPv6. Today, I'd like to fix that problem. Let's start with a basic introduction to IPv6, from the beginning.

I won't spend a lot of time discussing the need for IPv6. If you are reading this blog, you are already well aware that we network types are quickly running out of free IPv4 addresses, and that in an increasingly connected world, we need to implement a new Layer-3 protocol in order to connect all of our devices to the public Internet. Good enough? ;) Good. Let's proceed with a description of IPv6.

Basic Format of an IPv6 Address:
In IPv4, a valid IP address is a 32-bit number, broken down into four groups of 8-bit numbers -- that is, four groups of digits, each of which can be in the range 0-255. For example, 10.254.254.1 is a valid IP address, as is 172.16.0.4 and 192.168.131.75. Technically, any grouping of octets from 0.0.0.0 to 255.255.255.255 would be valid for IP addressing. However, in practice, parts of the address space have been reserved for special purposes, and therefore, 224.0.0.0 through 255.255.255.255 are not usable for addressing hosts.

Because one of the primary drivers for IPv6 is a lack of IPv4 address space, an IPv6 address is rather more complex. Where IPv4 addresses are 32 bits in length, an IPv6 address is 128 bits in length. Where IPv4 addresses are typically written in decimal notation, IPv6 addresses are written in hexidecimal. Additionally, where an IPv4 address is divided into four groups of 8 bits, separated by a period ("."), IPv6 addresses are subdivided into eight groups of 16-bits each, separated by a colon (":"). For example:
2001:4840:af21:0000:0000:2112:2358:0042
fe80:0000:0000:0000:baca:8ffe:fe42:f138

Because hexidecimal numbers contain alphabetic characters between "A" and "F," you will often see IPv6 addresses with...ummm...clever (?)...words enmbedded in the addresses:
2016:00c0:ffee:4a11:0000:0000:0000:0001
2001:dead:beef:cafe:0000:0000:0000:0128

...which helps with memorizing frequently used addresses. Even better, if an address contains a long sequence of zeroes, you can abbreviate the IPv6 address by replacing the sequence with two colons (":"):
2016:00c0:ffee:4a11::0001

Actually, even that can be shortened, because it isn't necessary to include all of the leading zeroes in each 16-bit string, like so:
2016:c0:ffee:4a11::1

Note: This only applies to LEADING zeroes, however, because trailing zeroes are placeholders, and therefore are required! Consequently, you cannot shorten "2016:c0:ffee:4a11::1" any further, as the zero in "2016" and "c0" must be present. One other catch: you can only truncate sequences of zeroes ONCE in an IPv6 address. For example, if you had the complete IPv6 address, "2001:0000:0042:0000:0000:0000:0000:af41," you would have to choose which sequence of zeroes to truncate. These would be acceptable:
2001::42:0000:0000:0000:0000:af41
2001:0000:42::af41

...but this would not:
2001::42::af41

That is because with either of the first two examples, you can still determine where within the 128 bits of address the "42" lies, but "2001::42::af41" could be any of the following addresses:
2001:0000:0042:0000:0000:0000:0000:af41
2001:0000:0000:0042:0000:0000:0000:af41
2001:0000:0000:0000:0042:0000:0000:af41
2001:0000:0000:0000:0000:0042:0000:af41

Note: Wait a minute! When you abbreviated the full IPv6 address as "2001:0000:42::af41,", you dropped the two leading zeroes ahead of the "42" in "0042," even though you replaced all of the zeroes after "42!"

Yes, but since you can only drop the leading zeroes in a 16-bit segment (i.e., "0042" can be abbreviated as "42," but "4200" cannot), we still know exactly where it belongs in the full, expanded IPv6 address.

Subnetting:
Just as in IPv4, IPv6 addresses can be subnetted. Just as 10.254.254.1/32 is a host address in IPv4, 2001::192:168:1:1/128 is a host address in IPv6. You can subdivide networks in IPv6 to optimize the number of networks and hosts in exactly the same way that you would in IPv4. However, it is important to remember that IPv6 uses hexadecimal numbers, so if you decide to "encapsulate" a common IPv4 address in IPv6 as I did above, don't make the mistake of assuming that, for example, 2001::192:168:1:9/126 and 2001::192.168.1.10/126 are contiguous host addresses within the same subnet. They aren't, as I discovered in a lab recently ;) Between ":9" and ":10" in an IPv6 address, you will find ":a" through ":f" -- which spans two /126 subnets, with ":10" being the network address (as opposed to a host address) for yet another subnet!

Putting it into practice!
Let's create a lab in GNS3 (or actual hardware, if you'd prefer) where we start connecting devices with IPv6. We'll start with a very simple network consisting of two routers. For this first lab, all we'll do is enable IPv6 on the routers, apply an IPv6 address to the connected interfaces, and make sure we can ping across the connection:



Now, we'll turn up the IPv6 addresses on these two routers:
R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0001/126
R1(config-if)#no shut
R1(config-if)#exit
R1(config#exit

...and on R2:
R2(config)#ipv6 unicast-routing
R2(config)#int fa0/0
R2(config-if)#ipv6 enable
R2(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0002/126
R2(config-if)#no shut
R2(config-if)#exit
R2(config#exit

Can we ping?
R1#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0002

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/19/36 ms
R1#

How about from R2?
R2#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0001

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms
R2#

Perfect! We have met the objectives of this lab, so we'll call it a day.

IPv6 Intro: Address Format and Subnetting

A couple of years ago, I created a lab, Advanced Cisco Routing: Implementing OSPF in IPv6. I probably got the cart before the horse when I created that lab, since that was the only in this blog (so far) where we even discussed IPv6. Ideally, I should have given an intro to IPv6 addressing and networking before creating a lab where we implemented a routing protocol in IPv6. Today, I'd like to fix that problem. Let's start with a basic introduction to IPv6, from the beginning.

I won't spend a lot of time discussing the need for IPv6. If you are reading this blog, you are already well aware that we network types are quickly running out of free IPv4 addresses, and that in an increasingly connected world, we need to implement a new Layer-3 protocol in order to connect all of our devices to the public Internet. Good enough? ;) Good. Let's proceed with a description of IPv6.

Basic Format of an IPv6 Address:
In IPv4, a valid IP address is a 32-bit number, broken down into four groups of 8-bit numbers -- that is, four groups of digits, each of which can be in the range 0-255. For example, 10.254.254.1 is a valid IP address, as is 172.16.0.4 and 192.168.131.75. Technically, any grouping of octets from 0.0.0.0 to 255.255.255.255 would be valid for IP addressing. However, in practice, parts of the address space have been reserved for special purposes, and therefore, 224.0.0.0 through 255.255.255.255 are not usable for addressing hosts.

Because one of the primary drivers for IPv6 is a lack of IPv4 address space, an IPv6 address is rather more complex. Where IPv4 addresses are 32 bits in length, an IPv6 address is 128 bits in length. Where IPv4 addresses are typically written in decimal notation, IPv6 addresses are written in hexidecimal. Additionally, where an IPv4 address is divided into four groups of 8 bits, separated by a period ("."), IPv6 addresses are subdivided into eight groups of 16-bits each, separated by a colon (":"). For example:
2001:4840:af21:0000:0000:2112:2358:0042
fe80:0000:0000:0000:baca:8ffe:fe42:f138

Because hexidecimal numbers contain alphabetic characters between "A" and "F," you will often see IPv6 addresses with...ummm...clever (?)...words enmbedded in the addresses:
2016:00c0:ffee:4a11:0000:0000:0000:0001
2001:dead:beef:cafe:0000:0000:0000:0128

...which helps with memorizing frequently used addresses. Even better, if an address contains a long sequence of zeroes, you can abbreviate the IPv6 address by replacing the sequence with two colons (":"):
2016:00c0:ffee:4a11::0001

Actually, even that can be shortened, because it isn't necessary to include all of the leading zeroes in each 16-bit string, like so:
2016:c0:ffee:4a11::1

Note: This only applies to LEADING zeroes, however, because trailing zeroes are placeholders, and therefore are required! Consequently, you cannot shorten "2016:c0:ffee:4a11::1" any further, as the zero in "2016" and "c0" must be present. One other catch: you can only truncate sequences of zeroes ONCE in an IPv6 address. For example, if you had the complete IPv6 address, "2001:0000:0042:0000:0000:0000:0000:af41," you would have to choose which sequence of zeroes to truncate. These would be acceptable:
2001::42:0000:0000:0000:0000:af41
2001:0000:42::af41

...but this would not:
2001::42::af41

That is because with either of the first two examples, you can still determine where within the 128 bits of address the "42" lies, but "2001::42::af41" could be any of the following addresses:
2001:0000:0042:0000:0000:0000:0000:af41
2001:0000:0000:0042:0000:0000:0000:af41
2001:0000:0000:0000:0042:0000:0000:af41
2001:0000:0000:0000:0000:0042:0000:af41

Note: Wait a minute! When you abbreviated the full IPv6 address as "2001:0000:42::af41,", you dropped the two leading zeroes ahead of the "42" in "0042," even though you replaced all of the zeroes after "42!"

Yes, but since you can only drop the leading zeroes in a 16-bit segment (i.e., "0042" can be abbreviated as "42," but "4200" cannot), we still know exactly where it belongs in the full, expanded IPv6 address.
Subnetting:
Just as in IPv4, IPv6 addresses can be subnetted. Just as 10.254.254.1/32 is a host address in IPv4, 2001::192:168:1:1/128 is a host address in IPv6. You can subdivide networks in IPv6 to optimize the number of networks and hosts in exactly the same way that you would in IPv4. However, it is important to remember that IPv6 uses hexadecimal numbers, so if you decide to "encapsulate" a common IPv4 address in IPv6 as I did above, don't make the mistake of assuming that, for example, 2001::192:168:1:9/126 and 2001::192.168.1.10/126 are contiguous host addresses within the same subnet. They aren't, as I discovered in a lab recently ;) Between "::9" and "::10" in an IPv6 address, you will find "::a" through "::f" -- which spans two /126 subnets, with "::10" being the network address for a third!

Putting it into practice!
Let's create a lab in GNS3 (or actual hardware, if you'd prefer) where we start connecting devices with IPv6. We'll start with a very simple network consisting of two routers. For this first lab, all we'll do is enable IPv6 on the routers, apply an IPv6 address to the connected interfaces, and make sure we can ping across the connection:



Now, we'll turn up the IPv6 addresses on these two routers:
R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0001/126
R1(config-if)#no shut
R1(config-if)#exit
R1(config#exit

...and on R2:
R2(config)#ipv6 unicast-routing
R2(config)#int fa0/0
R2(config-if)#ipv6 enable
R2(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0002/126
R2(config-if)#no shut
R2(config-if)#exit
R2(config#exit
>
Can we ping?
R1#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0002

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/19/36 ms
R1#

How about from R2?
R2#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0001

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::4:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms
R2#

Perfect! We have met the objectives of this lab, so we'll call it a day.

Tuesday, September 13, 2016

Cisco Advanced Routing Lab: Redistribution, Default Routes, and Virtual Tunnels

Today, I felt like challenging myself a little bit, so I created a large, somewhat complex network in GNS3 to try putting several concepts together into one, cohesive network. As usual, we'll start with the network diagram:



R1, R2, R3 and R4 are the network core. These routers all live in Area 0 (in the center of the diagram). R1 also participates in Area 1 and shares routes via BGP with R5. R5 participates in an entirely separate OSPF domain with R6 (my idea was that R5 and R6 would be "Internet" hosts for this lab). Just like R1, R2 also participates in Area 1, providing a redundant link to this area. R3 participates in OSPF area 3 and is one of the endpoints for the virtual tunnel to Area 4. R4 also belongs to Area 2. R7, 8 and 9 are pretty straightforward, existing only in Area 1. Likewise, R10 and R11 only live in Area 2; there's nothing complex about their configurations, either. R12, however, is the boundary between Area 2 and the RIP network including R13. R14 and R15 are routers belonging to Area 3, but R16 is a little more tricky. R16 participates in both Area 3 and Area 4.

However, OSPF requires ALL OSPF areas connect to the backbone (area 0) by at least one router. If you notice, there is no direct link between Area 4 and Area 0 in this network diagram, so in order to have Area 4 share routes with the rest of the network, you need to create a "virtual link" between R16 and R3. If ever you find yourself with an OSPF area that doesn't connect to the backbone, it might be worth rethinking your network design so that all of your areas do connect to Area 0. Speaking in broad generalities, there's usually something flawed with your design if you can't connect various OSPF areas directly to the backbone, but if for some reason you can't, it's pretty easy to connect R16 and R3 via a virtual tunnel. First, on R3:
R3(config)#router ospf 42
R3(config-router)#area 0.0.0.3 virtual-link 10.254.254.16


...and on R16:
R16(config)#router ospf 42
R16(config-router)#area 0.0.0.3 virtual-link 10.254.254.3


That's it! There are several options -- such as the various timers -- that you can adjust to account for various network performance issues across the virtual tunnel, but that's essentially all there is to creating the tunnel. Inside the OSPF config on each tunnel endpoint, you list the area ID of the OSPF area that the tunnel will be transiting, and you give the IP address of the other router's OSPF router-ID. In this network, I am using 10.254.254.<router number> for the loopback0 IP address, so R3 is 10.254.254.3 and R16 is 10.254.254.16.

The next "interesting" feature of this lab is the redistribution between OSPF Area 2 and the RIP network on R12. On R13, I created several 172.16.x.y networks on loopback interfaces...:
R13#sho ip int brie
Interface         IP-Address    OK? Method Status...
FastEthernet0/0   unassigned    YES unset  admin...
FastEthernet1/0   10.128.12.2   YES manual up ...
FastEthernet2/0   unassigned    YES unset  admin...
FastEthernet3/0   unassigned    YES unset  admin...
Loopback0         10.254.254.13 YES manual up...
Loopback1         172.16.1.1    YES manual up...
Loopback2         172.16.2.1    YES manual up...
Loopback3         172.17.1.1    YES manual up...
Loopback4         172.17.3.1    YES manual up...

RIPv1 is classful, while we are using classless routing, so the first thing to do is make sure that we are using RIPv2 on both R12 and R13:
R12(config)#router rip
R12(config-router)#version 2

Next, on R12, I want to tell RIP to redistribute OSPF routes, but to add a metric that is sufficiently large that R12 and R13 will prefer local routes to routes that have been imported from OSPF:
R12(config-router)#redistribute ospf 42 metric 3

Since RIP, being a distance-vector protocol, uses hop count as a metric (with a maximum of 15 hops), we start routes imported from OSPF with a hop count of 3 (the "42" is the OSPF process ID I used in the lab -- "router ospf 42"). Now, we'll do the same thing with OSPF:
R12(config-router)#router ospf 42
R12(config-router)#redistribute rip metric 50000 subnets

Again, we are setting the OSPF metric for routes important from RIP to an arbitrarily large value, so that OSPF will prefer local routes to imported routes; the exact value may require some tweaking on your network. I am also using the "subnets" option to tell OSPF to import just the specific subnets that RIP is advertising. Otherwise, any subnets from Class A IP space will be imported as /8 networks; any subnets from Class B IP space will be imported as /16 subnets; and any subnets from Class C IP space will be imported as /24 subnets (in other words, the two 172.16.x.y/24 subnets on R13 would be imported as a single 172.16.0.0/16, the two 172.16.x.y/24 subnets would be imported as a single 172.17.0.0/16, and the 10.254.254.13/32 subnet would be imported as 10.0.0.0/8 -- not at all what we wanted!).

On R1, we are advertising all of the subnets hosted in all of the OSPF areas as well as the RIP network to R5 via BGP:
router bgp 2358
no synchronization
bgp router-id 100.64.0.2
bgp log-neighbor-changes
network 10.0.0.4 mask 255.255.255.252
network 10.0.0.8 mask 255.255.255.252
network 10.0.1.4 mask 255.255.255.252
... network 172.16.0.0
network 172.17.0.0
network 192.168.9.0
neighbor 100.64.0.1 remote-as 2112
no auto-summary
!

It would also be possible to simply import OSPF into BGP, rather than list all of the subnets individually. However, this raises an interesting point: how do you import the routes that R5 is sharing via BGP into the network? The whole point of BGP is to share extremely large routing tables between routers. You don't want to import the entire Internet's routing tables into OSPF, so what is the best way to share external routes with the other routers in your internal network?

In this case, I used a simple, one-line statement to have the other routers send traffic destined for external networks to R1:
R1(config)#router ospf 42
R1(config-router)#default-information originate always
Since R5 is sharing its routes with R1, R1 knows how to reach the external subnets. By adding the "default-information originate" command to R1's OSPF config, it is essentially telling the other routers within the network that is the default gateway -- that traffic destined for unknown networks should be sent to it. R5 has the exact same statement in its OSPF config, so that R6 can reach the networks R5 has received via BGP.

Tuesday, June 7, 2016

BGP Route Filtering

Consider the network in the following diagram...:

If you apply a simple BGP configuration to each router in this network, something along the lines of...:
#R5 BGP Configuration:
router bgp 500
no synchronization
bgp router-id 10.254.254.5
bgp log-neighbor-changes
network 10.254.254.5 mask 255.255.255.255
network 172.16.0.0 mask 255.255.255.252
network 172.16.0.16 mask 255.255.255.252
neighbor 172.16.0.2 remote-as 100
neighbor 172.16.0.17 remote-as 400
no auto-summary

...BGP will find the "best" route around the network. For example, for R1 to ping R4's loopback address, it would take the route R1, R5, R4, and to ping R3's loopback address, R1 would take the route R1, R2, R3:
R1#sho ip route
<---snip--->
10.0.0.0/32 is subnetted, 5 subnets
B 10.254.254.2 [20/0] via 172.16.0.6, 00:00:10
B 10.254.254.3 [20/0] via 172.16.0.6, 00:00:10
C 10.254.254.1 is directly connected, Loopback0
B 10.254.254.4 [20/0] via 172.16.0.1, 00:00:09
B 10.254.254.5 [20/0] via 172.16.0.1, 00:00:15
R1#

Exactly as you would expect, right?

It could happen, however, that there is some factor of which BGP is unaware that makes this routing less than optimal. Suppose, for example, that you are the administrator of router R5, and while you would like to multi-home your router, you don't want to allow other networks to transit your router. To prevent BGP from advertising routes to other networks, it is possible to filter outbound routes from your router.

Step 1: Create an access list to define the networks you want to allow outbound.
R5(config)#access-list 1 permit 10.254.254.5 0.0.0.0
R5(config)#access-list 1 permit 172.16.0.0 0.0.0.3
R5(config)#access-list 1 permit 172.16.0.16 0.0.0.3

Step 2: Edit the BGP config to filter the routes as defined in your access list.
R5(config)#router bgp 500
R5(config-router)# neighbor 172.16.0.2 distribute-list 1 out
R5(config-router)# neighbor 172.16.0.17 distribute-list 1 out

Step 3: Clear the BGP sessions to reset the routes.
R5#clear ip bgp 100
R5#clear ip bgp 400
R5#
00:49:41: %BGP-5-ADJCHANGE: neighbor 172.16.0.2 Down User reset
R5#
00:49:43: %BGP-5-ADJCHANGE: neighbor 172.16.0.17 Down User reset
R5#

Now, if you look at the routes on R1, it will only transit R1 to reach networks that are directly connected to R1:
R1#sho ip route
<---snip--->
172.16.0.0/30 is subnetted, 5 subnets
B 172.16.0.16 [20/0] via 172.16.0.1, 00:01:28
B 172.16.0.12 [20/0] via 172.16.0.6, 00:09:24
B 172.16.0.8 [20/0] via 172.16.0.6, 00:09:24
C 172.16.0.4 is directly connected, FastEthernet0/0
C 172.16.0.0 is directly connected, FastEthernet3/0
10.0.0.0/32 is subnetted, 5 subnets
B 10.254.254.2 [20/0] via 172.16.0.6, 00:09:24
B 10.254.254.3 [20/0] via 172.16.0.6, 00:09:24
C 10.254.254.1 is directly connected, Loopback0
B 10.254.254.4 [20/0] via 172.16.0.6, 00:02:21
B 10.254.254.5 [20/0] via 172.16.0.1, 00:01:28
R1#

As you can see, to reach R4's loopback address now, R1 now will route traffic through R2 rather than through R5.

Now, what would happen if there was a break somewhere in between R2 and R4?
R2#conf t
R2(config)#int fa0/0
R2(config-if)#shut

R1#ping 10.254.254.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.254.254.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

R5 will not propagate any routes except those that you have explicitly allowed, and as a result, R1 no longer has a route to R4.

Friday, August 29, 2014

Advanced Cisco Routing: OSPF Metrics

Suppose there are multiple routes between hosts on a network? How does OSPF choose a preferred route? I'm a big fan of practical experience, so to answer this question, I fired up GNS3 and started building networks to find out:

There are two endpoints, R5 and R6 in this network. There is a core network consisting of R1, R2, R3 and R4 which provide the transport between these two endpoints. Looking at this network diagram, you can see that there are two routes that traffic between these endpoints might take: first, there is the route R1-R2-R3-R4; second, there is the much shorter route of R1-R4. You can make a logical argument for either of these routes being better. From R1, there are two paths to R4, one of which is across a FastEthernet interface, and the other of which is across a 10M Ethernet interface. From R1's perspective, route R1-R2-R3-R4, going through the FastEthernet interface, might appear to be better, since the FastEthernet interface has ten times the bandwidth of the Ethernet interface connecting R1 and R4. However, there are more hops on that route, and the Serial link between R2 and R3 is much slower than the Ethernet interface between R1 and R4. Consequently, a human with the complete picture of the network can see that R5-R1-R4-R6 is clearly the better path. Does OSPF see that, also?

R5#traceroute 192.168.2.2

Type escape sequence to abort.
Tracing the route to 192.168.2.2

1 192.168.1.1 4 msec 4 msec 4 msec
2 172.16.1.2 12 msec 8 msec 8 msec
3 192.168.2.2 28 msec 24 msec *
R5#

Yep. Like a human with a network diagram, OSPF forms a complete picture of the network topology and makes intelligent decisions about the best route between endpoints.

However, suppose the topology were different. What if R1-R4 were connected by a serial link and R1-R2-R3-R4 were all FastEthernet links, like so?:

In this case, there is only one hop on the R1-R4 path, whereas there are four hops on the R1-R2-R3-R4 path. However, the bandwidth across the FastEthernet links is much better than the bandwidth across the serial link. A human would most likely choose R1-R2-R3-R4 to pass the traffic. What does OSPF choose as the best path?
R5#traceroute 192.168.2.2

Type escape sequence to abort.
Tracing the route to 192.168.2.2

1 192.168.1.1 4 msec 8 msec 0 msec
2 172.16.2.2 16 msec 12 msec 12 msec
3 172.16.3.2 24 msec 24 msec 24 msec
4 172.16.4.2 36 msec 24 msec 28 msec
5 192.168.2.2 48 msec 40 msec *
R5#

Once again, OSPF uses its comprehensive view of the network to choose the best path between endpoints. However, if you need to force OSPF to choose a particular path, it is possible to do so by manually assigning a cost to a link, but that's a topic for another post ;)

Avanced Cisco Routing: Implementing OSPF in IPv6

So far, all of the labs have dealt exclusively with IPv4 -- what has traditionally just been called, "IP."  Today, let's look at configuring IPv6 on Cisco routers, since we are rapidly approaching the point where IPv4 will no longer suffice on the public Internet.

Consider the following network topology:

I am using the IPv6 address space 2001:dead:beef:0:0:0:0:0/64 (2001:dead:beef:0::/64) to create the subnets that I will use to address these routers.  I have decided that the subnet 2001:dead:beef::0/112 will be reserved for the loopback addresses on my core routers (far more than I need, but in real-life, that would provide room for expansion in the future).  The subnet 2001:dead:beef::1:0/112 will be reserved -- and subdivided -- for point-to-point networks, such as the serial links between the core routers.  Each LAN will be a /112 on 2001:dead:beef::x:0, where "x" is greater than 0 -- for example, 2001:dead:beef::1:0/112, 2001:dead:beef::2:0/112, etc.  I will use OPSFv6 to route between these various networks.

As I often do, I am using Cisco 3600-series routers for the core routers (ANCCR1, ENACR1, FAICR1 and HOMCR1) and Cisco 2600-series routers to simulate PCs attached to the routers' LANs.  Since the 2600 routers are the simplest to configure -- just a single Ethernet interface and a static route to the core routers -- that's where I started configuring this network:

faipc2(config)#int fa1/0
faipc2(config-if)#description Uplink to faicr1
faipc2(config-if)#ipv6 address 2001:dead:beef:0:0:0:3:2/112
faipc2(config-if)#ipv6 enable
faipc2(config-if)#no shut
faipc2(config-if)#exit
faipc2(config)#ipv6 route 0:0:0:0:0:0:0:0/0 2001:dead:beef:0:0:0:3:1
faipc2(config)#

That's all it takes to configure an IPv6 address on FA1/0 and to set up a static route to faicr1.  We'll repeat this set-up (with the appropriate IPv6 addresses and routes, of course) on R5-R9, but I won't duplicate the configurations here.

Once the "PC's" are configured, we'll start configuring the core routers.  Let's start with anccr1, since it's the most complex router on the network, having two Ethernet interfaces, two serial interfaces and a loopback interface:
anccr1(config)#int lo0
anccr1(config-if)#ipv6 address 2001:dead:beef::1/128
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int fa1/0
anccr1(config-if)#desc Anchorage LAN 1
anccr1(config-if)#ipv6 address 2001:dead:beef::6:1/112
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int fa2/0
anccr1(config-if)#desc Anchorage LAN 2
anccr1(config-if)#ipv6 address 2001:dead:beef::7:1/112
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int s0/0
anccr1(config-if)#desc Uplink to faicr1
anccr1(config-if)#ipv6 address 2001:dead:beef::1:1/127
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int s0/1
anccr1(config-if)#desc Uplink to enacr1
anccr1(config-if)#ipv6 address 2001:dead:beef::1:5/127
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut

Just as in IPv4, by default, the router will know how to reach connected networks, but will not share routes with the other routers until a routing protocol (OSPF, BGP, EIGRP, etc.) is enabled.  However, at this point we should have two devices we can reach from anccr1: ancpc1 (R7 on the diagram) and ancpc2 (R8 on the diagram).  Let's try to ping them both:
anccr1#ping 2001:dead:beef::6:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::6:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/12 ms
anccr1#ping 2001:dead:beef::7:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::7:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms
anccr1#

Excellent!  We were able to ping both hosts.  Let's turn up enacr1 and see if we can ping across the serial link:
enacr1(config)#int fa1/0
enacr1(config-if)#desc Kenai LAN
enacr1(config-if)#ipv6 address 2001:dead:beef::4:1/112
enacr1(config-if)#ipv6 enable
enacr1(config-if)#no shut
enacr1(config-if)#int s0/1
enacr1(config-if)#desc Uplink to homcr1
enacr1(config-if)#ipv6 address 2001:dead:beef::1:9/127
enacr1(config-if)#ipv6 enable
enacr1(config-if)#no shut
enacr1(config-if)#int s0/0
enacr1(config-if)#desc Uplink to anccr1
enacr1(config-if)#ipv6 address 2001:dead:beef::1:6/127
enacr1(config-if)#ipv6 enable
enacr1(config-if)#no shut

Hmmm...something seems to be wrong.  I can ping the 2600 router ("LAN PC"), but not the Anchorage core router:
enacr1#ping 2001:dead:beef::1:5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::1:5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
enacr1#ping 2001:dead:beef::4:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/6/12 ms
enacr1#

We'll troubleshoot just like we would on an IPv4 network:
enacr1#sho ipv6 int brief
Serial0/0                  [up/up]
    FE80::CE02:14FF:FEA2:10
    2001:dead:beef::1:6
Serial0/1                  [up/up]
    FE80::CE02:14FF:FEA2:10
    2001:dead:beef::1:9
Serial0/2                  [administratively down/down]
    unassigned
Serial0/3                  [administratively down/down]
    unassigned
FastEthernet1/0            [up/up]
    FE80::CE02:14FF:FEA2:10
    2001:dead:beef::4:1
enacr1#
enacr1#sho ipv6 route
IPv6 Routing Table - 8 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
C   2001:dead:beef::1:6/127 [0/0]
     via ::, Serial0/0
L   2001:dead:beef::1:6/128 [0/0]
     via ::, Serial0/0
C   2001:dead:beef::1:8/127 [0/0]
     via ::, Serial0/1
L   2001:dead:beef::1:9/128 [0/0]
     via ::, Serial0/1
C   2001:dead:beef::4:0/112 [0/0]
     via ::, FastEthernet1/0
L   2001:dead:beef::4:1/128 [0/0]
     via ::, FastEthernet1/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
enacr1#

Hmmm...well, for one thing, we configured the IPv6 addresses on the serial ports as /127's on both routers rather than /126's.  In theory, this should work, but you might want to research /127's on an IPv6 network before using them.  For now, let's change the /127's to /126's, and see what happens:
anccr1#ping 2001:dead:beef::1:6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::1:6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms
anccr1#

That's better!  I'd love to say that the incorrect subnetting was an accidental typo, but in all honesty...I fubar'd the notation -- but it made for a great teaching moment, so I didn't edit it out of the blog entry, lol.

One last thing to try...by default, a router knows all of the subnets connected to it, and the "LAN PC's" have a default route to the local core router, so in theory, a "LAN PC" should be able to ping the loopback IPv6 address of its local LAN router.  Let's try it:
ancpc1#ping 2001:dead:beef::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
ancpc1#

Sweet!  That worked just as expected.

Now, let's try enabling routing on the IPv6 network:
homcr1(config)#ipv6 router ospf 42
% IPv6 routing not enabled
homcr1(config)#
Eh?!?!  A quick search of the magic Google ball explains why: you must enable IPv6 unicast routing before you can turn up any IPv6 routing protocols.  <shrug>  Okay, whatever.  Let's do it:
homcr1(config)#ipv6 unicast-routing
homcr1(config)#ipv6 router ospf 42
04:44:40: %OSPFv3-4-NORTRID: OSPFv3 process 42 could not pick a router-id,
please configure manually

Ummm...okay.  I was just about to do that, anyway:
homcr1(config-rtr)#router-id 2001:dead:beef::4
                             ^
% Invalid input detected at '^' marker.

And we wonder why IPv6 is taking so long to adopt, sigh.  According to the spec, the OSPF router ID is technically NOT an IP address, but is instead a 32-bit number that is used to uniquely identify the router in it's OSPF area.  Since IP (v4) addresses happen to also be 32-bit numbers, that is what is typically used, but it is not a requirement.  The fact that Cisco, by default, will select one of the IPv4 addresses configured on the router to use as the router ID if you do not manually specify one muddies the issue, but that isn't really relevant here...except that we haven't configured any IPv4 addresses on the router, so OSPF can't arbitrarily snatch one to use as the router ID.  Back on track...let's assign a random 32-bit router ID to this router:
homcr1(config-rtr)#router-id 4.4.4.4

Next, there is no "network a.b.c.d e.f.g.h area i.j.k.l" command in IPv6 OSPF like there is in IPv4 OSPF.  Instead, we set the OSPF area globally, and tell the OSPF process what we would like to distribute:
homcr1(config-rtr)#area 0.0.0.0 range 2001:dead:beef::0/64
homcr1(config-rtr)#redistribute connected

However, that isn't sufficient to start sharing routes via IPv6 OSPF:
faicr1#sho ipv6 route
IPv6 Routing Table - 9 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC  2001:dead:beef::3/128 [0/0]
     via ::, Loopback0
C   2001:dead:beef::1:0/126 [0/0]
     via ::, Serial0/0
L   2001:dead:beef::1:2/128 [0/0]
     via ::, Serial0/0
C   2001:dead:beef::2:0/112 [0/0]
     via ::, FastEthernet1/0
L   2001:dead:beef::2:1/128 [0/0]
     via ::, FastEthernet1/0
C   2001:dead:beef::3:0/112 [0/0]
     via ::, FastEthernet2/0
L   2001:dead:beef::3:1/128 [0/0]
     via ::, FastEthernet2/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
faicr1#

In IPv6 OSPF, you have to enable the OSPF process in each interface that will be participating in OSPF:
faicr1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
faicr1(config)#int s0/0
faicr1(config-if)#ipv6 ospf 42 area 0.0.0.0
faicr1(config-if)#exit
05:10:00: %OSPFv3-5-ADJCHG: Process 42, Nbr 1.1.1.1 on Serial0/0 from LOADING to FULL, Loading Done
faicr1(config)#exit
faicr1#sho ipv6 route
IPv6 Routing Table - 16 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
OE2  2001:dead:beef::1/128 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
OE2  2001:dead:beef::2/128 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
LC  2001:dead:beef::3/128 [0/0]
     via ::, Loopback0
C   2001:dead:beef::1:0/126 [0/0]
     via ::, Serial0/0
L   2001:dead:beef::1:2/128 [0/0]
     via ::, Serial0/0
O   2001:dead:beef::1:4/126 [110/128]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
O   2001:dead:beef::1:8/126 [110/192]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
C   2001:dead:beef::2:0/112 [0/0]
     via ::, FastEthernet1/0
L   2001:dead:beef::2:1/128 [0/0]
     via ::, FastEthernet1/0
C   2001:dead:beef::3:0/112 [0/0]
     via ::, FastEthernet2/0
L   2001:dead:beef::3:1/128 [0/0]
     via ::, FastEthernet2/0
OE2  2001:dead:beef::4:0/112 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
OE2  2001:dead:beef::6:0/112 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
OE2  2001:dead:beef::7:0/112 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
faicr1#

That's much better! Now we have routes from the other routers (which previously had OSPF enabled on their serial interfaces) showing up on the Fairbanks core router. Let's make sure our "LAN PC's&qout; can ping end-to-end:
hompc1#ping 2001:dead:beef::4:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/20 ms
hompc1#ping 2001:dead:beef::6:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::6:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/36/64 ms
hompc1#ping 2001:dead:beef::7:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::7:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/30/56 ms
hompc1#ping 2001:dead:beef::2:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::2:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/35/56 ms
hompc1#ping 2001:dead:beef::3:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::3:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/25/57 ms
hompc1#

Thursday, October 10, 2013

Lesson 15 -- HSRP

You finally get caught up on all of your work and schedule a well-deserved week of PTO. The big day comes, and you relish in the chance to sleep in a little bit. You finally get up, then load up your motorcycle with gear (hey, it's my story, and with a week off, I'd go someplace cool on my motorcycle, lol) and race out of town to go camping in the mountains. You have just picked out a nice camping spot in the woods near a calming, babbling stream -- very Zen, you decide -- when you suddenly hear the most dreadful, blood-curdling, adrenaline-inducing noise known to man. The horrible wail sends chills up your spine, and you cringe with fear, wondering what is about to happen. You take a deep breath, summon all of your courage and...

...answer your cell phone.

It's the manager of the branch office. "I'm so sorry to bother you on the first day of your vacation, but we've just lost the network to the main office."

"No problem," you lie, sighing. You walk her through a few initial troubleshooting steps -- pings, traceroutes and such -- and confirm that the branch office router is off-line. You ask her to go to the wire closet and look for a power light on the front of the router. It takes a few tries to help her find the correct device, but soon enough, she has located it, and as you suspected, it is powered off. She cycles the power switch to no avail, so you have her check the circuit breakers in the wall. Sure enough, the breaker has tripped, so you have her reset it, and she tells you that she now sees "blinky lights" on the front of the router. By the time she has returned to her desk, the router has booted and she verifies that she can now reach the main office network again.

"Thanks again for the help," she tells you, as she hangs up, while you silently vow to camp tomorrow night in a remote valley farther back in the mountains where there is no cell service.

The rest of the week passes with no more interruptions, and you return to the office the following Monday morning with a plan to buy a second router and configure HSRP so that a failure of a router will cause the network to route all traffic through a standby router, reducing the number of after-hours calls you receive and providing better uptime to your users.

But mostly to reduce the number of after-hours calls you receive... :)

When the new router arrives, you copy the config from the existing router, then change the hostname on the new router and change the IP address of the serial line back to the main office. Once you've verified that the serial line to the main office is working, you configure HSRP on both routers. On the old router, you delete the IP address on the Fa0/0 port, then add these lines:

lab3640rtra(config)#interface FastEthernet0/0
lab3640rtra(config-if)#ip address 192.168.2.2 255.255.255.0
lab3640rtra(config-if)#standby 42 ip 192.168.2.1
lab3640rtra(config-if)#standby 42 priority 64
lab3640rtra(config-if)#standby 42 name Branch_Office_HSRP_Group


...and on the new router:

lab3640rtrb(config)#interface FastEthernet0/0
lab3640rtrb(config-if)#ip address 192.168.2.3 255.255.255.0
lab3640rtrb(config-if)#standby 42 ip 192.168.2.1
lab3640rtrb(config-if)#standby 42 priority 128
lab3640rtrb(config-if)#standby 42 name Branch_Office_HSRP_Group


A couple of things are important in this configuration. First, the old router (3640a) used to have the IP address 192.168.2.1./24 assigned to fa0/0, but I have now assigned that IP address to the standby group ("standby 42 ip 192.168.2.1"). Next, both the old router and the new router have new IP addresses in the same subnet as the IP address for the standby group (192.168.2.2, 192.168.2.3 and 192.168.2.1, respectively). The two routers will be negotiating responsibility for forwarding LAN traffic to the WAN port over their new IP addresses, and will be listening for traffic from the LAN on 192.168.2.1 (which the LAN hosts will use as the default gateway address). If the active router goes off-line for some reason, the standby router will notice that it is no longer receiving keep-alive messages, and will assume the role of the default gateway. Finally, notice that all of the lines that activate HSRP begin, "standby 42..." The number 42 is the standby group number, and can be anything that you desire (well, within the bounds of 0 and 255, anyway). I picked 42 because it is "a completely ordinary number, a number not just divisible by two but also six and seven. In fact it's the sort of number that you could without any fear introduce to your parents." Or something like that, anyway, lol.

<...shoots the rabbit, gets off of the bunny trail and gets back on topic...>

After setting up HSRP, you tap out a few more commands on the keyboard to make sure the routers really are providing fail-over protection:

lab3640artr#sho standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active addr     Standby addr    Group addr     
Fa0/0       42  64     Standby  192.168.2.3     local           192.168.2.1    
lab3640artr#


...and...:

lab3640brtr#sho standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active          Standby         Virtual IP     
Fa0/0       42  128    Active   local           192.168.2.2     192.168.2.1    
lab3640brtr#


Yep, looks good! You hook up a laptop to an unused switchport, then start pinging the main office router. Since 3640b is the active and 3640a is the standby, you decide to pull the Ethernet cable to 3640b to verify that the failover occurs as expected, and to see how many pings you drop during the switch:

64 bytes from 192.168.2.1: icmp_req=8 ttl=255 time=1.35ms
64 bytes from 192.168.2.1: icmp_req=9 ttl=255 time=1.38ms
64 bytes from 192.168.2.1: icmp_req=18 ttl=255 time=1.17ms
64 bytes from 192.168.2.1: icmp_req=19 ttl=255 time=1.14ms


Hmmm...about 9 seconds to fail over. Users will probably notice the drop, if they are paying attention, but the network will be back up before they can dial your cell phone. You check the HSRP status on the two routers again:

lab3640artr#sho standby brief                      P indicates configured to preempt.                      | Interface   Grp Prio P State    Active addr     Standby addr    Group addr      Fa0/0       42  64     Active   local           unknown         192.168.2.1     lab3640artr#

...and...:

lab3640brtr#sho standby brief                      P indicates configured to preempt.                      | Interface   Grp Prio P State    Active          Standby         Virtual IP      Fa0/0       42  128    Init     unknown         unknown         192.168.2.1     lab3640brtr#

Looks good. The output shows that the routers have switched roles, due to the disconnected network cable on the 3640b. Unless the WAN link on the active router is flapping, that should provide some redundancy between the main office and branch office networks for the users in the branch office. You pat yourself on the back and call it a day.