Category list

Recipe 8.15. OSPF Route Tagging

Problem

You want to tag specific routes to prevent routing loops during mutual redistributing between routing protocols.

Solution

You can tag external routes in OSPF by using the redistribute command with the tag keyword:

Router1#

configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#

router ospf




55



Router1(config-router)#

redistribute eigrp




11




metric-type




1




subnets tag




67



Router1(config-router)#

exit

Router1(config)#

end

Router1#

Discussion

Route tagging in OSPF is similar to route tagging in RIP Version 2 and EIGRP, which we discussed in Chapters 6 and 7, respectively. Just like those protocols, OSPF doesn't directly use the route tags. But they are useful when distributing routes into foreign routing protocols.

In the example configuration, this router, Router1 , is an ASBR that connects to a network that uses EIGRP process number 11. We have configured this router so that it redistributes these EIGRP routes into OSPF as External Type 1 routes with a tag value of 67:

Router5#

show ip route




10.2.2.0



Routing entry for 10.2.2.0/30
  Known via "ospf 87", distance 110, metric 45

Tag 67

, type

extern 1

Redistributing via ospf 87
  Last update from 172.25.1.5 on Ethernet0, 00:07:14 ago
  Routing Descriptor Blocks:
  * 172.25.1.5, from 172.25.25.1, 00:07:14 ago, via Ethernet0
      Route metric is 45, traffic share count is 1
Router5#

The tags become useful when you go to redistribute the tagged routes into another network. For example, the following configuration shows how we might redistribute this group of external routes into RIP, but no internal OSPF routes. This sort of configuration is useful if you want to allow the RIP and EIGRP external networks to talk to one another through your OSPF network, but prevent them from seeing your own routing tables:

Router1#

configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#

router rip

Router1(config-router)#

version




2



Router1(config-router)#

redistribute ospf




87




route-map




TAGGEDROUTES



Router1(config-router)#

exit

Router1(config)#

route-map




TAGGEDROUTES




permit




10



Router1(config-route-map)#

match tag




67



Router1(config-route-map)#

exit

Router1(config)#

route-map




TAGGEDROUTES




deny




20



Router1(config-route-map)#

exit

Router1(config)#

end

Router1#

Recipe 8.16. Logging OSPF Adjacency Changes

Problem

You want to monitor OSPF adjacency state changes to ensure network stability.

Solution

The log-adjacency-changes configuration command instructs the router to create a log message whenever two OSPF routers establish or break their adjacency relationship:

Router2#

configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#

router ospf




12



Router2(config-router)#

log-adjacency-changes

Router2(config-router)#

exit

Router2(config)#

end

Router2#

Discussion

No routes are exchanged between routers if they lose their adjacency relationship. Every time this relationship is lost, the corresponding routes are removed, and every router in the area must be updated with the new network topology. This can be quite disruptive to a network. So it can be extremely useful to log these changes for troubleshooting, as well as for reconstructing serious problems that occurred in the past. We recommend using this option.

Here are some example log messages. The first message shows that the adjacency has been lost due to an expired timer. This means that this router has not heard its neighbor's regularly scheduled "hello" messages recently, so it needs to delete its routes. A few minutes later, the neighbor has come back and reestablished its adjacency:

Oct 14 09:54:13: %OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 on Serial0/0 from FULL to DOWN,

Neighbor Down: Dead timer expired

Oct 14 09:57:43: %OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 on Serial0/0 from LOADING to FULL,

Loading Done

Starting in 12.1, Cisco added the keyword detail :

Router2#

configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#

router ospf




12



Router2(config-router)#

log-adjacency-changes detail

Router2(config-router)#

exit

Router2(config)#

end

Router2#

When you enable the detailed logging, you get considerably more information. It now shows all of the various stages that OSPF neighbors need to go through to establish their adjacencies:

%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from FULL to DOWN, Neighbor Down: Dead timer expired
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from DOWN to INIT, Received Hello
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from INIT to 2WAY, 2-Way Received
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from 2WAY to EXSTART, AdjOK?
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from EXSTART to EXCHANGE, Negotiation Done
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from EXCHANGE to LOADING, Exchange Done
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from LOADING to FULL, Loading Done

This level of detail is rarely required unless you suspect that there is a problem with the handshake process between two routers. In that case, it might be more effective to use debugging as discussed in Recipe 8.21. We wouldn't normally recommend using the detail option in production networks because it just fills up the logs with extra messages. It is usually sufficient to know when two neighbors lost their adjacency and when they managed to reestablish it.