Monthly Archives: October 2013

CCNP ROUTE Study – OSPF Authentication

authentication

We know that two OSPF routers will become neighbours if they can agree on certain parameters (see my previous post for details) and this is great, but suppose the bad guys were able to connect their own router to the same data link and then cause OSPF routing mayhem – how do we stop this???  

Authentication is the answer, and here’s how we do it.

With authentication enabled, every OSPF message sent between routers is authenticated using a pre-shared key. If authentication fails then routers will drop the hello packets, meaning an adjacency cannot form.

Authentication is enabled either per interface or per area, and there are three types of OSPF authentication

  • type 0 – none
  • type 1 – clear text
  • type 2 – MD5

The first example is per interface, type 2 authentication (type 1 is pointless anyway!). Here’s our configuration on R1 (with a matching config on R2):

interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.252
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 CCNPBABY!

To verify this, the show ip ospf interface command will show us that MD5 authentication is enabled and the id of the key being used:

R1#show ip ospf interface
Ethernet0/0 is up, line protocol is up
  Internet Address 10.0.0.1/30, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  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 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Designated Router)
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1

We can also turn on some debugging of ospf packets to verify. The output below shows that type 2 authentication is being used with key id 1:

R1#debug ip ospf packet
OSPF packet debugging is on
R1#
*Mar  1 00:18:00.455: OSPF: rcv. v:2 t:1 l:48 rid:2.2.2.2
      aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7EC8A1 from Ethernet0/0

The second example is per area, type 2 authentication. Here’s our configuration on R1 (with a matching config on R2):

!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 area 0 authentication message-digest
 network 10.0.0.0 0.0.0.3 area 0
!
!
interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.252
 ip ospf message-digest-key 1 md5 CCNPBABY!
 full-duplex

Use the same debugging and show commands as for the per interface config to verify, and you can now sleep a whole lot better at night knowing your OSPF network is secure!

I hope this has been a useful explanation.  Thanks for reading, and good luck with your CCNP studies!

Rich
 
Follow Rich on Twitter

CCNP ROUTE Study – OSPF adjacency set up

In this post we’re going to take a look at the process of two Cisco routers forming an OSPF neighbour adjacency, with an emphasis on what’s going on at a packet level. We’ll look at the packets sent and received on a multi-access network type, in this case Ethernet.

Here’s our network:

OSPF Neighbours

Our OSPF config on R1 looks like this:

router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.3 area 0

As soon as OSPF is enabled, R1 starts to send hello packets out of all interfaces matched by the network statement. These packets are sent to the All OSPF Routers Multicast address 224.0.0.5. Turn on some debugging and we can see this in action:

R1#debug ip ospf hello
OSPF hello events debugging is on
R1#
*Mar  1 06:32:30.270: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 10.0.0.1
R1#

Now is also good time to take a look at the output from the show ip ospf interface command. This is a great command for troubleshooting OSPF issues. Note some of the highlighted output:

R1#sh ip ospf interface
FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.1/30, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 1.1.1.1, Interface address 10.0.0.1
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:03
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

Now, if we start a packet capture with Wireshark we can take a look at the packets that each router is actually sending out across the wire.

Remember that there are 5 OSPF packet types:

  • type 1 – hello
  • type 2 – database description (DBD)
  • type 3 – link state request (LSR)
  • type 4 – link state update (LSU)
  • type 5 – link state acknowledgement (LSAck)

and 7 neighbour states:

  • state 1 – down
  • state 2 – init
  • state 3 – 2-way
  • state 4 – exstart
  • state 5 – exchange
  • state 6 – loading
  • state 7 – full

Here’s the first packet:

neighbours 0_1

As expected, it’s a type 1 Hello packet from R1. Starting with the IP header we can see that OSPF is IP protocol ID 89, and view the Src and Dst IP addresses:

neighbours 1

Moving on to the OSPF packet we can see the parameters that R1 is advertising to potential neighbours:

neighbours 2

So, at this point R1 is saying “HELLO” to any other devices listening on 224.0.0.5 on the ethernet segment that interface FastEthernet0/0 is connected to and advertising it’s OSPF settings. In order for a neighbour relationship to form, the following must match or be agreed upon by both sides:

  • subnet
  • area number
  • is this a stub area?
  • hello interval
  • dead timer interval
  • authentication (if used)
  • IP MTU

Next, we enable OSPF on R2 and the first thing it does is send out is it’s own type 1 hello packet to see if there are any routers out there able to become neighbours:

neighbours 3

R1 receives R2′s type 1 hello packet, and because both routers agree on the OSPF parameters , R1 places an entry for R2 in it’s neighbour table. At this point the two routers are in the Init state of OSPF.

Next, R1 sends another type 1 hello packet, but this time it is a unicast packet to R2′s IP address instead of a broadcast packet. Also note that in this packet, R1 states it has R2 as an active neighbour:

neighbours 4

At this point the routers are at the two way state. Next on the wire are two packets from R2 to R1. First is a type 2 – database description packet, followed by a type 1 hello packet indicating that R2 also has a neighbour (R1):

neighbours 5

neighbours 6

Now we are at the exstart state. Next comes the exchange state when the routers exchange type 2 – database description packets with each other. During this phase there is a master/slave election, after which the router with the highest router ID becomes the master:

neighbours 7

neighbours 8

neighbours 9

Next, we move onto the loading state, and we can see R2 sending a type 3 – link state request packet to R1, and R1 responding with a type 4 – link state update packet:

neighbours 10

neighbours 11

Our packet capture then shows three more type 4 – link state update packets (1 from R2 and 2 from R1), and these are sent to the All OSPF Routers Multicast address 224.0.0.5:

neighbours 12

neighbours 13

neighbours 14

Finally, we see a type 5 – link state acknowledgement packet from each router, again sent to the All OSPF Routers Multicast address 224.0.0.5:

neighbours 15

neighbours 16

Now that both routers link state databases have been synchronized, we have reached the full state, which we can can confirm with the show ip ospf neighbor command on R1:

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR        00:00:32    10.0.0.2        FastEthernet0/0

If we also check the show ip ospf interface command on R1 again, we can see it now reports R2 as being it’s neighbour and also that R2 is the designated router (DR):

R1#sh ip os int
FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.1/30, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:06
  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 2
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Designated Router)
  Suppress hello for 0 neighbor(s)

I hope this has been a useful explanation.  Thanks for reading, and good luck with your CCNP studies!

Rich

 

Follow Rich on Twitter

Junos Basics – Automatic Configuration Archiving

In my previous Junos Basics post I covered configuring a Juniper EX2200C switch as a DHCP server. In this post we’ll step through a really nice feature of Junos that is an absolute no-brainer – configuring your Juniper device to automatically back up a copy of it’s configuration file to an FTP server every time a new candidate configuration is committed. Why would you not enable this!?!?

We have an FTP server with an IP address of 192.168.1.101. The server has an FTP user account called juniper with a password of Jun0S.

Here’s our config:

system {
      archival {
        configuration {
            transfer-on-commit;
            archive-sites {
                "ftp://juniper:Jun0s@192.168.1.101";
                }
            }
      }
}

Now, each time a candidate configuration file is committed, a copy is sent the ftp server automatically.

As you can see this is a really useful feature that is really simple to set up.

I hope this has been a useful explanation.  

Thanks for reading.

Rich

Follow Rich on Twitter