Você está na página 1de 76

OSPF Network Types

If you are working on OSPF then you MUST know the different network types. I have been fortunate enough to be working with OSPF for sometime now so wanted to take some time and discuss all the Network types in OSPF. Broadcast:

Default on Ethernet Hello interval 10 seconds Dead Interval 40 seconds DR/BDR election Updates are sent as multicast Next hop is not changed and remains the ip address of the originating router

Non-Broadcast:

Default on Multipoint interface like Frame-relay Hello interval 30 seconds Dead Interval 120 seconds DR/BDR election Updates are sent as unicast Neighbor command required on hub router Next hop is not changed and remains the ip address of the originating router

Point to Point:

Default on HDLC, PPP and Frame-relay Point-to-Point Hello Interval 10 seconds Dead Interval 40 seconds No DR/BDR Election Multicast updates to 224.0.0.5 Next hop address is that of the advertising router

Point to Multipoint Broadcast:


Cisco proprietary Host routes are added in the routing table Hello Interval 30 seconds Dead Interval 40 seconds No DR/BDR Election Multicast updates to 224.0.0.5 Next hop address is that of the advertising router Frame-relay partial mesh

Point to Multipoint Non-Broadcast:


Cisco proprietary Hello Interval 30 seconds Dead Interval 120 seconds Frame-relay Partial Mesh No DR/BDR Election Unicast updates

By adjusting the hello/dead timers you can make non-compatible OSPF network types appear as neighbors via the show ip ospf neighbor but they wont become adjacent with each other. OSPF network types that use a DR (broadcast and non-broadcast) can neighbor with each other and function properly. Likewise OSPF network types (point-to-point and point-tomultipoint) that do not use a DR can neighbor with each other and function properly. But if you mix DR types with non-DR types they will not function properly (i.e. not fully adjacent). You should see in the OSPF database Adv Router is not-reachable messages when youve mixed DR and non-DR types. Here is what will work: Broadcast to Broadcast Non-Broadcast to Non-Broadcast Point-to-Point to Point-to-Point Point-to-Multipoint to Point-to-Multipoint Broadcast to Non-Broadcast (adjust hello/dead timers) Point-to-Point to Point-to-Multipoint (adjust hello/dead timers)

OSPF Network Types and Frame Relay Part 1


Knowing the OSPF Network Types and how they work with different frame relay topologies is one of those things that you should know inside out if you are attempting the CCIE lab. In this next series of articles we will be looking at the 5 OSPF network as well as how and when to use them in conjunction with a frame relay hub and spoke topology. We will be using the following topology for this tutorial:

Dynagen Configuration
ghostios = True sparsemem = True model = 3640 [localhost] [[3640]] image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin # On Linux / Unix use forward slashes: # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image ram = 96 [[ROUTER R1]] f0/0 = LAN 1 s1/0 = FRAME 1 console = 2000 model = 3640 [[ROUTER R2]] f0/0 = LAN 2 s1/0 = FRAME 2 console = 2001 model = 3640 [[ROUTER R3]] f0/0 = LAN 3

s1/0 = FRAME 3 console = 2002 model = 3640 [[FRSW FRAME]] 1:102 = 2:201 1:103 = 3:301

You can download the .net file for dynagen/dynamips here.

Basic Configuration
First things first lets set up our hub and spoke frame-relay topology. You can see in the diagram above R1 will be our hub, and R2 and R3 will be our spokes. R1
hostname R1 ! interface fastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip 192.168.1.3 103 broadcast no frame-relay inverse-arp

R2
hostname R2 ! interface fastEthernet0/0 ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay serial restart-delay 0 frame-relay map ip 192.168.1.1 201 broadcast frame-relay map ip 192.168.1.3 201 no frame-relay inverse-arp

R3
hostname R3 ! interface fastEthernet0/0 ip address 3.3.3.3 255.255.255.0 ! interface Serial1/0

ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 301 broadcast frame-relay map ip 192.168.1.2 301 no frame-relay inverse-arp

We have disabled frame-relay inverse arp, and made sure that R1 does not recieve redundant network broadcasts.

OSPF Over Frame Relay Non-Broadcast Network Type


The Non-Broadcast network types is used for topologies with no broadcast capability (or no broadcast capability configured!), or in topologies where you want OSPF to unicast its updates instead of broadcasting/multicasting. In the topology and configuration shown above we have configured the pseudo-broadcast capability of frame-relay. It doesnt really broadcast because not all stations in the cloud will receive that, just the ones with the broadcast statement in the frame-relay map command. Lets have a look our configuration for Non-Broadcast Frame-Relay networks: R1
hostname R1 ! interface fastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 frame-relay map ip 192.168.1.3 103 no frame-relay inverse-arp ip ospf network non-broadcast ! router ospf 1 router-id 1.1.1.1 network 0.0.0.0 255.255.255.255 area 0 neighbor 192.168.1.2 neighbor 192.168.1.3

R2
hostname R2 ! interface fastEthernet0/0 ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay serial restart-delay 0

frame-relay map ip 192.168.1.1 201 frame-relay map ip 192.168.1.3 201 no frame-relay inverse-arp ip ospf network non-broadcast ip ospf priority 0 ! router ospf 1 router-id 2.2.2.2 network 0.0.0.0 255.255.255.255 area 0

R3
hostname R3 ! interface fastEthernet0/0 ip address 3.3.3.3 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 301 frame-relay map ip 192.168.1.2 301 no frame-relay inverse-arp ip ospf network non-broadcast ip ospf priority 0 ! router ospf 1 router-id 3.3.3.3 network 0.0.0.0 255.255.255.255 area 0

You can see in the code above that we have disabled the broadcast capability of Frame-Relay by removing the broadcast statement from the frame-relay map statements. When preparing for your CCIE, its important to be able to look at the above topology and recognise when potential problems might arise. OSPF network type Non-Broadcast requires a DR. I would recognise that R1 is the hub and should be made the DR in OSPF network types that require them. OSPF Non-Broadcast is one of our only options here (the other being the Point-toMultipoint Non-Broadcast) as we have no capability to broadcast over that segment. We have made sure that the spokes (R2 & R3) are ineligible to become the DR. We can use the ip ospf priority 0 over the frame-relay topology thereby ensuring R1 will become the DR for the segment. On R1 we have specified our neighbors to unicast routing updates to using the neighbor command. Lets verify the configuration:
R1# *Mar 1 00:08:47: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0 from LOADING to FULL, Loading Done *Mar 1 00:08:47: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done R1#sh ip ospf nei

Neighbor ID 2.2.2.2 3.3.3.3

Pri 0 0

State FULL/DROTHER FULL/DROTHER

Dead Time 00:01:56 00:01:55

Address 192.168.1.2 192.168.1.3

Interface Serial1/0 Serial1/0

Looks like our neighbours have been brought up, lets check our routing table:
R2#sh 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 O C O C 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/65] via 192.168.1.1, 00:00:55, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 is directly connected, FastEthernet0/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 [110/65] via 192.168.1.3, 00:00:55, Serial1/0 192.168.1.0/24 is directly connected, Serial1/0

We have a route to R1, and R3s f0/0 networks in R2s routing table so R2 should have full reachability to those networks.
R2#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 96/153/248 ms R2#ping 3.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 144/249/376 ms

Looks like we have full reachability. Lets verify the OSPF timers and network types. We can do this with the show ip ospf interface command.
R1#sh ip ospf int Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, Interface address 192.168.1.1 No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5

oob-resync timeout 120 Hello due in 00:00:19 Supports Link-local Signaling (LLS) Index 2/2, 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 2, Adjacent neighbor count is 2 Adjacent with neighbor 2.2.2.2 Adjacent with neighbor 3.3.3.3 Suppress hello for 0 neighbor(s) FastEthernet0/0 is up, line protocol is up Internet Address 1.1.1.1/24, 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 1.1.1.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:09 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)

You can see the default timers on the Serial interface is 30 seconds for the Hello packets with a dead interval of 120 seconds. On a Fast Ethernet interface the default timers are 10 seconds and 40 seconds for hello and dead intervals respectively. In fact Cisco uses a default of Hello interval of 10 seconds for all broadcast networks and 30 seconds for non-broadcast. A dead interval is 4x this value. These values can be changed with the ip ospf hello interval command. OSPF network type non-broadcast is the default network type if you are using a physical serial interface.

OSPF Over Frame Relay Broadcast Network Type


The Broadcast Network type is the default network type on an Ethernet interface. A DR is election is performed and updates are sent via multicast packets. Frame relay will need to be configured for broadcast support to support the network type. Lets have a look at the configuration: R1
hostname R1 ! interface fastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay

frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip 192.168.1.3 103 broadcast no frame-relay inverse-arp ip ospf network broadcast ! router ospf 1 router-id 1.1.1.1 network 0.0.0.0 255.255.255.255 area 0

R2
hostname R2 ! interface fastEthernet0/0 ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 201 broadcast frame-relay map ip 192.168.1.3 201 no frame-relay inverse-arp ip ospf network broadcast ip ospf priority 0 ! router ospf 1 router-id 2.2.2.2 network 0.0.0.0 255.255.255.255 area 0

R3
hostname R3 ! interface fastEthernet0/0 ip address 3.3.3.3 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 301 broadcast frame-relay map ip 192.168.1.2 301 ip ospf priority 0 no frame-relay inverse-arp ip ospf network broadcast ! router ospf 1 router-id 3.3.3.3 network 0.0.0.0 255.255.255.255 area 0

You can see above that the frame-relay map commands have the broadcast keywords added. If we use the OSPF broadcast network type, we have to make sure that our layer two topology supports broadcasts. Lets verify the configuration:
R1#

*Mar 1 LOADING *Mar 1 LOADING

01:17: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from to FULL, Loading Done 01:17: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0 from to FULL, Loading Done

R1#sh ip ospf nei Neighbor ID 2.2.2.2 3.3.3.3 R1#sh run Pri 0 0 State FULL/DROTHER FULL/DROTHER Dead Time 00:00:34 00:00:34 Address 192.168.1.2 192.168.1.3 Interface Serial1/0 Serial1/0

If we have a look at the neighbors on R3, or R2 we should see that the only neighbour relationship formed is with the DR (R1 in this case).
R3#sh ip ospf nei Neighbor ID 1.1.1.1 Pri 1 State FULL/DR Dead Time 00:00:31 Address 192.168.1.1 Interface Serial1/0

Looks like our neighbours have been brought up, lets check our routing table:
R3#sh 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 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/65] via 192.168.1.1, 00:09:29, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets O 2.2.2.0 [110/65] via 192.168.1.2, 00:09:29, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets C 3.3.3.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Serial1/0 R3#ping 1.1.1.1 O Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 136/176/220 ms R3#ping 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 236/283/340 ms

You can see above, that even though R3 has no neighbour relationship with R2 we can still reach R2s ethernet segment. We are learning this through the Designated Router R1. R1 is acting as a co-ordination point. R2 and R3 will send their updates to R1. R1 will collate these updates and distribute them out to the spokes. Hence why R2 and R3 only need to have a neighbor relationship with the DR. Lets have a look at the timers and verify the network type:
R1#sh ip ospf int Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, Interface address 192.168.1.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:01 Supports Link-local Signaling (LLS) Index 2/2, 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 2, Adjacent neighbor count is 2 Adjacent with neighbor 2.2.2.2 Adjacent with neighbor 3.3.3.3 Suppress hello for 0 neighbor(s) FastEthernet0/0 is up, line protocol is up Internet Address 1.1.1.1/24, 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 1.1.1.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:02 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)

Notice above how the hello and dead intervals are 10 and 40 seconds respecitively for both the ethernet and serial interfaces. As mentioned above, this is because CISCO uses a default Hellp Interval for broadcast networks and 30 seconds for non-broadcast. The OSPFv2 RFC 2328 doesnt really have a required value for either Hello or Dead intervals but does suggest a hello interval of 10 seconds and a dead interval of 4X the hello interval. Thats it for broadcast and non-broadcast networks. In the next article we will be looking at point-to-multipoint and point-to-multipoint non-broadcast networks. Stay tuned. Now back to labs!

Summary:

Non-Broadcast network type is the default on a physical serial interface with ospf configured Non-Broadcast networks send unicast packets, so must be configured with neighbor statements Non-Broadcast networks have Hello and Dead intervals of 30 seconds and 120 seconds respectively Broadcast network types is the default on an ethernet interface. Broadcast network types must support broadcasting capability on a layer 2 topology Non-Broadcast and Broadcast network types require a DR. Care should be taken in DR placement (should be the Hub).

OSPF Network Types and Frame Relay Part 2


In our last article we looked at the Broadcast and Non-Broadcast OSPF network types. We will be continuing our OSPF Network Type series of articles by looking at Point-to-Multipoint and Point-to-Multipoint Non-Broadcast network types. Once again, we will be using the following topology for this tutorial:

Dynagen Configuration
ghostios = True sparsemem = True model = 3640 [localhost] [[3640]] image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin # On Linux / Unix use forward slashes: # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image ram = 96 [[ROUTER R1]] f0/0 = LAN 1 s1/0 = FRAME 1 console = 2000 model = 3640 [[ROUTER R2]] f0/0 = LAN 2 s1/0 = FRAME 2 console = 2001 model = 3640 [[ROUTER R3]] f0/0 = LAN 3 s1/0 = FRAME 3 console = 2002 model = 3640 [[FRSW FRAME]] 1:102 = 2:201 1:103 = 3:301

You can download the .net file for dynagen/dynamips here.

OSPF Over Frame Relay Point-to-Multipoint Network Type


OSPF treats Point-to-Multipoint networks as a collection of point-to-point links. A DR/BDR is not required in these networks as OSPF Packets are unicast to known neighbors. Lets have a look at the configuration: R1
hostname R1 ! interface fastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay

frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip 192.168.1.3 103 broadcast no frame-relay inverse-arp ip ospf network point-to-multipoint ! router ospf 1 router-id 1.1.1.1 network 0.0.0.0 255.255.255.255 area 0

R2
hostname R2 ! interface fastEthernet0/0 ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay serial restart-delay 0 frame-relay map ip 192.168.1.1 201 broadcast frame-relay map ip 192.168.1.3 201 no frame-relay inverse-arp ip ospf network point-to-multipoint ! router ospf 1 router-id 2.2.2.2 network 0.0.0.0 255.255.255.255 area 0

R3
hostname R3 ! interface fastEthernet0/0 ip address 3.3.3.3 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 301 broadcast frame-relay map ip 192.168.1.2 301 no frame-relay inverse-arp ip ospf network point-to-multipoint ! router ospf 1 router-id 3.3.3.3 network 0.0.0.0 255.255.255.255 area 0

You can see the configuration above is fairly straight forward. We dont need to worry about a DR as Point-to-Multipoint networks dont require one. Lets verify the configuration:
R1# *Mar 1 00:03: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done

*Mar 1 00:03: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0 from LOADING to FULL, Loading Done R1#sh ip ospf nei Neighbor ID 2.2.2.2 3.3.3.3 Pri 0 0 State FULL/ FULL/ Dead Time 00:01:39 00:01:39 Address 192.168.1.2 192.168.1.3 Interface Serial1/0 Serial1/0

You can see the output of the show ip ospf neighbors command above. We have full adjacency with R2 and R3. You can also see that there is no DR/BDR relationship between any of the routers. Lets verify the network types and timers:
Serial1/0 is up, line protocol is up Internet Address 192.168.1.3/24, Area 0 Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 oob-resync timeout 120 Hello due in 00:00:03 Supports Link-local Signaling (LLS) Index 2/2, 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 1.1.1.1 Suppress hello for 0 neighbor(s) FastEthernet0/0 is up, line protocol is up Internet Address 3.3.3.3/24, Area 0 Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 3.3.3.3, Interface address 3.3.3.3 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:04 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)

You can see above the default timers on a Point-to-Multipoint network is 30 seconds and 120 seconds for the hello and dead intervals respectively. So far this looks not very different from the other network types other than the ip ospf network type command. Lets take a look more closely at R3 and R3s routing table:
R3#sh ip ospf nei Neighbor ID Pri State Dead Time Address Interface

1.1.1.1

FULL/

00:01:42

192.168.1.1

Serial1/0

Looks like R3 has only formed a neighbor relationship with R1. Wait a minute, if R3 only forms a neighbor relationship with R1 and there is no DR relationship, does that mean that R3 has no idea about the networks from R2? The answer to this question lies in the route table of R3. Lets compare this to the route table when we used the Broadcast network type: Route Table Using Point-to-Multipoint Network Type
R3#sh 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 O O C O C O 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/65] via 192.168.1.1, 00:10:26, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/129] via 192.168.1.1, 00:10:26, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks 192.168.1.1/32 [110/64] via 192.168.1.1, 00:10:26, Serial1/0 192.168.1.0/24 is directly connected, Serial1/0 192.168.1.2/32 [110/128] via 192.168.1.1, 00:10:26, Serial1/0

Route Table Using Broadcast Network Type


R3#sh 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 O O C C 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/65] via 192.168.1.1, 00:09:29, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/65] via 192.168.1.2, 00:09:29, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is directly connected, Serial1/0

If we compare the route tables, we see that the route table for Point-to-Multipoint has three differences:
O O O 2.2.2.0 [110/129] via 192.168.1.1, 00:10:26, Serial1/0 192.168.1.1/32 [110/64] via 192.168.1.1, 00:10:26, Serial1/0 192.168.1.2/32 [110/128] via 192.168.1.1, 00:10:26, Serial1/0

The route to 2.2.2.0 network is via 192.168.1.1 instead of 192.168.1.2. We also have two /32 routes for the endpoints in the frame-relay cloud. The Point-to-Multipoint network type treats the NBMA network as a series of point-to-point links. OSPF treats it as if we are squeezing a single subnet over two point to point links. In this case all of R3s routes are via R1. The layer 3 topology is mirroring the layer 2 topology. Because Point-to-Multipoint treats the NBMA network as a series of point-to-point links, we could even get rid of the frame relay map between R3 and R2 and the routes should still be fine! Lets try it:
R3#conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)#int s1/0 R3(config-if)#no frame-relay map ip 192.168.1.2 301 R3(config-if)#end *Mar 1 01:59:25.239: %SYS-5-CONFIG_I: Configured from console by console R3#sh run int s1/0 Building configuration... Current configuration : 227 bytes ! interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint serial restart-delay 0 frame-relay map ip 192.168.1.1 301 broadcast no frame-relay inverse-arp end

The configuration above shows we no longer have a mapping to R2. Lets have a look at the effect this has. Well clear the OSPF processes and take a look at reachability afterwards:
R3#clear ip ospf pro Reset ALL OSPF processes? [no]: yes R3# *Mar 1 01:59: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Mar 1 01:59: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial1/0 from LOADING to FULL, Loading Done R3#sh 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 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/65] via 192.168.1.1, 00:00:00, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets O 2.2.2.0 [110/129] via 192.168.1.1, 00:00:00, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets C 3.3.3.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks O 192.168.1.1/32 [110/64] via 192.168.1.1, 00:00:00, Serial1/0 C 192.168.1.0/24 is directly connected, Serial1/0 O 192.168.1.2/32 [110/128] via 192.168.1.1, 00:00:00, Serial1/0 R3#ping 2.2.2.2 O Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 96/229/428 ms

This still works because the OSPF point-to-multipoint network introduced an extra hop between R3 and the ethernet network on R2. Instead of going straight to R2s 192.168.1.2 address to get to that segment we go via R1s 192.168.1.1. OSPF has inserted an extra hop via R1 to mirror that of the layer 2 topology! Cool huh?

OSPF Over Frame Relay Point-to-Multipoint Non-Broadcast Network Type


The point-to-multipoint non-broadcast network type is basically the same as the point-tomultipoint network type except it is useful in scenarios where we have no broadcast capabilities. Lets reconfigure our layer 2 topology and take away the pseudo broadcast capability of frame relay: R1
hostname R1 ! interface fastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 frame-relay map ip 192.168.1.3 103 no frame-relay inverse-arp ip ospf network point-to-multipoint non-broadcast !

router ospf 1 router-id 1.1.1.1 network 0.0.0.0 255.255.255.255 area 0 neighbor 192.168.1.2 neighbor 192.168.1.3

R2
hostname R2 ! interface fastEthernet0/0 ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay serial restart-delay 0 frame-relay map ip 192.168.1.1 201 frame-relay map ip 192.168.1.3 201 no frame-relay inverse-arp ip ospf network point-to-multipoint non-broadcast ! router ospf 1 router-id 2.2.2.2 network 0.0.0.0 255.255.255.255 area 0

R3
hostname R3 ! interface fastEthernet0/0 ip address 3.3.3.3 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 301 frame-relay map ip 192.168.1.2 301 no frame-relay inverse-arp ip ospf network point-to-multipoint non-broadcast ! router ospf 1 router-id 3.3.3.3 network 0.0.0.0 255.255.255.255 area 0

You will notice with the configuration above we have once again removed the broadcast statement from the frame-relay map statements so no broadcasts will be propogated across that network. R1 has R2 and R3 defined as its neighbors and will unicast updates to them. Lets verify the configuration:
R1# *Mar 1 02:43: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial1/0 from LOADING to FULL, Loading Done

*Mar 1 02:43: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done R1#sh ip ospf nei Neighbor ID 2.2.2.2 3.3.3.3 Pri 0 0 State FULL/ FULL/ Dead Time 00:01:31 00:01:31 Address 192.168.1.2 192.168.1.3 Interface Serial1/0 Serial1/0

Once again you can see that R1 has established adjacencies with R2 and R3. No DR/BDR relationship is established in a point-to-multipoint non-broadcast network. Lets verify the network type and timers:
R1#sh ip ospf int Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 oob-resync timeout 120 Hello due in 00:00:23 Supports Link-local Signaling (LLS) Index 2/2, 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 2.2.2.2 Adjacent with neighbor 3.3.3.3 Suppress hello for 0 neighbor(s) FastEthernet0/0 is up, line protocol is up Internet Address 1.1.1.1/24, 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 1.1.1.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:01 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)

You can see the default timers for a point-to-multipoint non-broadcast network are 30 seconds and 120 seconds for the hello and dead intervals respectively.
R3#sh 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 O O C O C O 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/65] via 192.168.1.1, 00:20:04, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/129] via 192.168.1.1, 00:20:04, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks 192.168.1.1/32 [110/64] via 192.168.1.1, 00:20:04, Serial1/0 192.168.1.0/24 is directly connected, Serial1/0 192.168.1.2/32 [110/128] via 192.168.1.1, 00:20:05, Serial1/0

Looking at the routing table on R3, we can again see that the layer 3 routing mirrors the layer 2 switching, with everything going through R1. The other thing that differentiates point-to-multipoint from point-to-multipoint non-broadcast is the ability to define the costs of routes originating from a particular neighbor. For example:
router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 neighbor 192.168.1.2 cost 100 neighbor 192.168.1.3

Here we have defined all updates coming from R2 to have a cost of 100. Lets have a look at the routing table before and after this change: Before:
R1(config-router)#do sh 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 C 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0 2.0.0.0/24 is subnetted, 1 subnets

O O C O O

2.2.2.0 [110/65] via 192.168.1.2, 00:24:07, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 [110/65] via 192.168.1.3, 00:24:07, Serial1/0 192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks 192.168.1.0/24 is directly connected, Serial1/0 192.168.1.3/32 [110/64] via 192.168.1.3, 00:24:07, Serial1/0 192.168.1.2/32 [110/64] via 192.168.1.2, 00:24:07, Serial1/0

After:
R1(config-router)#do sh 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 C O O C O O 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/101] via 192.168.1.2, 00:00:02, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 [110/65] via 192.168.1.3, 00:00:02, Serial1/0 192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks 192.168.1.0/24 is directly connected, Serial1/0 192.168.1.3/32 [110/64] via 192.168.1.3, 00:00:02, Serial1/0 192.168.1.2/32 [110/100] via 192.168.1.2, 00:00:02, Serial1/0

You can see the route cost to the networks that R2 updated were increased to 100 (directly connected 192.168.1.2), and 101 (2.2.2.0/24). This could be useful is you have a network being advertised by both R2 and R3 and you would prefer one route over the other. In the next article we will be looking at the Point-to-Point and Loopback network types. HTH. Now back to labs! Summary:

OSPF treats Point-to-Multipoint networks as a series of point-to-point links, mirroring the layer 2 topology. Point-to-Multipoint networks dont have DR/BDR relationships. Point-to-Multipoint networks advertise /32 routes for all the frame-realy endpoints. Point-to-Multipoint networks have Hello and Dead intervals of 30 seconds and 120 seconds respectively. Point-to-Multipoint non-broadcast networks are very similar to point-to-multipoint networks except that they work over layer 2 topologies that have no broadcast capability

Point-to-Multipoint non-broadcast networks allow you to define cost on a per neighbor basis.

OSPF Network Types and Frame Relay Part 3


In our previous tutorials on OSPF Network types (you can read Part 1 here, and Part 2 here), we looked at the OSPF broadcast, non-broadcast, point-to-multipoint, and point-to-multipoint nonbroadcast network types. In this article we will be taking a look at the last of the ospf network types, namely point-to-point and loopback network types. Lets start with a configuration. We will be using the following topology in this tutorial:

Dynagen .net file Configuration


ghostios = True sparsemem = True model = 3640 [localhost] [[3640]] image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin # On Linux / Unix use forward slashes: # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image ram = 96 [[ROUTER R1]] f0/0 = LAN 1 s1/0 = FRAME 1 console = 2000 model = 3640 [[ROUTER R2]] f0/0 = LAN 2 s1/0 = FRAME 2 console = 2001 model = 3640 [[FRSW FRAME]] 1:102 = 2:201

You can download this dynagen configuration file here.

Basic Configuration Lets set up our basic configuration. We will disable inverse arp and manually map the framerelay dlcis to the ends of the point-to-point link.
hostname R1 ! interface fastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 broadcast no frame-relay inverse-arp hostname R2 ! interface fastEthernet0/0 ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay serial restart-delay 0 frame-relay map ip 192.168.1.1 201 broadcast no frame-relay inverse-arp R1#sh frame map Serial1/0 (up): ip 192.168.1.2 dlci 102(0x66,0x1860), static, broadcast, CISCO, status defined, active

Looks good so far. We have a static mapping between our dlci and ip address with broadcast capability configured. Lets check communication between the two routers:
R1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 72/104/164 ms

So far so good, we have connectivity between the two routers.

OSPF Over Frame-Relay Point-to-Point Network Type


As the name suggests, the OSPF Point-to-Point network type is designed to be used on networks with a single pair of routers (for example T1, DS-3 or SONET links). In our case R1 and R2 are the only pair of routers configured over a frame relay cloud. Lets take a look at the configuration:
hostname R1 ! interface fastEthernet0/0 ip address 1.1.1.1 255.255.255.0

! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 broadcast no frame-relay inverse-arp ip ospf network point-to-point ! router ospf 1 router-id 1.1.1.1 network 0.0.0.0 255.255.255.255 area 0 hostname R2 ! interface fastEthernet0/0 ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay serial restart-delay 0 frame-relay map ip 192.168.1.1 201 broadcast no frame-relay inverse-arp ip ospf network point-to-point ! router ospf 1 router-id 2.2.2.2 network 0.0.0.0 255.255.255.255 area 0

Weve configured OSPF such that all interfaces will be placed in area 0. The default nonbroadcast network type has been changed to the point-to-point network type using the ip ospf network point-to-point command.
R1#sh ip ospf nei Neighbor ID 2.2.2.2 Pri 0 State FULL/ Dead Time 00:00:30 Address 192.168.1.2 Interface Serial1/0

You can see that R1 has become fully adjacent with R2. You will also notice with the above show ip ospf neighbor command that there is no DR on this segment. The Point-to-Point network type does not require a DR to operate. OSPF packets on this networks will always be addressed to the well known 224.0.0.5 (except retransmitted LSAs which are always unicast). Lets verify the OSPF network type and take a look at the default timers:
R1#sh ip ospf int s1/0 Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:07 Supports Link-local Signaling (LLS)

Index 2/2, 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 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 Suppress hello for 0 neighbor(s)

The default timers on a Point-to-Point link is 10 and 40 seconds for hello and dead intervals respectively . We can change this using the ip ospf hello-interval and ip ospf dead-interval commands. We will be taking a look at changing the default timers in our next article when we mix and match ospf network types.
R1#sh 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 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0 2.0.0.0/24 is subnetted, 1 subnets O 2.2.2.0 [110/65] via 192.168.1.2, 00:02:25, Serial1/0 C 192.168.1.0/24 is directly connected, Serial1/0 R1#ping 2.2.2.2 C Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 44/100/176 ms

Looks like we have full connectivity between the routers!

OSPF Over Frame-Relay Loopback Network Type


The last of the OSPF network types that we will be looking at is the Loopback network type. This is a special network type that is only seen on loopback interfaces. We cannot manually change a network to be a Loopback network type, IOS automatically assigns the network type to loopback interfaces. Lets configure a loopback interface. We dont have to worry about activating OSPF on this interface as our ospf network statement covers all interfaces.
R2#conf t Enter configuration commands, one per line. R2(config)#int lo1 End with CNTL/Z.

*Mar 1 01:13:10.671: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to up R2(config-if)#ip add 22.22.22.22 255.255.255.0 R2#sh ip ospf int Loopback1 is up, line protocol is up Internet Address 22.22.22.22/24, Area 0 Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1 Loopback interface is treated as a stub Host Serial1/0.12 is up, line protocol is up Internet Address 192.168.1.2/24, Area 0 Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_POINT, 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 2/2, 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 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 1.1.1.1 Suppress hello for 0 neighbor(s) FastEthernet0/0 is up, line protocol is up Internet Address 2.2.2.2/24, Area 0 Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 2.2.2.2, Interface address 2.2.2.2 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:00 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)

You can see the output of the show ip ospf interfaces command, the loopback interface is treated as a stub host. No advertisements are sent out that interface, but it is advertised in the OSPF routing domain. Lets check the routing table on R1 to verify this.
R1#sh 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

C O O C

1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/65] via 192.168.1.2, 00:02:24, Serial1/0.12 22.0.0.0/32 is subnetted, 1 subnets 22.22.22.22 [110/65] via 192.168.1.2, 00:02:24, Serial1/0.12 192.168.1.0/24 is directly connected, Serial1/0.12

You can see by the routing table on R1 that the loopback network type advertises a /32 route for the loopback interface into the routing domain. This is because the loopback network type represents a sing stub host, a loopback! We can change the default network type on a loopback interface just like a normal interface using the ip ospf network command. Let take a look at what happens when we change the network type to a point-to-point network type:
hostname R2 ! interface Loopback1 ip address 22.22.22.22 255.255.255.0 ip ospf network point-to-point ! interface FastEthernet0/0 ip address 2.2.2.2 255.255.255.0 duplex auto speed auto ! interface Serial1/0 no ip address encapsulation frame-relay no frame-relay inverse-arp ! interface Serial1/0.12 point-to-point ip address 192.168.1.2 255.255.255.0 frame-relay interface-dlci 201 ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0 R1#sh 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 C 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0

O O C

2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/65] via 192.168.1.2, 00:03:01, Serial1/0.12 22.0.0.0/24 is subnetted, 1 subnets 22.22.22.0 [110/65] via 192.168.1.2, 00:03:01, Serial1/0.12 192.168.1.0/24 is directly connected, Serial1/0.12

You can see that by changing the ospf network type to point-to-point we can get our loopback advertised as a /24 instead of a /32 into the ospf routing domain. In our next tutorial we will be looking at mixing and matching ospf network types and looking at some of the problems this can potentially cause. Now back to Labs. HTH! Summary:

OSPF Point-to-Point network are designed to be used when there is a single pair of routers on a network segment. Point-to-Point networks dont have DR/BDR relationships. Point-to-Point networks have Hello and Dead intervals of 10 seconds and 40 seconds respectively. OSPF Loopback Network Type is a special network type used on loopback interfaces only. Loopback Network types are treated as a stub host in the OSPF routing domain, and are advertised as a /32 route by default. We can change the network type of a loopback using the ip ospf network command. This allows us to advertise the route as something other than a /32 route.

OSPF Network Types and Frame Relay Part 4


In our previous tutorials (you can find Part 1 here, Part 2 here and Part 3 here) we looked at the different OSPF network types and how they apply to a partial mesh Frame-Relay Hub and spoke topology. In normal situations that would be enough, but this is the CCIE we are preparing for! We have to understand how the different network types work together. This is incase the proctor decides to not allow you to use certain types of OSPF networks on one interface or does not allow you to use the ip ospf network commands on others. Evil Proctors :) Once again we will be using the following topology:

We will be using the following dynagen .net file:

ghostios = True sparsemem = True model = 3640 reply [localhost] [[3640]] image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin # On Linux / Unix use forward slashes: # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image ram = 96 [[ROUTER R1]] f0/0 = LAN 1 s1/0 = FRAME 1 console = 2000 model = 3640 [[ROUTER R2]] f0/0 = LAN 2 s1/0 = FRAME 2 console = 2001 model = 3640 [[FRSW FRAME]] 1:102 = 2:201

You can download this dynagen .net configuration file for this tutorial here. Lets have a look at the initial configuration: R1
hostname R1 ! interface FastEthernet0/0 ip address 1.1.1.1 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 broadcast no frame-relay inverse-arp ! router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0

R2
hostname R2 ! interface FastEthernet0/0

ip address 2.2.2.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 201 broadcast no frame-relay inverse-arp ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 0.0.0.0 255.255.255.255 area 0

You can see with the configuration above we have set up both of the routers to be in area 0. We havent changed the default network types so the s1/0 on both routers should be set to ospf nonbroadcast network types. Lets check this:
R1#sh ip ospf int s1/0 Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State WAITING, Priority 1 No designated router on this network No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 oob-resync timeout 120 Hello due in 00:00:07 Wait time before Designated router selection 00:01:37 Supports Link-local Signaling (LLS) Index 2/2, 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 0 msec Neighbor Count is 1, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s)

This is the same on R2. What about the routing table? Well we havent had any neighbors come up, and this is because the network type is non-broadcast. With a non-broadcast network type we need to specify neighbors using the neighbor command under the ospf configuration. Instead of setting up neighbors, lets play around with this. What would happen if we set one side to Broadcast networreplyk type and the other we left as non-broadcast? Lets see:
R2#conf t Enter configuration commands, one per line. R2(config)#int s1/0 R2(config-if)#ip ospf network broadcast End with CNTL/Z.

If we take a look at our neighbors we will notice that we havent formed an adjacency between the routers.
R1#sh ip ospf nei

R1#

What is the problem here? Well at first glance your probably thinking well the network types dont match Arden!. Thats true, but matching network types is not one of the pre-requisites for forming an adjacency. What are the pre-requisites for forming an adjacency between two ospf neighbors? Pre-Requisites for OSPF adjacencies:

Same Authentication type & Password Stub Area flag Same Area Same Network Mask Same Hello & Dead Timers

Looking at that list we have the same authentication type (were not using any!), same stub area flag (ie none!), same area (Area 0), and same mask. But what about the Hello & Dead timers? Lets compare the two routers: R1
R1#sh ip ospf int s1/0 Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, Interface address 192.168.1.1 No backup designated router on this network Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 oob-resync timeout 120 Hello due in 00:00:15 Supports Link-local Signaling (LLS) Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 1 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)

R2
R2#sh ip ospf int s1/0 Serial1/0 is up, line protocol is up Internet Address 192.168.1.2/24, Area 0 Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2 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:00 Supports Link-local Signaling (LLS)

Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 1 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s)

Looking at the output from the show ip ospf interface command you can clearly see that the Hello and Dead timers dont match up. A broadcast network type has timers of 10 and 40 seconds for hello and dead timers respectively. A non-broadcast network type has timers of 30 and 120 seconds for hello and dead timers respectively. Lets change the timers on R1 and see if this helps:
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int s1/0 R1(config-if)#ip ospf hello-interval 10 R1#sh ip ospf int s1/0 Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State WAITING, Priority 1 No designated router on this network 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:04 Wait time before Designated router selection 00:01:45 Supports Link-local Signaling (LLS) Index 2/2, 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 16 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s)

We used the ip ospf hello-interval command to change the hello timers. You can see above that we didnt have to change the dead interval. By default the dead interval is set at 4x the hello interval. These timers now match R1 so we should see a neighbor adjacency form.
R1# *Mar 1 05:42:18.118: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done R1# R1#sh ip ospf nei Neighbor ID 2.2.2.2 R1# Pri 1 State FULL/DR Dead Time 00:00:31 Address 192.168.1.2 Interface Serial1/0

Looks good. You can see there that R2 has become the DR for the frame relay segment. Remember that both Broadcast network types and Non-Broadcast network types require a DR. R1s s1/0 is an ospf non-broadcast network type. In this network type hello messages are sent unicast to neighbors. We dont have neighbours defined here so we will never initiate sending hello messages. R1 will still reply to hellos however. This is how an adjacency is formed. R2s s1/0 is an ospf broadcast network type. We will multicast a hello to 224.0.0.5 on that segment. R1 is receives those hellos and unicasts a reply back. Lets verify this:
R2#debug ip ospf hello OSPF hello events debugging is on R2# OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 2.2.2.2 OSPF: Send hello to 224.0.0.5 area 0 on Serial1/0 from 192.168.1.2 R2# R1#debug ip ospf hello R1# OSPF: Rcv hello from 2.2.2.2 area 0 from Serial1/0 192.168.1.2 OSPF: End of hello processing R1# OSPF: Send hello to 192.168.1.2 area 0 on Serial1/0 from 192.168.1.1 R1#

A neighbor relationship forms now because all the pre-requisites that we mentioned before are met. R2 is elected the DR for this segment and all updates from R1 are sent to R2 via unicast to 192.168.1.2. Updates from R2 are sent to R1 via 224.0.0.5. R1 still listens on this address even though it does not send out lsa updates on this address. The key thing here is that both the ospf broadcast and non-broadcast network types use DR to handle propogation of updates through ospf. Because of this they are able to share routes. Looking at the routing tables of both you can see we have full connectivity:
R2#sh 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 O C C 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/65] via 192.168.1.1, 00:00:23, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is directly connected, Serial1/0

Looks good, but what would happen if we change R1 to a network type that didnt support a DR. Lets try it and see :)

R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int s1/0 R1(config-if)#ip ospf network point-to-multipoint R1# %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached %SYS-5-CONFIG_I: Configured from console by console R1# %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done

Looks like the adjacency worked! Why:


R1#sh ip ospf int s1/0 Serial1/0 is up, line protocol is up Internet Address 192.168.1.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64 Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:05 Supports Link-local Signaling (LLS) Index 2/2, 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 16 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 Suppress hello for 0 neighbor(s)

The point-to-multipoint network type has timers that match the broadcast network type set on R2. The adjacency pre-requisites are met so an adjacency is formed.
R1#sh ip ospf nei Neighbor ID Pri 2.2.2.2 0 R2#sh ip ospf nei Neighbor ID 1.1.1.1 Pri 1 State FULL/ Dead Time 00:00:36 Dead Time 00:00:39 Address 192.168.1.2 Address 192.168.1.1 Interface Serial1/0 Interface Serial1/0

State FULL/BDR

Looking at the show ip ospf neighbor output of both neighbors we see a problem. R1 sees R2 as a neighbour but does not think a DR relationship is necessary on the Frame Segment. R2 thinks a DR is necessary on the frame segment. Herein lies the problem:
R2#sh 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 2.0.0.0/24 is subnetted, 1 subnets C 2.2.2.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Serial1/0 R1#sh 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 C C 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is directly connected, Serial1/0

R1 and R2 are not swapping routes! Lets have a think about why this is. Even though all the pre-requisites for neighbor adjacencies have been met, R1 will be unicasting updates to R2 and R2 will be sending updates to the multicast address 224.0.0.6 (all DR and BDRs). The link-state databases will not be kept synchronized properly. The moral of the story: We can mix and match network types as long as the DR relationship is taken into account. This means we can mix and match the following network types: Dont Need a DR: Point-to-Point and Point-to-Multipoint (if you adjust timers) Point-to-Point and Point-to-Multipoint non-broadcast (if you adjust timers) Point-to-Multipoint and Point-to-Multipoint non-broadcast Need a DR: Broadcast and Non-Broadcast (if you adjust timers) In our next article in the OSPF Network Types and Frame-Relay series we will be putting all of these together and taking a look at how the OSPF network types work in conjunction with a large partial mesh network. Now back to labs! HTH! Summary:

An adjacency will be formed with routers running OSPF, as long as the authentication is the same, the stub flag is the same, the area is the same, and the timers are the same.

If we mix and match network types we might need to modify the timers so we can form an adjacency. This is done with the ip ospf hello-interval and ip ospf dead-interval commands. You can mix and match network types as long as the network types involved have the same DR relationship. You cant mix network types that require a DR with those that dont require a DR.

OSPF Network Types and Frame Relay Part 5


In my previous tutorials we looked at the different OSPF Network types (you can find Part 1 here, Part 2 here, Part 3 here, and Part 4 here) and also how they interact with each other. In this tutorial we will be looking at implementing OSPF over a partial mesh Frame-Relay network with multiple hubs and spokes. This is the last of the OSPF Network Types and Frame Relay series of articles.unless I find something cool! :) We will be implementing the following topology for this tutorial:

Dynagen / Dynamips .net Configuration File:


ghostios = true

sparsemem = true model = 3640 [localhost] [[3640]] image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin # On Linux / Unix use forward slashes: # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image ram = 128 [[ROUTER R1]] f0/0 = LAN 1 s1/0 = FRAME 1 console = 2000 model = 3640 [[ROUTER R2]] f0/0 = LAN 2 s1/0 = FRAME 2 console = 2001 model = 3640 [[ROUTER R3]] f0/0 = LAN 3 s1/0 = FRAME 3 console = 2002 model = 3640 [[ROUTER R4]] f0/0 = LAN 4 s1/0 = FRAME 4 console = 2003 model = 3640 [[FRSW FRAME]] 1:102 = 2:201 2:203 = 3:302 3:304 = 4:403

You can download the dynagen .net configuration file for this topology here. Lets have a look at the basic configuration for this topology: R1
hostname R1 ! no service timestamps debug uptime no service timestamps log uptime ! interface FastEthernet0/0 ip address 1.1.1.1 255.255.255.0 duplex auto speed auto

! interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip 192.168.1.3 102 frame-relay map ip 192.168.1.4 102 no frame-relay inverse-arp

R2
hostname R2 ! no service timestamps debug uptime no service timestamps log uptime ! interface FastEthernet0/0 ip address 2.2.2.2 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 201 broadcast frame-relay map ip 192.168.1.3 203 broadcast frame-relay map ip 192.168.1.4 203 no frame-relay inverse-arp

R3
hostname R3 ! no service timestamps debug uptime no service timestamps log uptime ! interface FastEthernet0/0 ip address 3.3.3.3 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 302 frame-relay map ip 192.168.1.2 302 broadcast frame-relay map ip 192.168.1.4 304 broadcast no frame-relay inverse-arp

R4
hostname R4 ! no service timestamps debug uptime no service timestamps log uptime

! interface FastEthernet0/0 ip address 4.4.4.4 255.255.255.0 duplex auto speed auto ! interface Serial1/0 ip address 192.168.1.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 403 frame-relay map ip 192.168.1.2 403 frame-relay map ip 192.168.1.3 403 broadcast no frame-relay inverse-arp

Lets take a close look at this configuration. You can see above we have a partial mesh configuration and it could be argued that we actually have two hubs. R2 and R3 could both be considered hubs. R2 is the hub for R1 and R3 spokes, and R3 is the hub for R2 and R4 spokes. The broadcast statements reflect this. R2 has broadcast statements in its frame-relay map for its spokes, and only its spokes. This is the same on R3, we have broadcast statements for R2 and R4 (its spokes only). This is to stop redundant broadcasts. If we apply a broadcast statement to each and every frame-relay map statement this will cause redundant broadcasts frames to be sent. For example lets say we configure R4 as follows: R4
interface Serial1/0 ip address 192.168.1.4 255.255.255.0 encapsulation frame-relay frame-relay map ip 192.168.1.1 403 broadcast frame-relay map ip 192.168.1.2 403 broadcast frame-relay map ip 192.168.1.3 403 broadcast no frame-relay inverse-arp

Notice we have applied a broadcast option to every frame-relay map statement. When a broadcast frame is sent, it will create three packets with a layer2 header (frame relay) specifying DLCI 403, and a layer3 header (IP) specifying a destination of 192.168.1.255. R3 will receive all three of these frames. R3 will look at the layer2 header of those frames and say Oh this for me at layer2! Great, lets look at the layer3 header. R3 will then de-encapsulate the layer2 header (the frame) and then take a look at the layer3 header which has a destination of 192.168.1.255. Oh its a broadcast great, thats for me as well, R3 says. Will it forward those back out the interface to the rest of the Routers? No. Think about this. When you get a broadcast packet on an ethernet network does your computer process it and then send it back out again. If it did this would result in a hell of a lot of broadcast traffic on our networks! R3 will get three packets that have the broadcast as a destination address and process them. It will not resend those broadcast packets backout again. That is what it means by redundant broadcasts.

Lets verify this: R2:


R2#debug ip packet IP packet debugging is on

R3:
R3#debug ip packet IP packet debugging is on

R4:
R4#debug ip packet IP packet debugging is on

We have turned on ip packet debugging on all routers (dont try this on a production router!). Lets generate some packets on R4:
R4#ping 192.168.1.255 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.255, timeout is 2 seconds: IP: s=192.168.1.4 (local), d=255.255.255.255 (Serial1/0), len 100, sending broad/multicast IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3 IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3 IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3 Reply to request 0 from 192.168.1.3, 80 ms Reply to request 0 from 192.168.1.3, 96 ms Reply to request 0 from 192.168.1.3, 88 ms -----Output Cut----R3# IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2 IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2 IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2 IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending

You can see clearly in the output above that R3 got 3 ping packets for every one ping that was supposed to be sent. R3 then sent 3 unicast reply back to to R4 only. Be aware of this as I see a lot of people setting broadcast statement on every frame-relay map statement. I dont know if you will loose marks on this in the CCIE Lab exam but it certainly helps to be aware of it. On your hub, set a broadcast frame-relay map on all the DLCIs leading to your spokes. On your spokes, set the broadcast frame-relay map on the DLCI leading to your hub. This has implications for OSPF. It is why we usually want to make sure that the hub is the Designated Router (DR) in OSPF. The spokes send an update via a multicast (subset of broadcast) to 224.0.0.6 which the DR listens on. This is only applicable to network types that require a DR. The updates are then collated by the DR and sent out to the other spokes via the address 224.0.0.5. They are seperate broadcasts. Lets clean up before we move on to setting up OSPF across this network. R2:
R2#un all All possible debugging has been turned off

R3:
R3#un all All possible debugging has been turned off

R4:
R4#un all All possible debugging has been turned off R4#conf t Enter configuration commands, one per line. R4(config)#default int s1/0 Building configuration...

End with CNTL/Z.

Interface Serial1/0 set to default configuration R4(config)# %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up R4(config)#int s1/0 R4(config-if)# ip address 192.168.1.4 255.255.255.0 R4(config-if)# encapsulation frame-relay R4(config-if)# frame-relay map ip 192.168.1.1 403 R4(config-if)# frame-relay map ip 192.168.1.2 403 R4(config-if)# frame-relay map ip 192.168.1.3 403 broadcast R4(config-if)# no frame-relay inverse-arp R4(config-if)#no shut R4(config-if)#end

Setting Up An OSPF Network Across A Partial-Mesh Frame-Relay Network


One of the things that you should be asking yourself looking at that topology is what OSPF network type do we use? Weve already stated that there are essentially two hubs in that topology. Both R2 and R3 could be considered hubs. Well, if there are two hubs which one do we make the DR? Can we even use a network type that requires a DR in this topology? Lets explore this first.

OSPF DR Network Types:


R1:
interface Serial1/0 ip ospf network broadcast ip ospf priority 0 ! router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 192.168.1.1 0.0.0.0 area 0

R2:
interface Serial1/0 ip ospf network broadcast ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 192.168.1.2 0.0.0.0 area 0

R3:
interface Serial1/0 ip ospf network broadcast ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 192.168.1.3 0.0.0.0 area 0

R4:
interface Serial1/0 ip ospf network broadcast ip ospf priority 0 ! router ospf 1 router-id 4.4.4.4

log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 192.168.1.4 0.0.0.0 area 0

So we have activated ospf on all the interfaces in our topology. For simplicity sake we have used a single OSPF area (area 0) for our entire topology. Lets verify that we are able to establish adjacency on our routers:
R1#sh ip ospf nei Neighbor ID Pri 2.2.2.2 1 R2#sh ip ospf nei Neighbor ID Pri 1.1.1.1 0 3.3.3.3 1 R3#sh ip ospf nei Neighbor ID Pri 2.2.2.2 1 4.4.4.4 0 R4#sh ip ospf nei Neighbor ID 3.3.3.3 Pri 1 State FULL/DR State FULL/DROTHER FULL/DR State FULL/BDR FULL/DROTHER State FULL/DR Dead Time 00:00:30 Dead Time 00:00:36 00:00:30 Dead Time 00:00:32 00:00:33 Dead Time 00:00:38 Address 192.168.1.2 Address 192.168.1.1 192.168.1.3 Address 192.168.1.2 192.168.1.4 Address 192.168.1.3 Interface Serial1/0 Interface Serial1/0 Serial1/0 Interface Serial1/0 Serial1/0 Interface Serial1/0

At first glance, that looks fine. They all came up as fully adjacent, but take a look at those DR/BDR relationships. They are not consistent at all!
R1#sh ip ospf int s1/0 | inc Designated|Backup Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2 Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2 Adjacent with neighbor 2.2.2.2 (Designated Router) R2#sh ip ospf int s1/0 | inc Designated|Backup Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3 Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2 Adjacent with neighbor 3.3.3.3 (Designated Router) R3#sh ip ospf int s1/0 | inc Designated|Backup Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3 Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2 Adjacent with neighbor 2.2.2.2 (Backup Designated Router) R4#sh ip ospf int s1/0 | inc Designated|Backup Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3 Adjacent with neighbor 3.3.3.3 (Designated Router)

R1 believes that R2 is the DR. R2, R3, and R4 believe that R3 is the DR. How will this effect the routing tables?
R2#sh ip route | b Gateway Gateway of last resort is not set 2.0.0.0/24 is subnetted, 1 subnets

2.2.2.0 is directly connected, FastEthernet0/0 3.0.0.0/24 is subnetted, 1 subnets O 3.3.3.0 [110/65] via 192.168.1.3, 00:03:40, Serial1/0 4.0.0.0/24 is subnetted, 1 subnets O 4.4.4.0 [110/65] via 192.168.1.4, 00:03:40, Serial1/0 C 192.168.1.0/24 is directly connected, Serial1/0 R3#sh ip route | b Gateway Gateway of last resort is not set 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/65] via 192.168.1.2, 00:04:07, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets C 3.3.3.0 is directly connected, FastEthernet0/0 4.0.0.0/24 is subnetted, 1 subnets O 4.4.4.0 [110/65] via 192.168.1.4, 00:04:07, Serial1/0 C 192.168.1.0/24 is directly connected, Serial1/0 R4#sh ip route | b Gateway Gateway of last resort is not set O O O C C 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/65] via 192.168.1.2, 00:04:18, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 [110/65] via 192.168.1.3, 00:04:18, Serial1/0 4.0.0.0/24 is subnetted, 1 subnets 4.4.4.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is directly connected, Serial1/0

It looks like R2, R3, and R4 can see each others Ethernet networks, but they have no visibility of R1s Ethernet segment.
R1#sh ip route | b Gateway Gateway of last resort is not set C C 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is directly connected, Serial1/0

R1 has no visibility at all of the other networks even though we are fully adjacent with R2! Lets examine this a little closer. In the above topology, R2, R3, and R4 will be able to swap routes as they have a consitent DR. Updates will be sent to the DR, these will be collated by the DR and then resent out to the spokes. But R1 thinks R2 is the DR. R1 will send its updates to what it thinks is the DR (R2). R2 will not accept these routes because it believes R3 is the DR! The biggest problem with this topology and OSPF network types that require a DR is who do we make the DR?. We usually make the hub in a hub and spoke topology the DR, but what happens when we effectively have 2 hubs? These types of topologies are simply not suited to OSPF network types that require a DR (broadcast, and non-broadcast). We cant have 2 DRs!

OSPF Non-DR Network Types:

Lets try the same thing with a Non-DR OSPF Network type. In this example we will be using the point-to-multipoint OSPF network type, although we could also use any of the other types that dont require a DR. Lets take a look at the configuration: R1:
interface Serial1/0 ip address 192.168.1.1 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.2 102 broadcast frame-relay map ip 192.168.1.3 102 frame-relay map ip 192.168.1.4 102 no frame-relay inverse-arp ! router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 192.168.1.1 0.0.0.0 area 0

R2:
interface Serial1/0 ip address 192.168.1.2 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.1 201 broadcast frame-relay map ip 192.168.1.3 203 broadcast frame-relay map ip 192.168.1.4 203 no frame-relay inverse-arp ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 192.168.1.2 0.0.0.0 area 0

R3:
interface Serial1/0 ip address 192.168.1.3 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.1 302 frame-relay map ip 192.168.1.2 302 broadcast frame-relay map ip 192.168.1.4 304 broadcast no frame-relay inverse-arp ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0

network 192.168.1.3 0.0.0.0 area 0

R4:
interface Serial1/0 ip address 192.168.1.4 255.255.255.0 encapsulation frame-relay ip ospf network point-to-multipoint frame-relay map ip 192.168.1.1 403 frame-relay map ip 192.168.1.2 403 frame-relay map ip 192.168.1.3 403 broadcast no frame-relay inverse-arp ! router ospf 1 router-id 4.4.4.4 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 192.168.1.4 0.0.0.0 area 0

Once again we have setup all our interfaces so that they are in area 0. We have used the ip ospf network point-to-multipoint command on all our routers so we have a consistent network type. This network type does not require a DR as OSPF will inject /32 route to all our end points. You can check out my previous tutorial on the point-to-multipoint OSPF network type on why this is so cool! Our two hubs, R2 and R3 have frame-relay maps with broadcast statements to their respective spokes. R2 has a broadcast statement for R1 and R3 in its frame-relay map statement. R3 has a broadcast statement for R2 and R4 in its frame-relay maps. Once again, we dont apply broadcast statements to all our traffic as we would receive redundant broadcast messages. Lets verify the routing table:
R1#sh ip route | b Gateway Gateway of last resort is not set C O O O C O O O 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 is directly connected, FastEthernet0/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/65] via 192.168.1.2, 00:15:43, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 [110/129] via 192.168.1.2, 00:15:43, Serial1/0 4.0.0.0/24 is subnetted, 1 subnets 4.4.4.0 [110/193] via 192.168.1.2, 00:15:43, Serial1/0 192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks 192.168.1.0/24 is directly connected, Serial1/0 192.168.1.3/32 [110/128] via 192.168.1.2, 00:15:43, Serial1/0 192.168.1.2/32 [110/64] via 192.168.1.2, 00:15:43, Serial1/0 192.168.1.4/32 [110/192] via 192.168.1.2, 00:15:43, Serial1/0

You can see clearly above OSPF has inserted an extra hop via R2 for R1 for all our routers in the 192.168.1.0/24 segment. OSPFs point-to-multipoint network type creates next hops to make the layer 3 topology mirror that of the layer 2 topology.

R1 looks great, lets verify R4s routing table and see if we can ping across the furthest spokes:
R4#sh ip route | b Gateway Gateway of last resort is not set O O O C O C O O 1.0.0.0/24 is subnetted, 1 subnets 1.1.1.0 [110/193] via 192.168.1.3, 00:24:11, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets 2.2.2.0 [110/129] via 192.168.1.3, 00:24:11, Serial1/0 3.0.0.0/24 is subnetted, 1 subnets 3.3.3.0 [110/65] via 192.168.1.3, 00:24:11, Serial1/0 4.0.0.0/24 is subnetted, 1 subnets 4.4.4.0 is directly connected, FastEthernet0/0 192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks 192.168.1.1/32 [110/192] via 192.168.1.3, 00:24:11, Serial1/0 192.168.1.0/24 is directly connected, Serial1/0 192.168.1.3/32 [110/64] via 192.168.1.3, 00:24:11, Serial1/0 192.168.1.2/32 [110/128] via 192.168.1.3, 00:24:11, Serial1/0

The routing table looks great! Lets check reachability:


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

Looks like we have full reachability! Awesome! So whats the moral of this story? On topologies that have one hub, make sure the hub becomes the DR by setting the ip ospf priority of the spokes to 0 (or use a network type that doesnt require a DR!). For a frame-relay topology that effectively has multiple hubs like our topology above we should use an OSPF network type that doesnt require a DR. If anybody has any other questions regarding OSPF networks and frame-relay, or has some weird topology that would make a great tutorial shoot me an email. HTH. Now get back to labs!

Summary:

For topologies where you have one hub, ensure the hub is the DR or use a network type that doesnt require a DR For topologies that have more than one hub, use a network type that doesnt require a DR In partial mesh topologies, the hubs should use a broadcast frame-relay map on DLCIs to all connected spokes. This is to stop redundant broadcasts

In partial mesh topologies, the spokes should use a broadcast frame-relay map on DLCIs to the hub only. This is to stop redundant broadcasts

Filtering Routes in OSPF Part 1 Filtering Within An Area


In addition to knowing all the different OSPF Network Types and how they relate to FrameRelay, a CCIE candidate must be familiar with the different methods of filtering routes in OSPF. This two part series of tutorials will focus on filtering routes in OSPF, both within an area and between areas. This tutorial will focus on filtering routes within an area using distribute-lists, access-lists and using a route-map. We will be using the following topology for this tutorial:

Dynagen .net Configuration File:


ghostios = True sparsemem = True model = 3640 [localhost] [[3640]] image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin # On Linux / Unix use forward slashes: # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image ram = 128 [[ROUTER R1]] model = 3640 console = 2000 e1/0 = LAN 13 e1/1 = LAN 12 autostart = False

[[ROUTER R2]] model = 3640 console = 2001 e1/0 = LAN 23 e1/1 = LAN 12 autostart = False [[ROUTER R3]] model = 3640 console = 2002 e1/0 = LAN 13 e1/1 = LAN 23 e1/2 = LAN 34 e1/3 = LAN 35 autostart = False [[ROUTER R4]] model = 3640 console = 2003 e1/0 = LAN 34 e1/1 = LAN 45 autostart = False [[ROUTER R5]] model = 3640 console = 2004 e1/0 = LAN 35 e1/1 = LAN 45 autostart = False

You can download the .net dynagen configuration file here.

Basic Configuration
First things first lets set up our basic topology. You can see in the diagram above R3 will be our Area Border Router (ABR) between Area 0 and Area 1. R1 and R2 will be backbone routers in Area 0, and R4 and R5 will be internal Area 1 routers. R1:
hostname R1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Ethernet1/0 ip address 10.0.13.1 255.255.255.0 full-duplex ! interface Ethernet1/1 ip address 10.0.12.1 255.255.255.0 full-duplex ! router ospf 1

router-id 1.1.1.1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 10.0.12.1 0.0.0.0 area 0 network 10.0.13.1 0.0.0.0 area 0

R2:
hostname R2 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Ethernet1/0 ip address 10.0.23.2 255.255.255.0 full-duplex ! interface Ethernet1/1 ip address 10.0.12.2 255.255.255.0 full-duplex ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 10.0.12.2 0.0.0.0 area 0 network 10.0.23.2 0.0.0.0 area 0

R3:
hostname R3 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Ethernet1/0 ip address 10.0.13.3 255.255.255.0 full-duplex ! interface Ethernet1/1 ip address 10.0.23.3 255.255.255.0 full-duplex ! interface Ethernet1/2 ip address 10.1.34.3 255.255.255.0 full-duplex ! interface Ethernet1/3 ip address 10.1.35.3 255.255.255.0 full-duplex ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0

network network network network

10.0.13.3 10.0.23.3 10.1.34.3 10.1.35.3

0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0

area area area area

0 0 1 1

R4:
hostname R4 ! interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface Ethernet1/0 ip address 10.1.34.4 255.255.255.0 full-duplex ! interface Ethernet1/1 ip address 10.1.45.4 255.255.255.0 full-duplex ! router ospf 1 router-id 4.4.4.4 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 1 network 10.1.34.4 0.0.0.0 area 1 network 10.1.45.4 0.0.0.0 area 1

R5:
hostname R5 ! interface Loopback0 ip address 5.5.5.5 255.255.255.255 ! interface Ethernet1/0 ip address 10.1.35.5 255.255.255.0 full-duplex ! interface Ethernet1/1 ip address 10.1.45.5 255.255.255.0 full-duplex ! router ospf 1 router-id 5.5.5.5 log-adjacency-changes network 5.5.5.5 0.0.0.0 area 1 network 10.1.35.5 0.0.0.0 area 1 network 10.1.45.5 0.0.0.0 area 1

You can see above, we have also added a loopback interface on each device and advertised them into OSPF. R1, R2, and R3s Loopback0 interfaces have been added to Area 0. R4 and R5s Loopback0 interfaces have been added to Area 1. Lets verify the routing table on R5 and test connectivity before we start filtering routes.

R5#sh ip route | b Gateway Gateway of last resort is not set O IA O IA O IA O C O IA O IA O IA C C O 1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/21] via 10.1.35.3, 00:47:50, Ethernet1/0 2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/21] via 10.1.35.3, 00:47:50, Ethernet1/0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/11] via 10.1.35.3, 00:47:50, Ethernet1/0 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 [110/11] via 10.1.45.4, 00:47:50, Ethernet1/1 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 6 subnets 10.0.12.0 [110/30] via 10.1.35.3, 00:47:50, Ethernet1/0 10.0.13.0 [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0 10.0.23.0 [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0 10.1.45.0 is directly connected, Ethernet1/1 10.1.35.0 is directly connected, Ethernet1/0 10.1.34.0 [110/20] via 10.1.45.4, 00:47:50, Ethernet1/1 [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0

The routing table looks correct. We have inter-area routes to R1, R2, and R3s loopback0 addresses as well as to the 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks.
R5#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 216/245/284 ms

Looks like we have full connectivity. Now time to filter some routes!

Filtering Routes Within An Area


OSPF is a link-state routing protocol. Routers running OSPF within an area swap state information and populate a topology database. Each router then independently calculates the best paths based on the information contained in their topology database. All routers within an area must have the same topology information so that they can accurately make routing decisions. Lets take a look at the current OSPF topology database on R5:
R5#sh ip ospf database OSPF Router with ID (5.5.5.5) (Process ID 1) Router Link States (Area 1) Link ID 3.3.3.3 4.4.4.4 5.5.5.5 ADV Router 3.3.3.3 4.4.4.4 5.5.5.5 Age 473 473 454 Seq# 0x80000004 0x80000005 0x80000005 Checksum 0x00EC42 0x006887 0x000BD3 Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.34.4 10.1.35.5 10.1.45.5 ADV Router 4.4.4.4 5.5.5.5 5.5.5.5 Age 473 454 454 Seq# 0x80000003 0x80000003 0x80000003 Checksum 0x0014C6 0x0003CD 0x00C6FB

Summary Net Link States (Area 1) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 10.0.12.0 10.0.13.0 10.0.23.0 ADV Router 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 Age 473 473 473 473 474 474 Seq# 0x80000003 0x80000003 0x80000003 0x80000003 0x80000003 0x80000003 Checksum 0x006BB4 0x003DDE 0x00AA77 0x00EC18 0x007D90 0x000FF4

We will be filtering routes on R5 so it will be interesting to see the effect that this will have on the topology database. If we lose any of the database entries, we will have an inconsistent database in our area with some routers missing pieces of the the topology database. An inconsistent topology database might cause the Dijkstras shortest-path-first algorithm that OSPF uses to calculate paths that contain routing loops or routing black holes. Herein lies the challenge. If we filter routes on a particular router, does that mean that some routers in an area will have a different topology database than the others in the same area? How will this affect the routing process? It is these questions that I want you to keep in mind when we go through our examples.

Filtering within an area Using distribute-list


The first tool we will be using to filter routes is a distribute-list. We will first use a distribute list to filter all routes except R3s loopback address (3.3.3.3) from R5s routing table. Lets take a look at the configuration: R5:
router ospf 1 distribute-list 1 in ! access-list 1 permit 3.3.3.3

You can see we have created an inbound distribute-list on the OSPF process on R5. We have used an access-list to define that we only want to permit the 3.3.3.3 address (dont forget there is an implicit deny at the end of that access list). Lets verify this:
R5#sh ip route | b Gateway Gateway of last resort is not set

O IA C C C

3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/11] via 10.1.35.3, 00:00:14, Ethernet1/0 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 2 subnets 10.1.45.0 is directly connected, Ethernet1/1 10.1.35.0 is directly connected, Ethernet1/0

Looks like our distribute-list worked as anticipated. The only non-connected route that we can see is the 3.3.3.3/32 network (ie R3s loopback0). Lets check out the OSPF topology database:
R5#sh ip ospf data OSPF Router with ID (5.5.5.5) (Process ID 1) Router Link States (Area 1) Link ID 3.3.3.3 4.4.4.4 5.5.5.5 ADV Router 3.3.3.3 4.4.4.4 5.5.5.5 Age 1476 1415 1362 Seq# 0x80000005 0x80000006 0x80000006 Checksum 0x00D659 0x006688 0x00DC03 Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.34.4 10.1.35.3 10.1.45.5 ADV Router 4.4.4.4 3.3.3.3 5.5.5.5 Age 1415 1476 1362 Seq# 0x80000002 0x80000002 0x80000002 Checksum 0x0016C5 0x007566 0x00C8FA

Summary Net Link States (Area 1) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 10.0.12.0 10.0.13.0 10.0.23.0 ADV Router 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 Age 1476 1476 1476 1476 1478 1478 Seq# 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 Checksum 0x006DB3 0x003FDD 0x00AC76 0x00EE17 0x007F8F 0x0011F3

Whoa! We have NO change to the OSPF topology database! At first glance this might seem counter-intuitive but this is exactly what we want to happen. Remember OSPF is a link-state routing protocol where each router then calculates the best paths based on the information contained in their topology database. All routers within an area must have the same topology information so that they can accurately make routing decisions. If they dont have the same topology database on the routers within an area we risk routing loops or routing black holes in that area.

So the distribute-list command doesnt affect routes as they enter or leave the OSPF topology database. The distribute-list command affects routes as they go in and out of the routing table. It does not prevent link state packets from being propagated. This is very important to remember. When Dijkstras shortest-path-first algorithm calculates the best path in OSPF it needs to have a complete view of the topology in an area. If it does not, it cannot calculate best paths that are guaranteed to be loop free. This configuration could still result in a routing black hole if R4 decides to send packets for any other address (other than R3s Loopback0) via R5. Lets check this: R4:
R4#sh ip ospf data OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 1) Link ID 3.3.3.3 4.4.4.4 5.5.5.5 ADV Router 3.3.3.3 4.4.4.4 5.5.5.5 Age 41 45 44 Seq# 0x80000003 0x80000003 0x80000003 Checksum 0x00EE41 0x006C85 0x000FD1 Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.34.4 10.1.35.5 10.1.45.5 ADV Router 4.4.4.4 5.5.5.5 5.5.5.5 Age 45 43 54 Seq# 0x80000001 0x80000001 0x80000001 Checksum 0x0018C4 0x0007CB 0x00CAF9

Summary Net Link States (Area 1) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 10.0.12.0 10.0.13.0 10.0.23.0 ADV Router 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 Age 32 42 82 42 83 83 Seq# 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 0x80000001 Checksum 0x006FB2 0x0041DC 0x00AE75 0x00F016 0x00818E 0x0013F2

You can see R4s topology database above. It has the same entries as R5s. This is needed by OSPF to make accurate routing decisions.
R4#sh ip route | b Gateway Gateway of last resort is not set O IA 1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/21] via 10.1.34.3, 00:00:02, Ethernet1/0 2.0.0.0/32 is subnetted, 1 subnets

O IA

2.2.2.2 [110/21] via 10.1.34.3, 00:00:02, Ethernet1/0 3.0.0.0/32 is subnetted, 1 subnets O IA 3.3.3.3 [110/11] via 10.1.34.3, 00:00:02, Ethernet1/0 4.0.0.0/32 is subnetted, 1 subnets C 4.4.4.4 is directly connected, Loopback0 5.0.0.0/32 is subnetted, 1 subnets O 5.5.5.5 [110/11] via 10.1.45.5, 00:00:02, Ethernet1/1 10.0.0.0/24 is subnetted, 6 subnets O IA 10.0.12.0 [110/30] via 10.1.34.3, 00:00:02, Ethernet1/0 O IA 10.0.13.0 [110/20] via 10.1.34.3, 00:00:02, Ethernet1/0 O IA 10.0.23.0 [110/20] via 10.1.34.3, 00:00:03, Ethernet1/0 C 10.1.45.0 is directly connected, Ethernet1/1 O 10.1.35.0 [110/20] via 10.1.45.5, 00:00:03, Ethernet1/1 [110/20] via 10.1.34.3, 00:00:03, Ethernet1/0 C 10.1.34.0 is directly connected, Ethernet1/0 R4#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/52 ms

At the moment R4 is routing everything correctly to R3. Lets take a look what happens when we shut down R4s e1/0 interface:
R4#conf t Enter configuration commands, one per line. R4(config)#int e1/0 R4(config-if)#shut R4(config-if)#end R4#sh ip route | b Gateway Gateway of last resort is not set O IA O IA O IA C O O IA O IA O IA C O End with CNTL/Z.

1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/31] via 10.1.45.5, 00:00:03, Ethernet1/1 2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/31] via 10.1.45.5, 00:00:03, Ethernet1/1 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/21] via 10.1.45.5, 00:00:03, Ethernet1/1 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 is directly connected, Loopback0 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 [110/11] via 10.1.45.5, 00:00:03, Ethernet1/1 10.0.0.0/24 is subnetted, 5 subnets 10.0.12.0 [110/40] via 10.1.45.5, 00:00:03, Ethernet1/1 10.0.13.0 [110/30] via 10.1.45.5, 00:00:03, Ethernet1/1 10.0.23.0 [110/30] via 10.1.45.5, 00:00:04, Ethernet1/1 10.1.45.0 is directly connected, Ethernet1/1 10.1.35.0 [110/20] via 10.1.45.5, 00:00:04, Ethernet1/1

Take a look at the routing table above. R4s OSPF has noticed a topology change and Dijkstras shortest-path algorithm has recalculated that the new best path is via R5. Because we still have the same topology database as R5, R4 assumes that this is a valid decision. It doesnt realise that we are filtering all routes except for 3.3.3.3 on R5.

R4#ping 3.3.3.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/35/72 ms R4#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)

This results in a routing black hole, which is exactly what we would expect. The distribute-list command doesnt affect the topology database, only the routing table. Lets reset the configuration on R4 and R5 before we proceed: R4:
R4#conf t Enter configuration commands, one per line. R4(config)#int e1/0 R4(config-if)#no shut R4(config-if)#end End with CNTL/Z.

R5:
R5#conf t Enter configuration commands, one per line. R5(config)#no access-list 1 R5(config)#router ospf 1 R5(config-router)#no distribute-list 1 in R5(config-router)#end End with CNTL/Z.

Filtering within an area Using a distribute-list with a route-map


We can combine the distribute list command with a route-map to give us more flexibility in matching routing table entries. With a route-map on our distribute-list we can use the following options:

match interface match ip address match ip next-hop match ip route-source match metric match route-type match tag

Lets use the match ip address in conjunction with a prefix-list so we can be more flexible with what gets permitted into our routing table. Lets verify the current routing table before we proceed:
R5#sh ip route | b Gateway Gateway of last resort is not set O IA O IA O IA O C O IA O IA O IA C C O 1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/21] via 10.1.35.3, 00:00:07, Ethernet1/0 2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/21] via 10.1.35.3, 00:00:07, Ethernet1/0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/11] via 10.1.35.3, 00:00:07, Ethernet1/0 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 [110/11] via 10.1.45.4, 00:00:07, Ethernet1/1 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 6 subnets 10.0.12.0 [110/30] via 10.1.35.3, 00:00:07, Ethernet1/0 10.0.13.0 [110/20] via 10.1.35.3, 00:00:07, Ethernet1/0 10.0.23.0 [110/20] via 10.1.35.3, 00:00:08, Ethernet1/0 10.1.45.0 is directly connected, Ethernet1/1 10.1.35.0 is directly connected, Ethernet1/0 10.1.34.0 [110/20] via 10.1.45.4, 00:00:08, Ethernet1/1 [110/20] via 10.1.35.3, 00:00:08, Ethernet1/0

You can see in the routing table above we have complete connectivity in our little network. We will use a distribute-list, this time with a route-map to deny all the 10.0.0.0/16 networks (ie. 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks). R5:
router ospf 1 distribute-list route-map NO_AREA0 in ! ip prefix-list AREA0 seq 5 deny 10.0.0.0/16 le 32 ip prefix-list AREA0 seq 10 permit 0.0.0.0/0 le 32 ! route-map NO_AREA0 permit 10 match ip address prefix-list AREA0

The distribute-list above uses a route-map to deny any networks in the 10.0.0.0/16 supernet. This will cover the 10.0.12.0, 10.0.13.0/24 and 10.0.23.0/24 networks that we want to filter. Everything else will be allowed into our routing table. Lets verify this:
R5#sh ip route | b Gateway Gateway of last resort is not set 1.0.0.0/32 1.1.1.1 2.0.0.0/32 O IA 2.2.2.2 O IA is subnetted, 1 subnets [110/21] via 10.1.35.3, 00:00:02, Ethernet1/0 is subnetted, 1 subnets [110/21] via 10.1.35.3, 00:00:02, Ethernet1/0

O IA O C C C O

3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/11] via 10.1.35.3, 00:00:02, Ethernet1/0 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 [110/11] via 10.1.45.4, 00:00:02, Ethernet1/1 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 3 subnets 10.1.45.0 is directly connected, Ethernet1/1 10.1.35.0 is directly connected, Ethernet1/0 10.1.34.0 [110/20] via 10.1.45.4, 00:00:03, Ethernet1/1 [110/20] via 10.1.35.3, 00:00:03, Ethernet1/0

The distribute list should not effect the topology database as it only filters routes coming into the route table.
R5#sh ip ospf data OSPF Router with ID (5.5.5.5) (Process ID 1) Router Link States (Area 1) Link ID 3.3.3.3 4.4.4.4 5.5.5.5 ADV Router 3.3.3.3 4.4.4.4 5.5.5.5 Age 1791 1794 1780 Seq# 0x8000000D 0x8000000E 0x8000000B Checksum 0x00C462 0x0040A7 0x00FED9 Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.34.3 10.1.35.5 10.1.45.5 ADV Router 3.3.3.3 5.5.5.5 5.5.5.5 Age 1791 1780 1780 Seq# 0x80000009 0x80000009 0x80000009 Checksum 0x004099 0x00F6D3 0x00BA02

Summary Net Link States (Area 1) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 10.0.12.0 10.0.13.0 10.0.23.0 ADV Router 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 Age 1791 1791 1791 1791 1792 1792 Seq# 0x80000009 0x80000009 0x80000009 0x80000009 0x80000009 0x80000009 Checksum 0x005FBA 0x0031E4 0x009E7D 0x00E01E 0x007196 0x0003FA

Awesome! It worked as anticipated. We still have a complete topology database, however we have successfully filtered the 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks from the route table. Lets reset the configuration on R5 before we proceed:
R5#conf t Enter configuration commands, one per line. R5(config)#no route-map NO_AREA0 permit 10 R5(config)#no ip prefix-list AREA0 R5(config)#router ospf 1 End with CNTL/Z.

R5(config-router)#no distribute-list route-map NO_AREA0 in R5(config-router)#end

Using Administrative Distance


We can also filter routes within an OSPF area by changing the the administrative distance of routes to 255 (an invalid route). We can use the distance command to do this. Lets take a look at an example. R5:
router ospf 1 distance 255 0.0.0.0 255.255.255.255 1 ! access-list 1 permit 3.3.3.3

The example above shows the use of the distance command to filter routes in an OSPF area. The command states that any routes from any router that matches the access-list 1 (ie. the 3.3.3.3/32 network) will be given a administrative distance of 255 (invalid). The result of this is that the 3.3.3.3/32 network will be filtered from entering the routing table. Lets verify this:

R5#clear ip route * R5#sh ip route | b Gateway Gateway of last resort is not set O IA O IA O C O IA O IA O IA C C O 1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/21] via 10.1.35.3, 00:00:01, Ethernet1/0 2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/21] via 10.1.35.3, 00:00:01, Ethernet1/0 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 [110/11] via 10.1.45.4, 00:00:01, Ethernet1/1 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 10.0.0.0/24 is subnetted, 6 subnets 10.0.12.0 [110/30] via 10.1.35.3, 00:00:01, Ethernet1/0 10.0.13.0 [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0 10.0.23.0 [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0 10.1.45.0 is directly connected, Ethernet1/1 10.1.35.0 is directly connected, Ethernet1/0 10.1.34.0 [110/20] via 10.1.45.4, 00:00:01, Ethernet1/1 [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0

Looks great! We have routes for everything except for the 3.3.3.3/32 network. This should have not affected the topology database. Lets verify this:
R5#sh ip ospf data OSPF Router with ID (5.5.5.5) (Process ID 1)

Router Link States (Area 1) Link ID 3.3.3.3 4.4.4.4 5.5.5.5 ADV Router 3.3.3.3 4.4.4.4 5.5.5.5 Age 964 978 985 Seq# 0x8000000E 0x8000000F 0x8000000C Checksum 0x00C263 0x003EA8 0x00FCDA Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.34.3 10.1.35.5 10.1.45.5 ADV Router 3.3.3.3 5.5.5.5 5.5.5.5 Age 964 985 985 Seq# 0x8000000A 0x8000000A 0x8000000A Checksum 0x003E9A 0x00F4D4 0x00B803

Summary Net Link States (Area 1) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 10.0.12.0 10.0.13.0 10.0.23.0 ADV Router 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 Age 964 964 964 964 965 965 Seq# 0x8000000A 0x8000000A 0x8000000A 0x8000000A 0x8000000A 0x8000000A Checksum 0x005DBB 0x002FE5 0x009C7E 0x00DE1F 0x006F97 0x0001FB

Nice! It worked as anticipated. We successfully filtered the route from entering the routing table but not the topology database. When you perform route filtering within an OSPF area with the distribute-list and distance commands you are filtering routes as they enter the route-table, not the topology database. The topology database must be consistent within an area for the Dijkstras shortest path first algorithm to work correctly. It does not affect LSA propagation. Thats it for filtering with an OSPF area. In the next article we will be looking at filtering between areas. Stay tuned. Now back to labs!

Summary:

You can use a distribute-list or distance command to filter routes within an area. The distribute-list and distance commands filter routes as they enter the routing-table not the topology database. The distribute-list and distance commands do not affect link state packet progagation

Filtering Routes in OSPF Part 2 Filtering Between Areas Using area filter-list
In our last article on Filtering Routes in OSPF we looked at filtering routes within an OSPF area. In this article we will be filtering routes between areas using the area filter-list command. OSPF route filtering is an important concept to be familiar with for any CCIE candidate. We will be looking at the area filter-list command first. Part 3 will then look at some of the more obtuse ways of filtering using the area range and summary-address commands. Part of being a CCIE is knowing multiple ways of configuring the same taskjust in case those evil proctors decide to restrict which of those methods you can and cant do! :) We will be using the following topology for this tutorial:

Dynagen .net Configuration File:


ghostios = True sparsemem = True model = 3640 [localhost] [[3640]] image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin # On Linux / Unix use forward slashes: # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image ram = 128 [[ROUTER R1]] console = 2000 e1/0 = LAN 13 e1/1 = LAN 12 autostart = False model = 3640 [[ROUTER R2]]

console = 2001 e1/0 = LAN 23 e1/1 = LAN 12 autostart = False model = 3640 [[ROUTER R3]] console = 2002 e1/0 = LAN 13 e1/1 = LAN 23 e1/2 = LAN 34 autostart = False model = 3640 [[ROUTER R4]] console = 2003 e1/0 = LAN 45 e1/1 = LAN 46 e1/2 = LAN 34 autostart = False model = 3640 [[ROUTER R5]] console = 2004 e1/0 = LAN 45 e1/1 = LAN 56 autostart = False model = 3640 [[ROUTER R6]] console = 2005 e1/0 = LAN 46 e1/1 = LAN 56 autostart = False model = 3640

You can download the pre-configured .net dynagen configuration file for this tutorial here.

Basic Configuration
First things first lets set up our basic topology. In this topology R1 and R2 will be internal area 2 routers with R3 the Area Border Router (ABR) between area 2 and area 0. R5 and R6 will be internal area 1 routers with R4 the ABR between area 1 and area 0. Lets take at this configuration: R1:
hostname R1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Ethernet1/0

ip address 10.2.13.1 255.255.255.0 ! interface Ethernet1/1 ip address 10.2.12.1 255.255.255.0 ! router ospf 1 router-id 1.1.1.1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 2 network 10.2.12.1 0.0.0.0 area 2 network 10.2.13.1 0.0.0.0 area 2

R2:
hostname R2 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface Ethernet1/0 ip address 10.2.23.2 255.255.255.0 ! interface Ethernet1/1 ip address 10.2.12.2 255.255.255.0 ! router ospf 1 router-id 2.2.2.2 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 2 network 10.2.12.2 0.0.0.0 area 2 network 10.2.23.2 0.0.0.0 area 2

R3:
hostname R3 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Ethernet1/0 ip address 10.2.13.3 255.255.255.0 ! interface Ethernet1/1 ip address 10.2.23.3 255.255.255.0 ! interface Ethernet1/2 ip address 10.0.34.3 255.255.255.0 ! router ospf 1 router-id 3.3.3.3 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 10.0.34.3 0.0.0.0 area 0 network 10.2.13.3 0.0.0.0 area 2 network 10.2.23.3 0.0.0.0 area 2

R4:
hostname R4 ! interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface Ethernet1/0 ip address 10.1.45.4 255.255.255.0 ! interface Ethernet1/1 ip address 10.1.46.4 255.255.255.0 ! interface Ethernet1/2 ip address 10.0.34.4 255.255.255.0 ! router ospf 1 router-id 4.4.4.4 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 10.0.34.4 0.0.0.0 area 0 network 10.1.45.4 0.0.0.0 area 1 network 10.1.46.4 0.0.0.0 area 1

R5:
hostname R5 ! interface Loopback0 ip address 5.5.5.5 255.255.255.255 ! interface Ethernet1/0 ip address 10.1.45.5 255.255.255.0 ! interface Ethernet1/1 ip address 10.1.56.5 255.255.255.0 ! router ospf 1 router-id 5.5.5.5 log-adjacency-changes network 5.5.5.5 0.0.0.0 area 1 network 10.1.45.5 0.0.0.0 area 1 network 10.1.56.5 0.0.0.0 area 1

R6:
hostname R6 ! interface Loopback0 ip address 6.6.6.6 255.255.255.255 ! interface Ethernet1/0 ip address 10.1.46.6 255.255.255.0 ! interface Ethernet1/1

ip address 10.1.56.6 255.255.255.0 ! router ospf 1 router-id 6.6.6.6 log-adjacency-changes network 6.6.6.6 0.0.0.0 area 1 network 10.1.46.6 0.0.0.0 area 1 network 10.1.56.6 0.0.0.0 area 1

We have added a loopback interface on each device and advertised them into OSPF. R1 and R2s Loopback0 interfaces have been added to area 2. R3 and R4s Loopback0 interfaces have been added to Area 0. R5 and R6s Loopback0 interfaces have been added to Area 1. Lets verify the routing table on R5 and test connectivity before we start filtering routes.
R5#sh ip route | b Gateway Gateway of last resort is not set O IA O IA O IA O IA C O O IA O IA O IA O C O IA C 1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/31] via 10.1.45.4, 00:05:51, Ethernet1/0 2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/31] via 10.1.45.4, 00:05:51, Ethernet1/0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/21] via 10.1.45.4, 00:05:51, Ethernet1/0 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 [110/11] via 10.1.45.4, 00:05:51, Ethernet1/0 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 6.0.0.0/32 is subnetted, 1 subnets 6.6.6.6 [110/11] via 10.1.56.6, 00:05:51, Ethernet1/1 10.0.0.0/24 is subnetted, 7 subnets 10.2.12.0 [110/40] via 10.1.45.4, 00:05:51, Ethernet1/0 10.2.13.0 [110/30] via 10.1.45.4, 00:05:51, Ethernet1/0 10.2.23.0 [110/30] via 10.1.45.4, 00:05:51, Ethernet1/0 10.1.46.0 [110/20] via 10.1.56.6, 00:05:51, Ethernet1/1 [110/20] via 10.1.45.4, 00:05:51, Ethernet1/0 10.1.45.0 is directly connected, Ethernet1/0 10.0.34.0 [110/20] via 10.1.45.4, 00:05:51, Ethernet1/0 10.1.56.0 is directly connected, Ethernet1/1

The routing table looks correct. We have inter-area routes to R1, R2, R3 and R4s loopback0 addresses as well as to the 10.2.12.0/24, 10.2.13.0/24, 10.2.23.0/24 and 10.0.34.0/24 networks. Exactly what we would expect. Lets verify connectivity:
R5#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 216/245/284 ms

Looks like we have full connectivity. Awesome!

OSPF Distance Vector or Link State?


Remember back to when you were studying for your CCNA. If you took a course, the instructor probably blabbed on about the difference between Link State and Distance Vector routing protocols (I know I spend a large amount of time on this when I am teaching it!). In a nutshell, with Distance Vector routing protocols the routers cannot see past their neighbors. They rely on their neighbors to tell them everything. In turn they tell their neighbors everything they have learned so far. With Link State routing protocols, the routers tell everyone (via a multicast exchange) information about itself, its links, and its neighbors (This is a massive simplification, but it will do for now). Link State Routers take this information and create a link state database. This database is identical for all routers. Based on this information each router use the Dijikstras shortest path algorithm to independantly calculate the shortest path. Now if we had a large number of routers, this would make the size of that database massive. In the old days this was a problem because memory and cpu power was limited. So we break up that database into areas. This allows OSPF to scale to larger networks. The routers in an area maintain a linkstate database for their area. This database should be identical for all other routers in the same area. So there is a database for each area. Each area is connected to another area via an ABR (Area Border Router). The ABR will have databases for two or more areas. This is where things get funky. The routers within an area inherently know how to get to other routers within the same area. The topology database will tell them. But how do they get to routers in another area. They cannot see past their own area. They rely on the ABR to tell them about routes to other areas. Hang on a sec doesnt that sound a bit like Distance Vector? In Distance Vector routing protocols, routers cannot see past their neighbors. They rely on there neighbors to tell them everything. This is the same as routers in different areas in OSPF. Internal area routers cannot see past their areas! They rely on the ABR to tell them everything about other areas. OSPF is a link state protocol within an area. OSPF can be considered a distance vector protocol between areas. Think about this. Because we are relying on the ABR to tell our internal routers everything outside the area, we must ensure a loop free topology between areas. Hence the reason why all areas must attach to Area 0. By forcing all areas to touch Area 0 in a kind of floral petal arrangement, where area 0 is the center of the flower and the other areas are the petals, we can ensure that no loops will be formed between areas! An ABR will summarize routes from other areas and create an LSA (Link State Advertisements) type 3 before sending it into the area.

You can see in the diagram above R3 will create a type 3 summary LSAs for the networks in Area 1 and Area 0 and send it into area 2. R3 will also create a type 3 summary LSA for the the networks in area 2 and send it out of area 2. The direction there is important because it will come into play later when we filter these routes. We can verify this on R1 by taking a look at the database:
R1#sh ip ospf database OSPF Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 2) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 ADV Router 1.1.1.1 2.2.2.2 3.3.3.3 Age 444 435 401 Seq# 0x80000004 0x80000004 0x80000003 Checksum 0x0094F2 0x00CF95 0x00323F Link count 3 3 2

Net Link States (Area 2) Link ID 10.2.12.2 10.2.13.3 10.2.23.3 ADV Router 2.2.2.2 3.3.3.3 3.3.3.3 Age 435 401 401 Seq# 0x80000002 0x80000002 0x80000002 Checksum 0x00A466 0x00936D 0x00579B

Summary Net Link States (Area 2) Link ID 3.3.3.3 4.4.4.4 5.5.5.5 6.6.6.6 10.0.34.0 10.1.45.0 10.1.46.0 10.1.56.0 ADV Router 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 3.3.3.3 Age 401 401 401 401 402 402 402 402 Seq# 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 Checksum 0x00AC76 0x00E232 0x0019ED 0x00EA18 0x009762 0x00766D 0x006B77 0x00616D

You can above that we have Router Link States (LSA Type 1) and Net Link States (LSA Type 2) in our database on R1. This describes the routers and networks in our area 2. R3 will take these routes and generate a LSA Type 3 and send it out into area 0. We can also see the Summary Net Link States (LSA Type 3). These have been generated by R3 and sent into area 2. Enough theory, lets get into filtering some routes!

Recap: Filtering Routes Within An Area


In our previous tutorial, we looked at filtering routes within an OSPF area. We noted that when you use filtering tools within an area, you are only filtering from the routes entering the route table. You are not filtering the OSPF database. The database must be consistent within an area for OSPF to work correctly. This results in a discrepancy between the route table and OSPF database when filtering within an area. An ABR will summarise routes as an LSA type 3 before sending it into the area. It is on the ABR that we will perform filtering between areas. How does filtering between areas affect the route tables and OSPF database? Lets find out!

Filtering Routes Between Areas Using and area filter-list


The first technique we are going to use to filter routes between areas is using the area filter-list command. Before we start lets take a look at the OSPF database on R5. R5:
R5#sh ip ospf database OSPF Router with ID (5.5.5.5) (Process ID 1) Router Link States (Area 1) Link ID 4.4.4.4 5.5.5.5 6.6.6.6 ADV Router 4.4.4.4 5.5.5.5 6.6.6.6 Age 799 792 810 Seq# 0x80000004 0x80000004 0x80000004 Checksum 0x00D71F 0x00D7DC 0x007A29 Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.45.5 10.1.46.6 10.1.56.6 ADV Router 5.5.5.5 6.6.6.6 6.6.6.6 Age 792 810 810 Seq# 0x80000002 0x80000002 0x80000002 Checksum 0x00C8FA 0x00B702 0x007B30

Summary Net Link States (Area 1) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 ADV Router 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 Age 799 799 799 799 Seq# 0x80000002 0x80000002 0x80000002 0x80000002 Checksum 0x00B35F 0x008589 0x00F222 0x0060BA

10.0.34.0 10.2.12.0 10.2.13.0 10.2.23.0

4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4

800 800 800 800

0x80000002 0x80000002 0x80000002 0x80000002

0x00797C 0x001DD8 0x00AD51 0x003FB5

You can see above that R5 has Router Link States (LSA Type 1) and Net Link States (LSA Type 2) that describe the networks and routers in area 1. We can also see the Summary Net Link States (LSA Type 3) that have been generated by R4 and sent into area 1.
R5#sh ip route | b Gateway Gateway of last resort is not set O IA O IA O IA O IA C O O IA O IA O IA O C O IA C 1.0.0.0/32 is subnetted, 1 subnets 1.1.1.1 [110/31] via 10.1.45.4, 00:50:57, Ethernet1/0 2.0.0.0/32 is subnetted, 1 subnets 2.2.2.2 [110/31] via 10.1.45.4, 00:50:57, Ethernet1/0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [110/21] via 10.1.45.4, 00:50:57, Ethernet1/0 4.0.0.0/32 is subnetted, 1 subnets 4.4.4.4 [110/11] via 10.1.45.4, 00:50:57, Ethernet1/0 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 6.0.0.0/32 is subnetted, 1 subnets 6.6.6.6 [110/11] via 10.1.56.6, 00:50:57, Ethernet1/1 10.0.0.0/24 is subnetted, 7 subnets 10.2.12.0 [110/40] via 10.1.45.4, 00:50:57, Ethernet1/0 10.2.13.0 [110/30] via 10.1.45.4, 00:50:57, Ethernet1/0 10.2.23.0 [110/30] via 10.1.45.4, 00:50:57, Ethernet1/0 10.1.46.0 [110/20] via 10.1.56.6, 00:50:57, Ethernet1/1 [110/20] via 10.1.45.4, 00:50:57, Ethernet1/0 10.1.45.0 is directly connected, Ethernet1/0 10.0.34.0 [110/20] via 10.1.45.4, 00:50:57, Ethernet1/0 10.1.56.0 is directly connected, Ethernet1/1

Looking at the route table we can see that we have inter-area routes to the Loopbacks for R1, R2, R3, and R4. We also have inter-area routes to the networks in Area 2, and the backbone area. It is these inter-area routes that we will look to filter from going into area 1. Lets have a look at the database on R4 where we be performing the filtering. R4:
R4#sh ip ospf database OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 0) Link ID 3.3.3.3 4.4.4.4 ADV Router 3.3.3.3 4.4.4.4 Age 745 780 Seq# Checksum Link count 0x80000003 0x00236F 2 0x80000003 0x00374E 2

Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum

10.0.34.4

4.4.4.4

780

0x80000002 0x0022BA

Summary Net Link States (Area 0) Link ID 1.1.1.1 2.2.2.2 5.5.5.5 6.6.6.6 10.1.45.0 10.1.46.0 10.1.56.0 10.2.12.0 10.2.13.0 10.2.23.0 ADV Router 3.3.3.3 3.3.3.3 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 3.3.3.3 3.3.3.3 3.3.3.3 Age 745 745 780 780 780 780 780 745 745 745 Seq# 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 Checksum 0x006DB3 0x003FDD 0x009676 0x0068A0 0x00F3F5 0x00E8FF 0x00DEF5 0x00D62D 0x0067A5 0x00F80A

Router Link States (Area 1) Link ID 4.4.4.4 5.5.5.5 6.6.6.6 ADV Router 4.4.4.4 5.5.5.5 6.6.6.6 Age 780 775 792 Seq# 0x80000004 0x80000004 0x80000004 Checksum 0x00D71F 0x00D7DC 0x007A29 Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.45.5 10.1.46.6 10.1.56.6 ADV Router 5.5.5.5 6.6.6.6 6.6.6.6 Age 775 792 792 Seq# 0x80000002 0x80000002 0x80000002 Checksum 0x00C8FA 0x00B702 0x007B30

Summary Net Link States (Area 1) Link ID 1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 10.0.34.0 10.2.12.0 10.2.13.0 10.2.23.0 ADV Router 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 Age 780 780 781 781 781 781 781 781 Seq# 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 0x80000002 Checksum 0x00B35F 0x008589 0x00F222 0x0060BA 0x00797C 0x001DD8 0x00AD51 0x003FB5

You can see above that R4 has a consistent database with all the routers in Area 0 and Area 1. It has a complete view of both areas. R4 has sent the LSA Type 3 routes from area 2 into area 1. Lets set up R4 so that it only passes the 10.2.12.0/24 and 10.2.23.0/24 routes into area 1 using the area filter-list command: R4:
router ospf 1 router-id 4.4.4.4 log-adjacency-changes area 1 filter-list prefix AREA_1_IN in network 4.4.4.4 0.0.0.0 area 0

network 10.0.34.4 0.0.0.0 area 0 network 10.1.45.4 0.0.0.0 area 1 network 10.1.46.4 0.0.0.0 area 1 ! ip prefix-list AREA_1_IN seq 5 permit 10.2.12.0/24 ip prefix-list AREA_1_IN seq 10 permit 10.2.23.0/24

You can see above that we have created a prefix-list that matches the routes that we want to permit (ie allowed) to go into area 1. We have then applied this prefix-list to the area filter-list. Notice the direction. We are only allowing those routes matched by the prefix into area 1. Its from the perspective of the area not the router. A lot of candidates make the mistake of saying area 1 filter-list prefix AREA_1_IN out thinking its filtering the routes from going out of the router. This is wrong. You have to think of it from the perspective of the areas. We are filtering routes from going into area 1. Lets verify the routing tables and OSPF database on R5: R5:
R5#sh ip ospf database OSPF Router with ID (5.5.5.5) (Process ID 1) Router Link States (Area 1) Link ID 4.4.4.4 5.5.5.5 6.6.6.6 ADV Router 4.4.4.4 5.5.5.5 6.6.6.6 Age 1530 1523 1541 Seq# 0x80000004 0x80000004 0x80000004 Checksum 0x00D71F 0x00D7DC 0x007A29 Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.45.5 10.1.46.6 10.1.56.6 ADV Router 5.5.5.5 6.6.6.6 6.6.6.6 Age 1523 1541 1541 Seq# 0x80000002 0x80000002 0x80000002 Checksum 0x00C8FA 0x00B702 0x007B30

Summary Net Link States (Area 1) Link ID 10.2.12.0 10.2.23.0 ADV Router 4.4.4.4 4.4.4.4 Age 1530 85 Seq# Checksum 0x80000002 0x001DD8 0x80000001 0x0041B4

Looks like the only LSA Type 3 (Summary Net Link States) routes that we received are the only ones we permitted on R4. Exactly what we expected! Now lets check the route table:
R5#sh ip route | b Gateway Gateway of last resort is not set C 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0

6.0.0.0/32 is subnetted, 1 subnets 6.6.6.6 [110/11] via 10.1.56.6, 00:56:45, Ethernet1/1 10.0.0.0/24 is subnetted, 5 subnets O IA 10.2.12.0 [110/40] via 10.1.45.4, 00:56:45, Ethernet1/0 O IA 10.2.23.0 [110/30] via 10.1.45.4, 00:00:05, Ethernet1/0 O 10.1.46.0 [110/20] via 10.1.56.6, 00:56:45, Ethernet1/1 [110/20] via 10.1.45.4, 00:56:45, Ethernet1/0 C 10.1.45.0 is directly connected, Ethernet1/0 C 10.1.56.0 is directly connected, Ethernet1/1 O

Awesome! The only inter-area routes that we can see on R5 are those that we permitted on the ABR (R4). Lets have a look at example of filtering routes coming out of an area: R3:
router ospf 1 router-id 3.3.3.3 log-adjacency-changes area 2 filter-list prefix AREA_2_OUT out network 3.3.3.3 0.0.0.0 area 0 network 10.0.34.3 0.0.0.0 area 0 network 10.2.13.3 0.0.0.0 area 2 network 10.2.23.3 0.0.0.0 area 2 ! ip prefix-list AREA_2_OUT seq 5 permit 10.2.23.0/24

Recall that R3 will generate a Type 3 Summary LSA for all the routes in area 2 and then send it out of area 2. In the example above we area stopping R3 creating a Type 3 LSA and sending it into area 0. We are using a prefix list to specify that the only Type 3 LSA that R3 will generate is for the 10.2.23.0/24 route. Lets check the database on R4 now, Ill just clear the OSPF process on R3 to speed to convergence along:
R3#clear ip ospf pro Reset ALL OSPF processes? [no]: yes

R4:
R4#sh ip ospf data OSPF Router with ID (4.4.4.4) (Process ID 1) Router Link States (Area 0) Link ID 3.3.3.3 4.4.4.4 ADV Router 3.3.3.3 4.4.4.4 Age 31 117 Seq# Checksum Link count 0x80000005 0x00157C 2 0x80000004 0x002B5A 2

Net Link States (Area 0)

Link ID 10.0.34.3

ADV Router 3.3.3.3

Age 127

Seq# Checksum 0x80000001 0x005C86

Summary Net Link States (Area 0) Link ID 5.5.5.5 6.6.6.6 10.1.45.0 10.1.46.0 10.1.56.0 10.2.23.0 ADV Router 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 4.4.4.4 3.3.3.3 Age 112 122 112 122 122 31 Seq# 0x80000002 0x80000001 0x80000001 0x80000001 0x80000001 0x80000003 Checksum 0x009676 0x006A9F 0x00F5F4 0x00EAFE 0x00E0F4 0x00F60B

Router Link States (Area 1) Link ID 4.4.4.4 5.5.5.5 6.6.6.6 ADV Router 4.4.4.4 5.5.5.5 6.6.6.6 Age 117 126 62 Seq# 0x80000006 0x80000006 0x80000005 Checksum 0x00D321 0x00D3DE 0x00782A Link count 2 3 3

Net Link States (Area 1) Link ID 10.1.45.5 10.1.46.6 10.1.56.6 ADV Router 5.5.5.5 6.6.6.6 6.6.6.6 Age 123 62 62 Seq# 0x80000003 0x80000003 0x80000003 Checksum 0x00C6FB 0x00B503 0x007931

Summary Net Link States (Area 1) Link ID 10.2.23.0 ADV Router 4.4.4.4 Age 117 Seq# Checksum 0x80000002 0x003FB5

You can see that the only Type 3 LSA from area 2 that R4 can see is the 10.2.23.0/24 network. Exactly what we expected. Awesome! R5:
R5#sh ip route | b Gateway Gateway of last resort is not set 5.0.0.0/32 is subnetted, 1 subnets 5.5.5.5 is directly connected, Loopback0 6.0.0.0/32 is subnetted, 1 subnets O 6.6.6.6 [110/11] via 10.1.56.6, 00:02:18, Ethernet1/1 10.0.0.0/24 is subnetted, 4 subnets O IA 10.2.23.0 [110/30] via 10.1.45.4, 00:02:18, Ethernet1/0 O 10.1.46.0 [110/20] via 10.1.56.6, 00:02:18, Ethernet1/1 [110/20] via 10.1.45.4, 00:02:18, Ethernet1/0 C 10.1.45.0 is directly connected, Ethernet1/0 C 10.1.56.0 is directly connected, Ethernet1/1 C

This in turn is the only inter-area route that we can see on R5 (remember that we are also filtering on R4).

R5#sh ip ospf database OSPF Router with ID (5.5.5.5) (Process ID 1) Router Link States (Area 1) Link ID 5.5.5.5 6.6.6.6 ADV Router 5.5.5.5 6.6.6.6 Age 6 1952 Seq# Checksum Link count 0x80000006 0x00D3DE 3 0x80000004 0x007A29 3

Net Link States (Area 1) Link ID 10.1.45.4 10.1.45.5 10.1.46.6 10.1.56.6 ADV Router 4.4.4.4 5.5.5.5 6.6.6.6 6.6.6.6 Age 3609 3 1952 1952 Seq# 0x80000001 0x80000003 0x80000002 0x80000002 Checksum 0x0003C6 0x00C6FB 0x00B702 0x007B30

Summary Net Link States (Area 1) Link ID 10.2.23.0 ADV Router 4.4.4.4 Age 4 Seq# Checksum 0x80000001 0x0041B4

So you can see that we can filter routes using the area filter-list command. The area filter-list command filters LSA Type 3s from going in or out of an area. The routes in an area still maintain a consistent route table and OSPF database. Filtering between areas stops routes from entering the OSPF database and in turn stops them from going into the route tables. In our next article in this series we will look at filtering between areas using a few of the more obtuse ways such as the area range command and summary-address commands. Hope this helps. If anybody has any questions or suggestion, leave a comment below and Ill be happy to help. Now get back to labs! :)

Summary:

OSPF can be considered Link-State within an area, and Distance Vector between areas The area filter-list command filters routes going in or out from an area.

Você também pode gostar