installed in the routing table is that Layer 1 or
Layer 2 is down. If this is the case, it is not a routing
protocol problem. Layer 1 or 2 could be down for several
reasons. The following is a list of the most common things to
check if an interface or line protocol is down:
- Unplugged cable
- Loose cable
- Bad cable
- Bad transceiver
- Bad port
- Bad
interface card
- Layer 2 problem at the Telco in the
case of a WAN link
- Missing clockrate
statement in the case of back-to-back serial connection
This example shows two routers running OSPF between each
other. Debugs and Verification
Figure shows the
output of show ip ospf interface command for Ethernet 0,
which shows that the line protocol is down. Figure shows the
output of debug ip igrp transactions command. The output
shows that the router is not sending or receiving any IGRP
updates because Layer 2 is down. Solution
To correct
this problem, the Layer 2 problem must be fixed by checking
previously mentioned conditions. The solution could be as
simple as plugging in a cable, or it could be as complex as bad
hardware, in which case the hardware must be replaced. Figure
shows the output of show ip ospf interface command for
Ethernet 0 after the Layer 2 problem is corrected. Commands
used in this example and some of the commands that can be used
for other routing protocols include: - show ip
interface
- show ip interface brief
- show ip eigrp interfaces
- show ip ospf
interface
- debug ip routing
- debug ip rip
- debug ip igrp
transactions
- debug ip eigrp
- debug isis adj packets
- debug isis
update-packets
Content 5.3
Common IGP Routing Protocol Issues, Causes, and
Solutions 5.3.4 Distribute-list in/out
blocking A distribute list is a filtering mechanism for
routing updates. Distribute lists are not supported for OSPF or
IS-IS. Routers running link state protocols determine their
routes based on information in their link state database,
rather than the advertised route entries received from its
neighbors. Route filters have no effect on link state
advertisements or the link state database. This is because a
basic requirement of link state routing protocols is that
routers in an area must have identical link state databases. In
addition, it is important to remember that distribute lists do
not permit or deny the actual packets from entering the
routers, only which routing updates a router will send or
receive. A distribute list calls on an access list and checks
which networks are supposed to be permitted. If the access list
does not contain the network, it will automatically be denied.
A distribute list can be applied on incoming routing updates or
outgoing routing updates. This example shows two routers
running IGRP between each other. A distribute-list in is
configured, but because the access list does not contain the
permit statement for 131.108.0.0, router R2 is not
installing this route in the routing table. Debugs and
Verification
Figure shows the current configuration of
router R2. In the access list configuration, the network
131.108.0.0 is not explicitly permitted (and, therefore
denied), so the router is not installing any subnets of the
131.108.0.0 network. In this case, the access list was
incorrectly configured with the wrong network, 131.107.0.0.
Solution
Figure shows the new configuration of
router R2 with the correct access list. Figure shows that
router R2 is learning IGRP routes after the configuration
change.
Content 5.3 Common IGP Routing
Protocol Issues, Causes, and Solutions 5.3.5
Access list blocking Standard access lists are used to
filter the traffic based on source address. Extended access
lists are used to filter the traffic based on the source or
destination address. These access lists can be applied on the
interface with the interface-level command ip
access-group {access-list number} {in|out} to
filter the incoming or outgoing traffic. When the access list
is applied, make sure that it does not block the source address
of the routing update, or for routing protocols that form
adjacencies that it is not blocking the Hello packets from
being sent or received. It is very common to implement an
access list for security measures at the interface level. In
the case of routing protocols such as OSPF that use multicasts
to exchange Hellos, be sure to permit the multicast Hello
addresses in the access list. Otherwise, the access list might
block the OSPF multicast address unknowingly and prevent OSPF
from forming neighbors on that interface. This situation
happens only when the access list is blocking Hellos on both
routers. If only one side is blocking OSPF Hellos, the output
of show ip ospf neighbor will indicate that the
neighbor is stuck in INIT state. This example shows two routers
running OSPF between each other. Debugs and
Verification
Figure shows the OSPF configuration of
both routers R1 and R2, the access list is permitting only
incoming TCP and UDP traffic. The inbound access list checks
only traffic coming in on that interface. Because there is an
implicit deny at the end of each access list, this
access list will block the OSPF multicast address of 224.0.0.5.
The access list 101 in command is defined for debugging
purposes only. Figure shows the output of debug ip packet
101 detail command. This debug tracks down the OSPF
Hello packet only on the Ethernet segment. The debug
shows that OSPF Hello packet from router R1 is denied on R2.
This is because OSPF packets are carried directly over IP, and
do not include a TCP or UDP header. Solution
To
correct this problem, the access list must be reconfigured to
permit OSPF multicast Hellos. Figure shows the configuration
that fixes this problem. In this configuration, OSPF multicast
Hellos are permitted. Similarly, the access list on the other
side needs to be changed, making sure that the OSPF Hellos are
permitted in the access list. Figure shows the OSPF neighbor in
FULL state after fixing the configuration. Commands used in
this example and some of the commands that can be used for
other routing protocols include: - show ip eigrp
neighbors
- show ip ospf neighbor
- debug ip packet
Content
5.3 Common IGP Routing Protocol Issues,
Causes, and Solutions 5.3.6 Advertised network
interface is down IGP routing protocols will not advertise
any interface network address that is physically down. As soon
as the advertised network comes back up, the routing protocol
will start advertising it again in its updates. This example
shows two routers running RIP between each other. Debugs and
Verification
Figure shows that interface Ethernet 0 is
down. Figure shows the output from the debug ip rip
command. In this debug, router R1 is not sending or
receiving any RIP updates because Layer 2 is down. There is no
output from this debug command because of this problem.
Solution
RIP, like other routing protocols, runs
above Layer 2. RIP cannot send or receive any routes if Layer 2
is down. To correct this problem, Layer 2 or Layer 1 must be
corrected. Figure shows the interface Ethernet 0 after fixing
the Layer 2 problem. Figure shows the routing table of router
R2. Commands used in this example and some of the commands that
can be used for other routing protocols include:
- show ip interface
- show ip interface
brief
- show ip eigrp interfaces
- show ip ospf interface
- debug ip routing
- debug ip rip
- debug ip igrp
transactions
- debug ip eigrp
- debug isis adj packets
- debug isis