evilrouters.net

Today I’m expanding on to our previous BGP lab, “Configuring Basic BGP“. We’re going to demonstrate how we can use BGP’s weight attribute to influence routing out of an autonomous system (AS). We’ve got a new network topology consisting of four routers arranged in a “square”:

Dynagen topology

Here’s what our .net file for Dynagen looks like for this lab:

autostart = False

[localhost:7200]

        workingdir = /home/jlgaddis/dynamips/working/bgp

        [[3640]]
                image = /home/jlgaddis/dynamips/ios/c3640-js-mz.124-17.img
                idlepc = 0x604c37fc
                ram = 128
                disk0 = 8
                disk1 = 0
                mmap = true
                ghostios = true

        [[router R1]]
                model = 3640
                console = 2000
                slot0 = NM-4T
                s0/0 = R2 s0/0
                s0/1 = R4 s0/1

        [[router R2]]
                model = 3640
                console = 2001
                slot0 = NM-4T
                s0/1 = R3 s0/1

        [[router R3]]
                model = 3640
                console = 2002
                slot0 = NM-4T
                s0/0 = R4 s0/0

        [[router R4]]
                model = 3640
                console = 2003
                slot0 = NM-4T

IP Addresses

To better illustrate the IP addressing used within the lab, here’s a handy dandy table for you as well:

Device	Interface	IP Address	Subnet Mask
R1	Loopback 0	192.168.1.1	255.255.255.0
	Serial 0/0	192.168.0.1	255.255.255.252
	Serial 0/1	192.168.0.14	255.255.255.252
R2	Loopback 0	192.168.2.2	255.255.255.0
	Serial 0/0	192.168.0.2	255.255.255.252
	Serial 0/1	192.168.0.5	255.255.255.252
R3	Loopback 0	192.168.3.3	255.255.255.0
	Serial 0/0	192.168.0.9	255.255.255.252
	Serial 0/1	192.168.0.6	255.255.255.252
R4	Loopback 0	192.168.4.4	255.255.255.0
	Serial 0/0	192.168.0.10	255.255.255.252
	Serial 0/1	192.168.0.13	255.255.255.252

Each router will advertise the /24 network of its Loopback 0 interface into BGP.

Initial configurations

Using the IP addressing schema from the table above, let’s go ahead and configure the loopback0, serial0/0, and serial0/1 interfaces on each router:

R1# configure terminal
R1(config)# interface loopback 0
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# interface serial 0/0
R1(config-if)# ip address 192.168.0.1 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# interface serial 0/1
R1(config-if)# ip address 192.168.0.14 255.255.255.252
R1(config-if)# no shutdown
R1(config-if)# end
R1#

R2# configure terminal
R2(config)# interface loopback 0
R2(config-if)# ip address 192.168.2.2 255.255.255.0
R2(config-if)# interface serial 0/0
R2(config-if)# ip address 192.168.0.2 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# interface serial 0/1
R2(config-if)# ip address 192.168.0.5 255.255.255.252
R2(config-if)# no shutdown
R2(config-if)# end
R2#

R3# configure terminal
R3(config)# interface loopback 0
R3(config-if)# ip address 192.168.3.3 255.255.255.0
R3(config-if)# interface serial 0/0
R3(config-if)# ip address 192.168.0.9 255.255.255.252
R3(config-if)# no shutdown
R3(config-if)# interface serial 0/1
R3(config-if)# ip address 192.168.0.6 255.255.255.252
R3(config-if)# no shutdown
R3(config-if)# end
R3#

R4# configure terminal
R4(config)# interface loopback 0
R4(config-if)# ip address 192.168.4.4 255.255.255.0
R4(config-if)# interface serial 0/0
R4(config-if)# ip address 192.168.0.10 255.255.255.252
R4(config-if)# no shutdown
R4(config-if)# interface serial 0/1
R4(config-if)# ip address 192.168.0.13 255.255.255.252
R4(config-if)# no shutdown
R4(config-if)# end
R4#

Verification of initial configuration

Let’s verify that we have full connectivity between our devices:

R1# ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/47/96 ms
R1# ping 192.168.0.13

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/42/112 ms
R1#

R2# ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/21/28 ms
R2# ping 192.168.0.6

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

R3# ping 192.168.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/19/24 ms
R3# ping 192.168.0.10

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

R4# ping 192.168.0.9

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/36 ms
R4# ping 192.168.0.14

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.14, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms
R4#

Alright, looks like we’re good to go!

BGP Configuration

Now we can get started on configuring BGP. Each router has two BGP neighbors that are directly connected via the serial 0/0 and serial 0/1 interfaces. On each router, we’re going to advertise into BGP the network of the loopback 0 interface (”192.168.x.0/24″):

R1# configure terminal
R1(config)# router bgp 65001
R1(config-router)# network 192.168.1.0 mask 255.255.255.0
R1(config-router)# neighbor 192.168.0.2 remote-as 65002
R1(config-router)# neighbor 192.168.0.13 remote-as 65004
R1(config-router)# end
R1#

R2# configure terminal
R2(config)# router bgp 65002
R2(config-router)# network 192.168.2.0 mask 255.255.255.0
R2(config-router)# neighbor 192.168.0.1 remote-as 65001
R2(config-router)# neighbor 192.168.0.6 remote-as 65003
R2(config-router)# end
R2#

R3# configure terminal
R3(config)# router bgp 65003
R3(config-router)# network 192.168.3.0 mask 255.255.255.0
R3(config-router)# neighbor 192.168.0.5 remote-as 65002
R3(config-router)# neighbor 192.168.0.10 remote-as 65004
R3(config-router)# end
R3#

R4# configure terminal
R4(config)# router bgp 65004
R4(config-router)# network 192.168.4.0 mask 255.255.255.0
R4(config-router)# neighbor 192.168.0.9 remote-as 65003
R4(config-router)# neighbor 192.168.0.14 remote-as 65001
R4(config-router)# end
R4#

Shortly after configuring BGP (above), we should see syslog messages letting us know that the adjacencies have formed. For example:

R1#
*Mar  1 00:15:03.791: %BGP-5-ADJCHANGE: neighbor 192.168.0.2 Up 
R1#
*Mar  1 00:19:50.823: %BGP-5-ADJCHANGE: neighbor 192.168.0.13 Up 
R1#

Verifying BGP

Let’s take a look at our BGP table on R1:

R1# show ip bgp
BGP table version is 5, local router ID is 192.168.1.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
*> 192.168.1.0      0.0.0.0                  0         32768 i
*  192.168.2.0      192.168.0.13                           0 65004 65003 65002 i
*>                  192.168.0.2              0             0 65002 i
*  192.168.3.0      192.168.0.13                           0 65004 65003 i
*>                  192.168.0.2                            0 65002 65003 i
*  192.168.4.0      192.168.0.2                            0 65002 65003 65004 i
*>                  192.168.0.13             0             0 65004 i
R1#

We can see that we have two routes to each of: 192.168.2.0/24, 192.168.3.0/24, and 192.168.4.0/24. All things being equal, BGP will choose the shortest path to each network. We can see this evidenced by the fact that BGP has chosen to send traffic for 192.168.2.0/24 to AS 65002 (R2) and traffic for 192.168.4.0/24 to AS 65004 (R4). Notice, however, that while there are two routes to 192.168.3.0/24 (AS 65003), BGP has chosen to send traffic for that network through AS 65002 (R2). The path through R2 was chosen because it is the “more stable” route (R1’s adjacency with R2 was formed before R1’s adjacency with R4).

Let’s assume, however, that (for whatever reason) we want to route traffic for 192.168.3.0/24 through AS 65004 (R4). The easiest (but not always best) way to do this is by using BGP’s weight attribute.

BGP weight attribute

Note that in the output of “show ip bgp” above, the weights assigned to each route to 192.168.3.0 are 0:

*  192.168.3.0      192.168.0.13                           0 65004 65003 i
*>                  192.168.0.2                            0 65002 65003 i

Zero is the default value. When multiple routes to the same destination exist, BGP will prefer the route with the highest weight. To influence traffic to 192.168.3.0 to take the path through AS 65004 (R4), we need to modify the weight assigned to the route received from R4. There are a few ways of doing this, but we’re going to use a route map (probably the most common method).

Just for verification, let’s look at what is currently in our routing table for 192.168.3.0/24:

R1# show ip route | include 192.168.3.0
B    192.168.3.0/24 [20/0] via 192.168.0.2, 00:17:31
R1#

We are, indeed, routing traffic to 192.168.3.0/24 via R2 (192.168.0.2).

Defining an access list

We are actually receiving multiple routes from R4, but only want to influence routing for one route so we are going to use route maps in conjunction with an IP access list to achieve our desired outcome. First, we need to define an access list that matches 192.168.3.0/24:

R1# configure terminal
R1(config)# access-list 3 permit 192.168.3.0 0.0.0.255
R1(config)# end
R1#

Defining a route map

With our access list now matching the networks we want to manipulate, we can now create our route map (which we’ll call “NET3″). Our route map will be configured to match traffic defined by access list 3 and will set the weight to 100:

R1# configure terminal
R1(config)# route-map NET3 permit 10
R1(config-route-map)# match ip address 3
R1(config-route-map)# set weight 100
R1(config-route-map)# route-map NET3 permit 20
R1(config-route-map)# end
R1#

You may be wondering about the “route-map NET3 permit 20″ statement, since it doesn’t appear to do anything. From Cisco:

“It is proper behavior to not accept any autonomous system path not matching the match clause of the route map. This means that you will not set the metric and the Cisco IOS software will not accept the route. However, you can configure the software to accept autonomous system paths not matched in the match clause of the route map command by using multiple maps of the same name, some without accompanying set commands.”

That’s exactly what we did in this case. If we had left out the “route-map NET3 permit 20″ statement, any other routes from R4 would not be accepted. Although we are only going to be manipulating the route to 192.168.3.0/24 from R4, we still need to accept all other routes from R4 into our BGP table.

Applying a route map to a neighbor

With our route map configured, we now need to instruct R1 to apply the route-map to any updates received from our neighbor, R4. Easy enough:

R1# configure terminal
R1(config)# router bgp 65001
R1(config-router)# neighbor 192.168.0.13 route-map NET3 in
R1(config-router)# end
R1#

We’re pretty much set at this point. The changes won’t take effect immediately, however. We need to restart the BGP process in order for our changes to take effect. Let’s restart:

R1# clear ip bgp 65004

If we take a look at our BGP table, we should see that the route for 192.168.3.0/24 that came from R4 (AS 65004) should now have a weight of 100 assigned to it, and it does:

R1# show ip bgp
BGP table version is 13, local router ID is 192.168.1.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
*> 192.168.1.0      0.0.0.0                  0         32768 i
*  192.168.2.0      192.168.0.13                           0 65004 65003 65002 i
*>                  192.168.0.2              0             0 65002 i
*> 192.168.3.0      192.168.0.13                         100 65004 65003 i
*                   192.168.0.2                            0 65002 65003 i
*> 192.168.4.0      192.168.0.13             0             0 65004 i
*                   192.168.0.2                            0 65002 65003 65004 i
R1#

Subsequently, we should see that the “new” route to 192.168.3.0/24 (via 192.168.0.13 in AS 65004) was installed into our routing table:

R1# show ip route | include 192.168.3.0
B    192.168.3.0/24 [20/0] via 192.168.0.13, 00:01:56
R1#

And that’s all there it is to it!

Related Posts:

Configuring Basic BGP

good advice?

oid for procurve 9304m cpu usage?

1120 days uptime

Configuring Basic OSPF (Dynamips)

Here’s a quick demonstration on how to configure two routers to be BGP neighbors. I’m using dynamips and the same topology from yesterday’s multilink PPP lab (for simplicity):

Autonomous Systems

• R1 : 42
• R2 : 69

Networks Advertised

We’ll configure a loopback 0 interface on each of the two routers and then advertise those networks to our BGP neighbors.

• R1 Loopback0 : 42.42.42.1/24
• R2 Loopback0 : 69.69.69.1/24

Loopback Configuration

Let’s configure our loopback 0 interfaces first:

R1# configure terminal
R1(config)# interface loopback 0
R1(config-if)# ip address 42.42.42.1 255.255.255.0
R1(config-if)# end
R1#

R2# configure terminal
R2(config)# interface loopback 0
R2(config-if)# ip address 69.69.69.1 255.255.255.0
R2(config-if)# end
R2#

R1 BGP Configuration

Now we’ll configure BGP on R1 and advertise only the 42.42.42.0/24 network into BGP:

R1# configure terminal
R1(config)# router bgp 42
R1(config-router)# network 42.42.42.0 mask 255.255.255.0
R1(config-router)# neighbor 192.168.42.2 remote-as 69
R1(config-router)# end
R1#

R2 BGP Configuration

Likewise, we’ll configure BGP on R2 and advertise only the 69.69.69.0/24 network:

R2# configure terminal
R2(config)# router bgp 69
R2(config-router)# network 69.69.69.0 mask 255.255.255.0
R2(config-router)# neighbor 192.168.42.1 remote-as 42
R2(config-router)# end
R2#

Verification

After a moment we should see a syslog message (on each router) similar to the following, letting us know that an adjacency has formed:

*Mar  1 00:07:28.667: %BGP-5-ADJCHANGE: neighbor 192.168.42.2 Up

BGP is not the fastest protocol when it comes to convergence, but after a moment we should see the neighbors are exchanging routes:

R1# show ip bgp summary
BGP router identifier 42.42.42.1, local AS number 42
BGP table version is 3, main routing table version 3
2 network entries using 234 bytes of memory
2 path entries using 104 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 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 734 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.42.2    4    69       5       5        3    0    0 00:01:18        1
R1#

R2# show ip bgp summary
BGP router identifier 69.69.69.1, local AS number 69
BGP table version is 3, main routing table version 3
2 network entries using 234 bytes of memory
2 path entries using 104 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 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 734 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.42.1    4    42       6       6        3    0    0 00:02:03        1
R2#

And if we take a look at our routing tables on each router, we should see that the networks we advertised into BGP do, indeed, show up on the other side:

R1# show ip route bgp
     69.0.0.0/24 is subnetted, 1 subnets
B       69.69.69.0 [20/0] via 192.168.42.2, 00:05:00
R1#

R2# show ip route bgp
     42.0.0.0/24 is subnetted, 1 subnets
B       42.42.42.0 [20/0] via 192.168.42.1, 00:04:52
R2#

Success! Later we’ll cover multihoming and the use of weights, local preferences, and MEDs to influence routing decisions.

Related Posts:

Configuring OSPF Authentication (Dynamips)

configuring a free vpn solution in your home

Basic NTP Configuration for Cisco Routers

Using weights to influence BGP routing

Configuring Basic OSPF (Dynamips)

Today, once again, I got annoyed by someone complaining about Microsoft “not including” a telnet client with Windows Vista, so here I am.

Most people will simply use another telnet client: PuTTY, TeraTerm Pro, or — my personal favorite — SecureCRT. The truth is, however, Microsoft actually did include a telnet client with Windows Vista. The problem is that it simply is not installed by default. Below is a step-by-step guide detailing how to install it:

• Start by opening up the Control Panel by clicking the Start button, then “Control Panel”
• Once in the control panel, click on “Programs”.
• Under “Programs and Features”, click on “Turn Windows features on or off”.
• If you get a “User Account Control” popup asking for your permission, click “Continue”
• In the “Windows Features” window that appears, scroll down and click the checkbox next to “Telnet client”.
• Click the “OK” button.
• Windows will then make you wait a random period of time while it installs the telnet client.
• Close the “Control Panel” window.

At this point, you can open up a command prompt (click “Start”, “All Programs”, “Accessories”, and “Command Prompt”) and start the telnet client by typing in “telnet” and pressing the Enter key.

See, wasn’t that simple!?

Related Posts:

linksys wrt54gs + openwrt

cheap laptops bad for vista, good for linux

open source ssl vpns?

handing out a static ip via cisco dhcp

Configuring FreeRADIUS to support Cisco AAA Clients

Related Posts:

new life goal: super mario brothers high score

nfl conference championship predictions

easter is cancelled

office 2008 available for download

microsoft office small business accounting 2006

This is just a quick lab I whipped up to demonstrate how to configure multilink PPP between a pair of routers. According to Cisco:

“Multilink PPP (also referred to as MP, MPPP, MLP, or Multilink) provides a method for spreading traffic across multiple physical WAN links while providing packet fragmentation and reassembly, proper sequencing, multivendor interoperability, and load balancing on inbound and outbound traffic.”

In other words, we can combine multiple physical connections into a single logical connection to provide increased bandwidth and/or load balancing.

Here’s what our topology looks like:

Pretty simple setup: two routers, R1 and R2, with two serial connections between their serial 0/0 and serial 0/1 interfaces. Let’s get right into it:

R1’s configuration

R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)# interface multilink 1
R1(config-if)#
*Mar  1 00:04:09.975: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down
R1(config-if)# ip address 192.168.42.1 255.255.255.252
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# interface serial 0/0
R1(config-if)# encapsulation ppp
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shutdown
R1(config-if)#
*Mar  1 00:05:07.467: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
R1(config-if)# interface serial 0/1
R1(config-if)# encapsulation ppp
R1(config-if)# ppp multilink
R1(config-if)# ppp multilink group 1
R1(config-if)# no shutdown
R1(config-if)# end
R1#
*Mar  1 00:05:33.679: %SYS-5-CONFIG_I: Configured from console by console
R1#
*Mar  1 00:05:35.019: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
R1#

R2’s configuration

Before starting to configure the other end of the link, I’ve started a debug so that we can see what is happening in the background:

R2# debug ppp multilink events
Multilink events debugging is on
R2#

R2# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)# interface multilink 1
*Mar  1 00:08:23.703: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to down
R2(config-if)# ip address 192.168.42.2 255.255.255.252
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)# interface serial 0/0
R2(config-if)# encapsulation ppp
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
*Mar  1 00:08:45.711: Se0/0 MLP: Added interface to multilink group Mu1
R2(config-if)# no shutdown
*Mar  1 00:08:52.231: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  1 00:08:52.343: Se0/0 MLP: Request add link to bundle
*Mar  1 00:08:52.343: Se0/0 MLP: Adding link to bundle
*Mar  1 00:08:52.355: Mu1 MLP: Added first link Se0/0 to bundle R1
R2(config-if)#
*Mar  1 00:08:52.363: %LINK-3-UPDOWN: Interface Multilink1, changed state to up
*Mar  1 00:08:53.339: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar  1 00:08:53.367: %LINEPROTO-5-UPDOWN: Line protocol on Interface Multilink1, changed state to up
R2(config-if)#

At this point, our multilink PPP session is up, although with only one link. It is completely usable and operational. Let’s go ahead and bring up the other serial link:

R2(config-if)# interface serial 0/1
R2(config-if)# encapsulation ppp
R2(config-if)# ppp multilink
R2(config-if)# ppp multilink group 1
R2(config-if)#
*Mar  1 00:12:22.647: Se0/1 MLP: Added interface to multilink group Mu1
R2(config-if)# no shutdown
R2(config-if)# end
R2#
*Mar  1 00:12:32.195: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 00:12:32.399: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
R2#
*Mar  1 00:12:32.447: Se0/1 MLP: Request add link to bundle
*Mar  1 00:12:32.447: Se0/1 MLP: Adding link to bundle
*Mar  1 00:12:32.459: Mu1 MLP: Added link Se0/1 to bundle R1
*Mar  1 00:12:33.447: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
R2#

We see that the other serial link has came up and been automatically added to the “bundle”, just as the first one was.

Verifying Multilink PPP

We can verify the proper operation of our multilink PPP configuration easily:

R1# show ppp multilink

Multilink1, bundle name is R2
  Endpoint discriminator is R2
  Bundle up for 00:06:17, total bandwidth 3088, load 1/255
  Receive buffer limit 24000 bytes, frag timeout 1000 ms
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x6 received sequence, 0x6 sent sequence
  Member links: 2 active, 0 inactive (max not set, min not set)
    Se0/0, since 00:06:17
    Se0/1, since 00:02:37
No inactive multilink interfaces
R1#

From the output above, we see that our “bundle”, R2, has two links (serial 0/0 and serial 0/1), both of which are active. We also see that there are no inactive links. In addition, note that the bandwidth of this link is 3088 Kbps — twice the bandwidth of a normal T-1. Let’s ping the remote end to verify connectivity:

R1# ping 192.168.42.2

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

Success! It works just as expected!

UPDATE: About a month and a half ago, I posted a “Configuring Multilink PPP” video which shows the configuration being done “live”, although without audio (I forgot to turn off “mute” on my headset). I’ve included it here:

Related Posts:

Configuring Basic BGP

video: configuring multilink ppp

Configuring OSPF Authentication (Dynamips)

configuring a free vpn solution in your home

dynamips labs topologies anyone?

I’m real tempted to ditch Twitter.

I interact with Twitter in three ways:

• through their web site
• through SMS
• through ping.fm

.

Most of my interaction with Twitter is through SMS. Nearly all of the updates that I receive from Twitter are via SMS. I “follow” a number of people (74, as I write this) but receive updates via SMS for perhaps only a third of those. I started out having everyone’s updates sent to me via SMS, but some people either 1) post way too frequently and end up annoying the shit out of me or 2) just don’t say enough interesting things (e.g., the “signal-to-noise” ratio is way outta control).

Most (but not all) of my updates are done through ping.fm. My BlackBerry has an AIM client and that’s how I communicate with ping.fm. I send updates to “pingfm” on AIM and those are broadcasted out to Facebook, Pownce (which I hardly ever use), and Twitter. This is nice because I can update Twitter and Facebook at the same time. Because I don’t want every update going to Facebook (e.g. “@ replies”), I usually send those back to Twitter as an SMS.

Last, if I’m at home and on the computer I usually keep Twitter open in a tab and occasionally refresh it, just to keep up on everyone that I don’t receive SMS updates for.

When I first signed up for Twitter, my primary method of interacting with it was via IM. The “track” feature was awesome and allowed me to find others who had similar interests as mine. Once the shit hit the fan with regard to IM (in other words, when it became massively unreliable), they pulled support for it. Suckage.

Then, several months ago, the Twitter service as a whole became extremely unreliable for a good period. A number of folks jumped ship then. I almost did, but I stuck around.

Today, I read on the Twitter blog that they pulled support for receiving SMS updates in Canada (due to rising costs). Since Twitter has no apparent business model (and, it seems, isn’t generating any revenue), it makes sense to assume that eventually the cash supply will be running low. At some point, they’ll pull support for SMS updates in the U.S. as well, at which time I’ll really have no use for the service anymore.

Maybe I should just get out now.

Are there any viable alternatives? It’d be nice to be able to send and receive updates via SMS. I’d be content with receiving updates via SMS and sending updates through another method (e.g. ping.fm, web only, etc.). What are my choices?

Related Posts:

Twitter Updates

twitter

ping.fm beta code

cracking wep in 96 seconds

reflection and reassessment

Let’s continue on from yesterday’s lab, “Configuring Basic OSPF“. We’ve had a new requirement added to our original design: authenticated OSPF.

Our security team has decided that it is a potential security risk to run unauthenticated OSPF across our network backbone and have asked us to implement a secure method of sending OSPF updates.

OSPF authentication comes in two forms: plain-text and MD5. Because a “secure method” was specified, we have to use MD5 authentication in our environment (plain-text is not “secure”).

Using “pwgen” on an Ubuntu Linux box (”sudo apt-get install pwgen”), I came up with a random key of “xooph8MuBaeph5ee”. This is the authentication key I’ll use for OSPF. You are, of course, free to use something else (and encouraged to do so!).

Since we already have an environment up and running (see the “Configuring Basic OSPF” lab), we just need to add OSPF authentication to our configs and then verify proper operation. Let’s get started.

The actual configuration to enable OSPF authentication is pretty simple. There’s a quick two-part process: 1) create our authentication key (per interface) and 2) tell OSPF to use this authentication key. We’ll knock them both out at once on each router:

ISP# configure terminal
ISP(config)# interface fastethernet 0/0
ISP(config-if)# ip ospf message-digest-key 1 md5 xooph8MuBaeph5ee
ISP(config-if)# router ospf 1
ISP(config-router)# area 0 authentication message-digest 
ISP(config-router)# end
ISP#

Shortly after entering the above configuration, you should have noticed that both of your adjacencies (to Remote1 and Remote2) went from “FULL” to “DOWN”. This is because the ISP router is now sending authenticated OSPF updates and is expecting to receive them as well. Let’s configure the Remote1 router:

REMOTE1# configure terminal
REMOTE1(config)# interface fastethernet 0/0
REMOTE1(config-if)# ip ospf message-digest-key 1 md5 xooph8MuBaeph5ee
REMOTE1(config-if)# router ospf 1
REMOTE1(config-router)# area 0 authentication message-digest 
REMOTE1(config-router)# end
REMOTE1#

What we see on Remote1 is a bit different. After entering the configuration, we should notice two things. First, the adjacency with Remote2 will go down (for the same reasons as with ISP router above). In addition, we should see the adjacency with the ISP router come back up as both are now sending (and expecting to receive) authenticated updates.

If we run “show ip ospf neighbor” on each router, we should see that ISP and Remote1 have an adjacency formed but that Remote2 does not have any adjacencies. Let’s verify this:

ISP# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.3      254   FULL/BDR        00:00:36    10.10.10.3      FastEthernet0/0
ISP#

REMOTE1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.1      255   FULL/DR         00:00:32    10.10.10.1      FastEthernet0/0
REMOTE1#

REMOTE2# show ip ospf neighbor

REMOTE2#

All we need to do to get all of our adjacencies back up is to configure OSPF authentication on Remote2 just like we did the other two routers. We should then see our adjacencies form again:

REMOTE2# configure terminal
REMOTE2(config)# interface fastethernet 0/0
REMOTE2(config-if)# ip ospf message-digest-key 1 md5 xooph8MuBaeph5ee
REMOTE2(config-if)# router ospf 1
REMOTE2(config-router)# area 0 authentication message-digest
REMOTE2(config-router)# end
REMOTE2#

And, indeed, we’ll see the adjacencies form. By looking at the output of “show ip route” we can verify convergence, but how can be know that authentication is actually being used?

Let’s run a “debug ip ospf adj” on ISP router and take a look at the output:

ISP# debug ip ospf adj
OSPF adjacency events debugging is on
ISP#
*Mar  1 00:28:18.055: OSPF: Send with youngest Key 1
ISP#
*Mar  1 00:28:28.055: OSPF: Send with youngest Key 1
ISP#
*Mar  1 00:28:38.055: OSPF: Send with youngest Key 1
ISP#
*Mar  1 00:28:48.055: OSPF: Send with youngest Key 1
ISP#undebug all
All possible debugging has been turned off
ISP#

Success! We’ve now added authentication to our OSPF updates which will make our security team happy — and now they owe us a beer!

Related Posts:

Configuring Basic OSPF (Dynamips)

nifty postfix stuff

Basic NTP Configuration for Cisco Routers

configuring a free vpn solution in your home

dynamips labs topologies anyone?

In this lab, we have three routers at multiple locations that are connected through a switch, as shown in the diagram below:

We have been tasked with setting up OSPF on this network, with a few specific requirements:

• We must ensure that the ISP router is the designated router (DR)
• We must ensure that the Remote1 router is the backup designated router (BDR)
• We must ensure that the Remote2 router never participates in the election process
• Each router’s OSPF router ID should be the IP address of its FastEthernet 0/0 interface
• The ISP router should use its Loopback 0 interface as its default route and should advertise this default route through OSPF

The IP addresses that we will be using are as follows:

Device	Interface	IP Address	Subnet Mask
ISP	FastEthernet 0/0	10.10.10.1	255.255.255.248
	Loopback 0	188.46.37.254	255.255.255.252
Remote1	FastEthernet 0/0	10.10.10.3	255.255.255.248
	Loopback 0	192.168.1.1	255.255.255.192
	Loopback 1	192.168.1.161	255.255.255.240
Remote2	FastEthernet 0/0	10.10.10.2	255.255.255.248
	Loopback 0	192.168.1.65	255.255.255.192
	Loopback 1	192.168.1.129	255.255.255.224

The Dynagen .net file that we’re using for this lab is as follows:

autostart = False

[localhost:7200]

        workingdir = /home/jlgaddis/dynamips/working/ospf-lab

        [[3640]]
                image = /home/jlgaddis/dynamips/ios/c3640-js-mz.124-17.img
                idlepc = 0x604c37fc
                ram = 128
                disk0 = 8
                disk1 = 0
                mmap = true
                ghostios = true

        [[router ISP]]
                model = 3640
                console = 2000
                slot0 = NM-1FE-TX
                fa0/0 = SW 10

        [[router Remote1]]
                model = 3640
                console = 2001
                slot0 = NM-1FE-TX
                fa0/0 = SW 1

        [[router Remote2]]
                model = 3640
                console = 2002
                slot0 = NM-1FE-TX
                fa0/0 = SW 24

        [[ethsw SW]]
                1 = access 1
                10 = access 1
                24 = access 1

With all necessary information in hand and our lab configured, let’s get started!

Configuring the interfaces

Our first step will be to configure the interfaces on all three routers with the IP addressing information in the table above. This should be fairly straightforward.

ISP# configure terminal
ISP(config)# interface fastethernet 0/0
ISP(config-if)# ip address 10.10.10.1 255.255.255.248
ISP(config-if)# no shutdown
ISP(config-if)# interface loopback 0
ISP(config-if)# ip address 188.46.37.254 255.255.255.252
ISP(config-if)# end
ISP#

Remote1# configure terminal
Remote1(config)# interface fastethernet 0/0
Remote1(config-if)# ip address 10.10.10.3 255.255.255.248
Remote1(config-if)# no shutdown
Remote1(config-if)# interface loopback 0
Remote1(config-if)# ip address 192.168.1.1 255.255.255.192
Remote1(config-if)# interface loopback 1
Remote1(config-if)# ip address 192.168.1.161 255.255.255.240
Remote1(config-if)# end
Remote1#

Remote2# configure terminal
Remote2(config)# interface fastethernet 0/0
Remote2(config-if)# ip address 10.10.10.2 255.255.255.248
Remote2(config-if)# no shutdown
Remote2(config-if)# interface loopback 0
Remote2(config-if)# ip address 192.168.1.65 255.255.255.192
Remote2(config-if)# interface loopback 1
Remote2(config-if)# ip address 192.168.1.129 255.255.255.224
Remote2(config-if)# end
Remote2#

Verifying connectivity

From the ISP router, we should now be able to ping the Remote1 and Remote2 routers:

ISP# ping 10.10.10.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/42/96 ms
ISP# ping 10.10.10.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/33/84 ms
ISP#

Configuring basic OSPF

Let’s get started with the OSPF configuration. For now, we won’t worry about the DR/BDR or router-id requirements, we just want to get our OSPF adjacencies up. We DO want to advertise all networks, including the Loopback interfaces, into the backbone area (”Area 0″):

ISP# configure terminal
ISP(config)# router ospf 1
ISP(config-router)# network 188.46.37.252 0.0.0.3 area 0
ISP(config-router)# network 10.10.10.0 0.0.0.7 area 0
ISP(config-router)# end
ISP#

Remote1# configure terminal
Remote1(config)# router ospf 1
Remote1(config-router)# network 192.168.1.0 0.0.0.63 area 0
Remote1(config-router)# network 192.168.1.160 0.0.0.15 area 0
Remote1(config-router)# network 10.10.10.0 0.0.0.7 area 0
Remote1(config-router)# end
Remote1#

Remote2# configure terminal
Remote2(config)# router ospf 1
Remote2(config-router)# network 192.168.1.64 0.0.0.63 area 0
Remote2(config-router)# network 192.168.1.128 0.0.0.31 area 0
Remote2(config-router)# network 10.10.10.0 0.0.0.7 area 0
Remote2(config-router)# end
Remote2#

Verifying OSPF adjacencies

Shortly after configuring OSPF as above, we should have seen log messages on our console, letting us know that the OSPF adjacencies had been established. Each router should have established an adjacency with the other two. Let’s take a look:

ISP# show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.129     1   FULL/DROTHER    00:00:38    10.10.10.2      FastEthernet0/0
192.168.1.161     1   FULL/BDR        00:00:36    10.10.10.3      FastEthernet0/0
ISP#

Remote1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
188.46.37.254     1   FULL/DR         00:00:32    10.10.10.1      FastEthernet0/0
192.168.1.129     1   FULL/DROTHER    00:00:38    10.10.10.2      FastEthernet0/0
Remote1#

Remote2# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
188.46.37.254     1   FULL/DR         00:00:32    10.10.10.1      FastEthernet0/0
192.168.1.161     1   FULL/BDR        00:00:36    10.10.10.3      FastEthernet0/0
Remote2#

Looks like our adjacencies have formed just as we intended.

Configuring OSPF Router IDs

As mentioned in our requirements:

“Each router’s OSPF router ID should be the IP address of its FastEthernet 0/0 interface”

Because we are 1) in a Cisco environment and 2) using loopback interfaces, this will definitely not be the case. According to Cisco (see page three):

“The OSPF router ID is a 32-bit IP address selected at the start of the OSPF process. The highest IP address configured on the router is the router ID. If a loopback address is configured, it is the router ID. In the case of multiple loopback addresses, the highest loopback address is the router ID. Once the router ID is elected, it does not change unless OSPF restarts or is manually changed with the router-id command.”

Since each router has at least one loopback interface, the default router ID chosen will not be the one that our requirements dictate. Let’s configure them manually:

ISP# configure terminal
ISP(config)# router ospf 1
ISP(config-router)# router-id 10.10.10.1
Reload or use "clear ip ospf process" command, for this to take effect
ISP(config-router)# end
ISP#

Remote1# configure terminal
Remote1(config)# router ospf 1
Remote1(config-router)# router-id 10.10.10.3
Reload or use "clear ip ospf process" command, for this to take effect
Remote1(config-router)# end
Remote1#

Remote2# configure terminal
Remote2(config)# router ospf 1
Remote2(config-router)# router-id 10.10.10.2
Reload or use "clear ip ospf process" command, for this to take effect
Remote2(config-router)# end
Remote2#

Note that IOS warned us that the router ID will not change until the OSPF process restarts (either manually or via a router reload). We’ll hold off on that for now.

Meeting the designated router (DR)/backup designated router (BDR) requirements

From the output of “show ip ospf neighbor” above, we can tell that the ISP router has been elected as our DR and that the Remote1 router has been elected as our BDR. This is merely a result of the order in which we configured the routers (and, subsequently, the order in which the adjacencies formed). To fully meet the requirements, we must ensure that, under normal circumstances, the ISP router will be the DR, the Remote1 router will be the BDR, and that the Remote2 will never even attempt to participate in the election process.

This is actually pretty easy to configure and can be done by setting OSPF priorities.

First, to ensure that the ISP router will be the DR, we’ll give it the highest possible OSPF priority (note that this is configured under the appropriate interface):

ISP# configure terminal
ISP(config)# interface fastethernet 0/0
ISP(config-if)# ip ospf priority 255
ISP(config-if)# end
ISP#

Next, to ensure that the Remote2 router never participates in the election process we can set its OSPF priority to zero:

Remote2# configure terminal
Remote2(config)# interface fastethernet 0/0
Remote2(config-if)# ip ospf priority 0
Remote2(config-if)# end
Remote2#

With our current configuration, the Remote1 router will always end up as the BDR. What if, however, we later added another router to the network. Because it would, by default, also have an OSPF priority of 1, it is possible that it could take over the role of BDR. While, according to our requirements, changing Remote1’s OSPF priority is not needed, let’s set it to 254 just for good measure:

Remote1# configure terminal
Remote1(config)# interface fastethernet 0/0
Remote1(config-if)# ip ospf priority 254
Remote1(config-if)# end
Remote1#

Restarting the OSPF process

At this point, we should be in good shape and have met all requirements except one. Let’s go ahead and restart the OSPF process on each router to have our changes (OSPF priorities and router IDs) take effect. I’ll restart them in the following order to ensure the elections result in our desired configuration: ISP, Remote1, Remote2.

ISP# clear ip ospf process
Reset OSPF process? [no]: yes
ISP#

Remote1# clear ip ospf process
Reset OSPF process? [no]: yes
Remote1#

Remote2# clear ip ospf process
Reset OSPF process? [no]: yes
Remote2#

We should see our adjacencies go down and new adjacencies form using the new OSPF router IDs. From the ISP router, we can verify that the new router IDs are being used and also see which routers have our DR and BDR roles:

ISP# show ip ospf interface fastethernet 0/0
FastEthernet0/0 is up, line protocol is up 
  Internet Address 10.10.10.1/29, Area 0 
  Process ID 1, Router ID 10.10.10.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 255 
  Designated Router (ID) 10.10.10.1, Interface address 10.10.10.1
  Backup Designated router (ID) 10.10.10.3, Interface address 10.10.10.3
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:08
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 2, Adjacent neighbor count is 2 
    Adjacent with neighbor 10.10.10.2
    Adjacent with neighbor 10.10.10.3  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)
ISP#

Verifying advertisement of OSPF routes:

Let’s take a look at the routing table on each router to ensure that our routes are being advertised throughout the OSPF area:

ISP# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     188.46.0.0/30 is subnetted, 1 subnets
C       188.46.37.252 is directly connected, Loopback0
     10.0.0.0/29 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     192.168.1.0/32 is subnetted, 4 subnets
O       192.168.1.65 [110/2] via 10.10.10.2, 00:01:53, FastEthernet0/0
O       192.168.1.1 [110/2] via 10.10.10.3, 00:01:53, FastEthernet0/0
O       192.168.1.161 [110/2] via 10.10.10.3, 00:01:53, FastEthernet0/0
O       192.168.1.129 [110/2] via 10.10.10.2, 00:01:53, FastEthernet0/0
ISP#

Remote1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     188.46.0.0/32 is subnetted, 1 subnets
O       188.46.37.254 [110/2] via 10.10.10.1, 00:01:53, FastEthernet0/0
     10.0.0.0/29 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     192.168.1.0/24 is variably subnetted, 4 subnets, 3 masks
O       192.168.1.65/32 [110/2] via 10.10.10.2, 00:01:53, FastEthernet0/0
C       192.168.1.0/26 is directly connected, Loopback0
C       192.168.1.160/28 is directly connected, Loopback1
O       192.168.1.129/32 [110/2] via 10.10.10.2, 00:01:53, FastEthernet0/0
Remote1#

Remote2# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     188.46.0.0/32 is subnetted, 1 subnets
O       188.46.37.254 [110/2] via 10.10.10.1, 00:01:53, FastEthernet0/0
     10.0.0.0/29 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, FastEthernet0/0
     192.168.1.0/24 is variably subnetted, 4 subnets, 3 masks
C       192.168.1.64/26 is directly connected, Loopback0
O       192.168.1.1/32 [110/2] via 10.10.10.3, 00:01:53, FastEthernet0/0
O       192.168.1.161/32 [110/2] via 10.10.10.3, 00:01:53, FastEthernet0/0
C       192.168.1.128/27 is directly connected, Loopback1
Remote2#

Okay, our routing tables look good; all networks are being advertised and we should have full connectivity.

Default route requirement

Our last requirement states:

“The ISP router should use its Loopback 0 interface as its default route and should advertise this default route through OSPF”

Easy enough, right? Let’s do it:

ISP# configure terminal
ISP(config)# ip route 0.0.0.0 0.0.0.0 loopback 0
ISP(config)# router ospf 1
ISP(config-router)# default-information originate
ISP(config-router)# end
ISP#

Verify default route on ISP router

First, let’s make sure the default route made it into the routing table on the ISP router:

ISP# show ip route | include 0.0.0.0/0
S*   0.0.0.0/0 is directly connected, Loopback0
ISP#

Excellent! A default route has been configured. Let’s make sure it’s being propagated to the other two routers:

Remote1# show ip route | include 0.0.0.0/0
O*E2 0.0.0.0/0 [110/1] via 10.10.10.1, 00:03:23, FastEthernet0/0
Remote1#

Remote2# show ip route | include 0.0.0.0/0
O*E2 0.0.0.0/0 [110/1] via 10.10.10.1, 00:03:23, FastEthernet0/0
Remote2#

Awesome! The default route on ISP router is being advertised into OSPF and picked up by the Remote1 and Remote2 routers.

We’ve now met all the requirements of the lab — our work here is done.

Be sure and save your configurations, next time we add OSPF authentication to prevent unauthorized routing updates.

See you next time!

Related Posts:

Configuring OSPF Authentication (Dynamips)

Basic Frame Relay Lab for Dynamips

Configuring Basic BGP

configuring a free vpn solution in your home

dynamips labs topologies anyone?

• “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning.” –Unknown

I have no idea where this quote originated; if you do, let me know so that I can give proper credit.

Related Posts:

scientists call diebold security flaw ‘worst ever’

What is NTP?

• “The Network Time Protocol (NTP) is a protocol for distributing the Coordinated Universal Time (UTC) by means of synchronizing the clocks of computer systems over packet-switched, variable-latency data networks.” –Wikipedia

Why is NTP important?

• “Time is inherently important to the function of routers and networks. It provides the only frame of reference between all devices on the network. This makes synchronized time extremely important. Without synchronized time, accurately correlating information between devices becomes difficult, if not impossible. When it comes to security, if you cannot successfully compare logs between each of your routers and all your network servers, you will find it very hard to develop a reliable picture of an incident. Finally, even if you are able to put the pieces together, unsynchronized times, especially between log files, may give an attacker with a good attorney enough wiggle room to escape prosecution.” –Thomas Akin, in Hardening Cisco Routers.

NTP provides us (the network, systems, and security guys) with an easy way to ensure that all of our network devices have the same time. In smaller networks, this is desirable; in large networks, it is a must. In this lab, we’ll configure one Cisco router as both a client (synchronizing time from hosts on the Internet) and server (providing time synchronization to other internal devices).

Topology

Our physical topology looks like this:

Specifications

For our demonstration, R1 will be both an NTP client and NTP server while R2 will only be an NTP client. Because we will be synchronizing R1’s time with a host on the Internet, R1 will need connectivity to the Internet for this demonstration; R2 will not. R1’s actual connectivity to the Internet is irrelevant and out of the scope of this demonstration.

• R1 will synchronize time against nist.netservicesgroup.com (64.113.32.5).
• R2 will synchronize time against R1 (172.16.12.1).
• NTP synchronization between R1 and R2 will be authenticated, using a key of “ThereIsTimeForEverything“.

Configuring R1 as an NTP client

Before we get started, I first want to show that we currently have an unsynchronized clock:

R1# show clock detail
*00:01:19.099 UTC Fri Mar 1 2002
No time source
R1#

Configuring a Cisco router to act as an NTP client is extremely simple. We’ll use the “ntp server” command, followed by the IP address of the NTP server:

R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)# ntp server nist.netservicesgroup.com
Translating "nist.netservicesgroup.com"...domain server (192.168.1.12) [OK]

R1(config)#

That’s about all there is to it, from the client side. Note that if you do not have DNS configured on your devices, you’ll need to use IP addresses instead of fully qualified domain names (above). If we take a look at our clock, we’ll see that the time has been updated from NTP:

R1# show clock detail
03:15:52.593 UTC Sun Nov 23 2008
Time source is NTP

Let’s verify our NTP associations and status:

R1# show ntp associations

      address         ref clock     st  when  poll reach  delay  offset    disp
*~64.113.32.5      .ACTS.            1    45    64   17    36.2   -2.90  1901.2
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

R1# show ntp status
Clock is synchronized, stratum 2, reference is 64.113.32.5
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is CCD34DAA.B4D97B06 (03:34:02.706 UTC Sun Nov 23 2008)
clock offset is -2.8967 msec, root delay is 36.16 msec
root dispersion is 909.03 msec, peer dispersion is 906.13 msec

Note that the synchronization process could take up to five minutes. If you see “Clock is unsynchronized” in the output of “show ntp status”, wait a moment and run the command again. If you so desired, you could use “debug ntp events” to watch the communications and see what is happening. Make sure that R1 becomes synchronized before beginning to configure R2 — a device providing NTP services will not do so until the device itself is fully synchronized.

Configuring R1 as an NTP server

Configuring R1 to act as an NTP server is easy enough — it’s already done! As soon as R1 becomes synchronized, it will automatically begin answering NTP requests from other hosts. This is why access lists are important; we’ll cover those in a later lab.

Configuring R2 as an NTP client

Now we’ll configure R2 as an NTP client, just as we did with R1. Let’s first show that our clock is unsynchronized, then configure R2 to synchronize with R1:

R2# show clock detail
*02:16:24.771 UTC Fri Mar 1 2002
No time source

R2# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)# ntp server 172.16.12.1

After a moment, we should see that R2 is now successfully synchronizing time with R1:

R2# show clock detail
04:17:06.271 UTC Sun Nov 23 2008
Time source is NTP
R2# show ntp associations

      address         ref clock     st  when  poll reach  delay  offset    disp
*~172.16.12.1      64.113.32.5       2    17    64  377    35.9    2.41     7.8
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured
R2# show ntp status
Clock is synchronized, stratum 3, reference is 172.16.12.1
nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**18
reference time is CCD357B6.5807B0D4 (04:16:54.343 UTC Sun Nov 23 2008)
clock offset is 2.4103 msec, root delay is 55.85 msec
root dispersion is 261.81 msec, peer dispersion is 7.80 msec

Configuring NTP Authentication

As of now, we have time synchronization working between R1 and an external NTP server and between R1 and R2. Our security policy, however, dictates (hypothetically, of course) that NTP traffic between hosts inside our network must be authenticated. (For additional security, we would use authentication for requests between R1 and the external NTP server as well.)

It is important to note that configuring authentication doesn’t require clients to use authentication — it merely enables them to do so. Our NTP servers will still answer requests that are not authenticated, so we’ll want to use access lists to control access as well (coming in the next lab).

Our first step in turning on authentication is to enable it on R1. Recall from above that we’re going to use the key “ThereIsTimeForEverything” (bonus points for the first person to leave a comment below telling me who that quote is from!):

R1# configure terminal
R1(config)# ntp authenticate
R1(config)# ntp authentication-key 10 md5 ThereIsTimeForEverything
R1(config)# ntp trusted-key 10

Likewise, we must configure the same authentication key on R2 and instruct it to use that key when “speaking” NTP to R1:

R2# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)# ntp authenticate
R2(config)# ntp authentication-key 10 md5 ThereIsTimeForEverything
R2(config)# ntp trusted-key 10
R2(config)# ntp server 172.16.12.1 key 10

Shortly thereafter, we can check our NTP associations on R2 and we should see that the NTP exchanges between it and R1 are authenticated:

R2# show ntp associations detail 
172.16.12.1 configured, authenticated, our_master, sane, valid, stratum 2
ref ID 64.113.32.5, time CCD37909.8B261140 (06:39:05.543 UTC Sun Nov 23 2008)
our mode client, peer mode server, our poll intvl 128, peer poll intvl 128
root delay 20.14 msec, root disp 65.69, reach 377, sync dist 116.699
delay 7.81 msec, offset 116.2200 msec, dispersion 37.03
precision 2**18, version 3
org time CCD37929.2A38A6CA (06:39:37.164 UTC Sun Nov 23 2008)
rcv time CCD37929.17DC107A (06:39:37.093 UTC Sun Nov 23 2008)
xmt time CCD37929.07835CB1 (06:39:37.029 UTC Sun Nov 23 2008)
filtdelay =    63.72    7.81   55.88   48.10   48.02   48.02   36.01   55.95
filtoffset =  103.59  116.22  118.39   92.51   79.64   51.89   70.94   43.87
filterror =     0.02    0.99    1.60    3.56    5.51    7.46    8.44    8.97

Did you see it? Let’s filter out some of the output and look only at the line we’re concerned with:

R2# show ntp associations detail | include 172.16.12.1  
172.16.12.1 configured, authenticated, our_master, sane, valid, stratum 2

There it is: “authenticated“.

Okay, now what!?

Excellent, we’ve managed to configure R1 as an NTP client synchronizing against a public NTP server on the Internet as well as providing NTP services to internal hosts. We even enabled the ability of R1’s NTP clients to authenticate the responses they’re receiving from R1 (security of NTP is important).

Later, we’ll extend this lab to provide redundancy as well as implement access lists to increase the security of our NTP “infrastructure”.

Related Posts:

speed test results

HELL BID SC

Configuring Basic BGP

Basic Frame Relay Lab for Dynamips

ccna certified