OSPF LSA Types

For many years I’ve been struggling to memorize OSPF LSA types. Finally, I have decided to create a lab that shows all those LSA types that are supported by Cisco in OSPFv2 (IPv4-OSPF).

Here is my lab topology:

Lab Topology
Lab Topology

Type 1 – Router LSA

According to the documentation LSA type 1 is sent by any router within the area and contains the information about its directly connected links.

To see it I start packet capture in R1 Fa0/0 interface and reset the OSPF process at R2 to provoke LSA flood. Theoretically I should see two Type 1 LSA coming from R2: one for link 10.0.2.0/30 and another one for 10.0.1.0/24.

Here is what actually appears:

Screen Shot 12-14-15 at 05.20 PM

Two LSAs. One with unicast destination and one destined to “ALL OSPF ROUTERS” multicast address. Both contain the same information:

LSA1Capt1

Screen Shot 12-14-15 at 05.21 PM

The information on both links is passed inside one Type 1 LSA. Links are presented with their IDs. There is a proper alogithm to derive Link ID depending on link type, in case of Transit that appears in this LSA network it’s DR IP address. The reason why R2 sends two LSA probably has to do with Cisco implementation of OSPF and the fact that R2 has broadcast multicaccess segment connected to it’s Fa0/1 interface.

This is how Type 1 LSA has been sent:

LSA Type 1
LSA Type 1

Type 2 – Network LSA

Type 2 LSA is generated by DR elected for multiaccess segment to inform its neighbors about this segment existence. An example of such a segment is the interconnecion between R2 R3 and R4. From R2 we can see that R4 got elected as DR (it’s router ID is 172.16.2.1):

R2#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
172.16.1.1 1 FULL/BDR 00:00:37 10.0.1.1 FastEthernet0/1
172.16.2.1 1 FULL/DR 00:00:34 10.0.1.2 FastEthernet0/1

So putting capture on R2 fa0/0 and resetting its OSPF process we should get Type 2 LSA from R4 containing information on R2-R3-R4 segment. Here it is, packed together with some other LSAs:

LSA Type 2
LSA Type 2

Notice the subnet mask for the segment, DR ID (Advertising Router) and three attached router IDs.

So Type 2 LSA flow is the following:

LSA Type 2

LSA Type 2

This type of LSA then gets resent by all the routers within the area (in this example R2 will resend it to R1). Advertising router field within the LSA will retain its original value as R4 being the DR is the one responsible for the LSA.

Type 3 – Summary LSA

Type 3 LSAs are sent by ABR. When a link-state change occurs within one of the areas connected to it, it sends this type of LSA to all the other areas thus notifying them about that change. For example, when R2 Fa0/0 link goes down we can expect R3 to notify R6 about this change with Type 3 LSA.

Setting capture for Fa0/0 on R6 and shutting down Fa0/0 on R2 we get the following:

Type 3 LSA
Type 3 LSA

Notice the Metric field value. Setting it to 16777215 (FFFFFF hexadecimal) is a way to mark link as unreachable and signal to other OSPF routers to withdraw its data from their databases.

R3 generates Type 3 LSA because it gets notified of the change by Type 1 LSA coming from R2. Here is the flow diagram:

LSA Type 3
LSA Type 3

Please note that the name “summary LSA” has nothing to do with route summarization feature. Nothing gets summarized here, at least by default.

Type 4 – ASBR summary LSA

Type 4 LSAs are also sent by ABR. By using them ABR notifies it’s connected areas about the presence of ASBR in any of these areas. In my topology R3(ABR) would notify R6 which is in Area 1 about the presence of R1(ASBR) in Area 0 using LSA of this type. Later on R6 will receive some external route information from R1 and the Type 5 LSA announcing this route will contain R1 Router ID, saying that this external network is behind R1. Data obtained by R6 from Type 4 LSA will tell it that R1 is behind R3.

What makes router an ASBR and thus provokes LSA Type 4 generation? It’s route redistribution from any other routing process or protocol into OSPF occurring at this router. In my topology R1 is an ASBR as it redistributes routes from RIP into OSPF.

So, again, R3, being an ABR, should notify R6 about the presence of R1 using Type 4 LSA. But how does R3 get to know that R1 is an ASBR and not just any common intra-area router? The answer is: R1 notifies everyone within Area 0 of itself being an ASBR by setting a special (E) flag in Type 1 LSAs it sends. Here it is:

Type 1 LSA with E flag set
Type 1 LSA with E flag set

Wireshark already interprets E flag set as “AS boundary router”.

So when R3 receives this LSA it sends Type 4 LSA to notify R6:

Type 4 LSA
Type 4 LSA

Advertising router field contains R3 Router-ID, Link State ID contains R1 (ASBR) Router ID.

Here is what the process looks like:

LSA Type 4
LSA Type 4

Type 5 – External LSA

LSA Type 5 is used to advertise external routes in all the OSPF areas. External in this case means not calculated or generated by OSPF process, but redistributed from other routing protocols, redistributed static or connected routes. As an example route for 192.168.99.0/24 network should be advertised by R1 using this type of LSA.

Putting R7 Loopback0 interface into shutdown provokes LSA flooding out of R1 FastEthernet0/0 notifying it as unreachable. Here is the capture:

LSA Type 5
LSA Type 5
LSA Type 5
LSA Type 5

Type 7 – NSSA External LSA

This LSA Type contains external routes information as well as Type 5 LSA. The difference is that Type 7 LSA is propagated across Not-so-Stubby area and Type 5 LSA is not. On ABR that connects NSSA to Backbone area Type 7 LSA gets converted into Type 5 LSA.

In my topology R5 should notify R4 about changes with interface Loopback0 (172.16.102.0/24 subnet) using this type of LSA.

Here is a Type 7 LSA sent by R5 on it’s Loopback0 shutdown:

LSA Type 7
LSA Type 7

and here is LSA 5 generated by R4 for Area0, containing information on the same link:

LSA Type 5 generated by ABR, based on the information from received LSA Type 7
LSA Type 5 generated by ABR, based on the information from received LSA Type 7
LSA Type 7
LSA Type 7

 

Layer 2 across Layer 3. Part 1 – L2TP

Several tasks I’ve been up to recently have made me study solutions to interconnect Layer 2 network segments across Layer 3 infrastructure. I decided to do a series of quick review of the technologies that serve this purpose. The most detailed information could be found in standards and vendors documents, there is no point to rewrite all of it here. What I was intended to is just produce a sort of quick reference/cheatsheet for what I have studied.

The first is Layer 2 Tunneling Protocol.

Lab 

Here is a network diagram I used:

Lab Diagram
Lab Diagram
  • R4 and R5 represent two hosts in the same VLAN. Those are the ones that need to be interconnected across the WAN.
  • R2 and R3 represent border routers in each location.
  • R1 is just a transport WAN emulation.

Starting configuration for border routers:

R2 R3
interface FastEthernet0/0
  description -= WAN =-
  ip address 115.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 115.0.0.1
interface FastEthernet0/0
 description -= WAN =-
 ip address 116.0.0.2 255.255.255.252
ip route 0.0.0.0 0.0.0.0 116.0.0.1

The starting configuration for R1, R4 and R5 is just IP addresses assigned to interfaces according to the diagram.

The basic L2TPv3 configuration

L2TP is probably the most straightforward method to implement Layer-2 interconnection across Layer-3 WAN. Basic config looks like this:

R2

pseudowire-class test-pw-class
encapsulation l2tpv3
ip local interface FastEthernet0/0
interface FastEthernet2/0
description -= LAN =-
no ip address
xconnect 116.0.0.2 123 encapsulation l2tpv3 pw-class test-pw-class

R3

pseudowire-class test-pw-class
encapsulation l2tpv3
ip local interface FastEthernet0/0
interface FastEthernet2/0
description -= LAN =-
no ip address
xconnect 116.0.0.2 123 encapsulation l2tpv3 pw-class test-pw-class

Here is the result:

L2TPv3 Tunnel Established
L2TP Tunnel Established

All the traffic coming to FastEthernet 2/0 port of any of the border routers gets encapsulated and sent to the opposite site where it gets decapsulated while going out of another FastEthernet 2/0 interface. As a result we can ping R5 from R4 and vice versa as if they were connected directly by Layer-2 link:

R5#ping 192.168.1.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.4, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 88/98/120 ms
R4#ping 192.168.1.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/116/156 ms

The broadcast traffic also gets propagated successfully:

R4#ping 255.255.255.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
Reply to request 0 from 192.168.1.5, 152 ms
Reply to request 1 from 192.168.1.5, 108 ms
Reply to request 2 from 192.168.1.5, 152 ms
Reply to request 3 from 192.168.1.5, 104 ms

Some theory

The obvious advantage of L2TP is that in order to implement it you don’t need anything but Layer 3 connectivity between devices that will terminate both ends of the tunnel.

Here is what happens to the Layer 2 Payload when it gets transferred over the tunnel:

Encapsulation Scheme
Encapsulation Scheme

First, L2TPv3 Header gets added to the original Layer 2 Frame. It contains all the information needed to identify the Tunnel and the Session.

Second IP Delivery Header containing source and destination IP addresses of the tunnel peers (in our case R2 and R3 routers) and UDP Header are added to deliver the packet to the other end device that will decapsulate it. On transport layer L2TPv3 uses port 1701.

The packet flow to establish the connection is the following:

L2TP Control Packet Flow
L2TP Control Packet Flow

Verifying 

Checking tunnel and session states:

R2#show l2tun

L2TP Tunnel and Session Information Total tunnels 1 sessions 1

LocTunID   RemTunID   Remote Name   State  Remote Address  Sessn L2TP Class/
                                                           Count VPDN Group
1401476767 197244710  R3            est    116.0.0.2       1     l2tp_default_cl

LocID      RemID      TunID      Username, Intf/      State  Last Chg Uniq ID
                                 Vcid, Circuit
4141636091 3431548551 1401476767 123, Fa2/0           est    00:02:50 1

You can see the tunnel Virtual Circuit ID 123 configured and it’s state as established.

Here is a debug command showing tunnel establishment process where you can see packets related to tunnel setup marked bold. R2 plays the role of the server in this case, so the tunnel establishment process begins with it receiving SCCRQ, responds SCCRP and so on. Notice also the states the system passes through (Idle, Proc-SCCRQ, Wt-SCCN, etc.) till it gets to established.

R2#debug l2tp event
*Dec  8 23:52:23.159: L2X  tnl   08318:________: Create logical tunnel
*Dec  8 23:52:23.159: L2TP tnl   08318:________: Create tunnel
*Dec  8 23:52:23.163: L2TP tnl   08318:________:     version set to Cisco-V3
*Dec  8 23:52:23.163: L2TP tnl   08318:________:     remote ip set to 116.0.0.2
*Dec  8 23:52:23.167: L2TP tnl   08318:________:     local ip set to 115.0.0.2
*Dec  8 23:52:23.175: L2TP tnl   08318:70A47756: FSM-CC ev Rx-SCCRQ
*Dec  8 23:52:23.175: L2TP tnl   08318:70A47756: FSM-CC    Idle->Proc-SCCRQ
*Dec  8 23:52:23.179: L2TP tnl   08318:70A47756: FSM-CC do Rx-SCCRQ
*Dec  8 23:52:23.183: L2TP tnl   08318:70A47756:     class name l2tp_default_class
*Dec  8 23:52:23.191: L2TP       _____:________: Check for existing cc
*Dec  8 23:52:23.191: L2TP       _____:________:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.195: L2TP       _____:________:   and peer router id: 116.0.0.2
*Dec  8 23:52:23.195: L2TP       _____:________:   and peer hostname: R3
*Dec  8 23:52:23.199: L2TP       _____:________:   and version: V3
*Dec  8 23:52:23.203: L2TP       _____:________:   No other cc exists to tie with
*Dec  8 23:52:23.203: L2TP tnl   08318:70A47756: FSM-CC ev SCCRQ-OK
*Dec  8 23:52:23.207: L2TP tnl   08318:70A47756: FSM-CC    Proc-SCCRQ->Wt-SCCCN
*Dec  8 23:52:23.207: L2TP tnl   08318:70A47756: FSM-CC do Tx-SCCRP
*Dec  8 23:52:23.211: L2X        _____:________: l2x_open_socket: is called
*Dec  8 23:52:23.211: L2TP tnl   08318:70A47756: Open sock 115.0.0.2:0->116.0.0.2:0
*Dec  8 23:52:23.215: L2TP tnl   08318:70A47756: FSM-CC ev Sock-Ready
*Dec  8 23:52:23.215: L2TP tnl   08318:70A47756: FSM-CC    in Wt-SCCCN
*Dec  8 23:52:23.219: L2TP tnl   08318:70A47756: FSM-CC do Ignore-Sock-Up
*Dec  8 23:52:23.355: L2TP tnl   08318:70A47756: FSM-CC ev Rx-SCCCN
*Dec  8 23:52:23.359: L2TP tnl   08318:70A47756: FSM-CC    Wt-SCCCN->Proc-SCCCN
*Dec  8 23:52:23.359: L2TP tnl   08318:70A47756: FSM-CC do Rx-SCCCN
*Dec  8 23:52:23.379: L2TP tnl   08318:70A47756: FSM-CC ev SCCCN-OK
*Dec  8 23:52:23.379: L2TP tnl   08318:70A47756: FSM-CC    Proc-SCCCN->established
*Dec  8 23:52:23.383: L2TP tnl   08318:70A47756: FSM-CC do Established
*Dec  8 23:52:23.383: L2TP tnl   08318:70A47756: Control channel up
*Dec  8 23:52:23.387: L2TP tnl   08318:70A47756:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.431: L2X  _____:_____:________: Create logical session
*Dec  8 23:52:23.435: L2TP _____:_____:________: Create session
*Dec  8 23:52:23.435: L2TP _____:_____:________:   Using ICRQ FSM
*Dec  8 23:52:23.439: L2TP _____:_____:________: FSM-Sn ev created
*Dec  8 23:52:23.439: L2TP _____:_____:________: FSM-Sn    Init->Idle
*Dec  8 23:52:23.443: L2TP _____:_____:________: FSM-Sn do none
*Dec  8 23:52:23.443: L2TP _____:_____:________:     remote ip set to 116.0.0.2
*Dec  8 23:52:23.447: L2TP _____:_____:________:     local ip set to 115.0.0.2
*Dec  8 23:52:23.451: L2TP tnl   08318:70A47756: FSM-CC ev Session-Conn
*Dec  8 23:52:23.451: L2TP tnl   08318:70A47756: FSM-CC    in established
*Dec  8 23:52:23.455: L2TP tnl   08318:70A47756: FSM-CC do Session-Conn-Est
*Dec  8 23:52:23.455: L2TP tnl   08318:70A47756:   Session count now 1
*Dec  8 23:52:23.459: L2TP _____:08318:ECEDBDCE: FSM-Sn ev CC-Up
*Dec  8 23:52:23.459: L2TP _____:08318:ECEDBDCE: FSM-Sn    in Idle
*Dec  8 23:52:23.463: L2TP _____:08318:ECEDBDCE: FSM-Sn do CC-Up-Ignore0-1
*Dec  8 23:52:23.463: L2TP _____:08318:ECEDBDCE: Session attached
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn ev Rx-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn    Idle->Proc-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE: FSM-Sn do Rx-ICRQ
*Dec  8 23:52:23.467: L2TP _____:08318:ECEDBDCE:   Chose application XCONNECT
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE:   App type set to XCONNECT
*Dec  8 23:52:23.471: L2TP tnl   08318:70A47756:   XCONNECT Session count now 1
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: Remote AC is now UP
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.471: L2TP _____:08318:ECEDBDCE: Set HA epoch to 0
*Dec  8 23:52:23.475: L2TP _____:08318:ECEDBDCE:
*Dec  8 23:52:23.495: L2X  _____:_____:________: Destroying logical session
*Dec  8 23:52:23.495: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.499: L2TP 00001:08318:ECEDBDCE:   App type set to XCONNECT
*Dec  8 23:52:23.499: L2TP 00001:08318:ECEDBDCE:   Need cc version: Cisco-V3
*Dec  8 23:52:23.503: L2TP 00001:08318:ECEDBDCE:   Sequencing default tx disabled
*Dec  8 23:52:23.507: L2TP 00001:08318:ECEDBDCE:   Sequencing default rx disabled
*Dec  8 23:52:23.507: L2TP 00001:08318:ECEDBDCE: no cookies enabled
*Dec  8 23:52:23.511: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev ICRQ-OK
*Dec  8 23:52:23.511: L2TP 00001:08318:ECEDBDCE: FSM-Sn Proc-ICRQ->Wt-Tx-ICRP
*Dec  8 23:52:23.515: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Tx-ICRP-Local-Check
*Dec  8 23:52:23.515: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Local-Cont
*Dec  8 23:52:23.519: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Wt-Tx-ICRP->Wt-Rx-ICCN
*Dec  8 23:52:23.519: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Tx-ICRP
*Dec  8 23:52:23.523: L2X        _____:________: l2x_open_socket: is called
*Dec  8 23:52:23.527: L2TP 00001:08318:ECEDBDCE: Open sock 115.0.0.2:0->116.0.0.2:0
*Dec  8 23:52:23.527: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Sock-Ready
*Dec  8 23:52:23.531: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in Wt-Rx-ICCN
*Dec  8 23:52:23.535: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-Sock-Up
*Dec  8 23:52:23.555: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.559: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev DP-Setup
*Dec  8 23:52:23.559: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in Wt-Rx-ICCN
*Dec  8 23:52:23.563: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-DP-Setup
*Dec  8 23:52:23.799: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev Rx-ICCN
*Dec  8 23:52:23.803: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Wt-Rx-ICCN->Proc-ICCN
*Dec  8 23:52:23.807: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Rx-ICCN
*Dec  8 23:52:23.807: L2TP 00001:08318:ECEDBDCE:   MTU is 65535
*Dec  8 23:52:23.811: L2TP 00001:08318:ECEDBDCE: Session data plane UP
*Dec  8 23:52:23.815: L2TP 00001:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.819: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.839: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev ICCN-OK
*Dec  8 23:52:23.843: L2TP 00001:08318:ECEDBDCE: FSM-Sn    Proc-ICCN->established
*Dec  8 23:52:23.843: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Established
*Dec  8 23:52:23.847: L2TP 00001:08318:ECEDBDCE: Session up
*Dec  8 23:52:23.851: L2TP 00001:08318:ECEDBDCE:   115.0.0.2<->116.0.0.2
*Dec  8 23:52:23.895: L2TP 00001:08318:ECEDBDCE: XCONNECT: process AVPs
*Dec  8 23:52:23.899: L2TP 00001:08318:ECEDBDCE:
*Dec  8 23:52:23.903: L2TP 00001:08318:ECEDBDCE: FSM-Sn ev DP-Up
*Dec  8 23:52:23.907: L2TP 00001:08318:ECEDBDCE: FSM-Sn    in established
*Dec  8 23:52:23.907: L2TP 00001:08318:ECEDBDCE: FSM-Sn do Ignore-DP-UP

Similar packet exchange information can be seen with debug vpdn command.

In case you need to reset L2TPv3-tunnel, the following command can be used:

R2#clear l2tun remote ip 116.0.0.2