OcNOS SP : Troubleshooting Guide : Layer 3 Routing
Layer 3 Routing
This chapter contains steps to resolve Layer 3 routing issues.
Missing Route
When end-to-end connectivity is a problem:
1. Check if you can ping your own interface and other devices on directly connected networks.
2. Check if the route is installed in the system:
show ip route
3. Check the configuration:
show running-config
4. Check if the interface is in the correct network:
show ip interface brief
RIP
This section contains steps to resolve RIP issues.
No RIP Adjacency
 
Symptom/Cause
Solution
Interface administratively shut down
show ip interface brief
Make sure that the interface is not administratively shut down.
 
Bring up the interface using the no shutdown command, if needed.Use the show interface command to verify that the interface is up.
RIP not enabled on the interface
show ip rip interface
Verify that RIP is enabled for the interface.
network
Enable RIP on the interface
Interface configured as a passive interface
Make sure that the interface is not configured as a passive interface using the show run command
If the interface is configured as passive, give the no passive interface command
RIP advertisements not sent and received on the interface
Use a packet sniffer (such as Ethereal or TCP dump) or log messages to verify the RIP advertisements. To turn on logging:
debug rip event or debug rip packet
One router configured as RIPv1 and the other router as RIPv2
Configure the router running RIPv2:
ip rip send version 1-compatible
ip rip receive version 1 2
BGP
This section contains steps to resolve BGP issues.
A common mistake is incomplete meshing of IBGP. IBGP must be fully meshed if Route Reflectors or confederations are not used. There is no way of learning automatically from the network.
 
Symptom/Cause
Solution
IBGP neighbors not coming up
BGP sessions not formed
IBGP neighbors stuck in active/idle state
Check for IP reachability between the BGP neighbors using ping command. If ping fails, configure IGP in the network for IBGP reachability or configure static route.
If IP reachability is there, check for the BGP configuration on both sides. Ensure that the AS numbers on both sides (peers) and the local AS / remote AS are same for IBGP. Use “show run bgp” to verify the configuration.
 
Verify that the bgp router ids are different on both sides using “show run bgp” or show ip bgp Summary” command.
 
If the IBGP peering is over any address family other than IPV4/unicast, explicit neighbor activation need to be configured for that address-family.
Eg:- neighbor < peer address> activate (for address-families other than default/ipv4 unicast)
 
If configurations are correct, check for tcp connection status using “netstat –tpln “command at shell prompt. If tcp connections are not in CONNECTED State, check whether the BGP neighborship is configured over loopback interface or normal/physical interface.
 
If the neighborship/peering is over loopback interface on both sides, then explicit “neighbor <peer loopback address> update source loopback” need to be configured on both peers. If loopback interface is used only on one side (peer), the above configuration need to be applied on the other side (peer).
 
If bgp md5 authentication is enabled, ensure that the passwords match on both sides. Verify that “debug ip bgp “does not throw any message like “No md5 digest ****“ or “Invalid md5 digest “.
IBGP session should come up and verify the IBGP neighbors are in Established state using the command “show ip bgp summary” or “show ip bgp neighbors”.
EBGP neighbors not coming up
EBGP sessions not formed
EBGP neighbors stuck in Active/idle state
Check for IP reachability between the BGP neighbors using ping command. If ping fails, verify IP address config and configure static route if the ebgp peers are not directly connected.
 
Verify the EBGP config is correct using the “show run bgp” command. For EBGP the AS numbers are different on both side and the local AS/remote AS should be reverse on both peers.
 
Verify that the bgp router ids are different on both sides, using “show run bgp” or show ip bgp Summary” command.
 
If the EBGP peering is over any address family other than IPV4/unicast, explicit neighbor activation need to be configured for that address-family.
Eg:- neighbor < peer address> activate (for address-families other than default/ipv4 unicast).
 
If configurations are proper, check for tcp connection status using “netstat –tpln” command at shell prompt. If tcp connections are not in CONNECTED State, check whether the BGP neighborship is configured over loopback interface or normal/physical interface.
 
If the neighborship/peering is over loopback interface on both sides then explicit “neighbor <peer loopback address> update source loopback” need to be configured on both peers. If loopback interface is used only on one side (peer), the above config need to be applied on the other side (peer).
 
If EBGP neighbors are not directly connected, configure the bgp multihop config with appropriate ttl value. The “ttl“ value should be greater than or equal to number of hops, the bgp peer is away.
Eg: neighbor < peer address> ebgp-multihop <ttl value>.
 
If bgp md5 authentication is enabled, ensure that the passwords match on both sides. Verify that “debug ip bgp “does not throw any message like “No md5 digest ****“ or “Invalid md5 digest “.
EBGP session should come up and verify the EBGP neighbors are in Established state using the command “Show ip bgp summary” or “show ip bgp neighbors”.
BGP peering flaps
BGP session flaps
BGP establishes and drops
Check for the BGP peer flap cause/reason from the notification field in “show ip bgp neighbor < peer address>.
If the reason is “Hold timer expiry” then keepalives are not received/ processed.
If keepalives are not received, check the peer router “show ip bgp summary” and verify that the sent msg field is getting incremented.
 
If Keepalives are received but not processed then keepalives are getting stuck behind the Update messages. In other words the update messages are taking longer time to process or the system is configured beyond the claimed BGP limits.The keepalives getting queued can be verified from the “show ip bgp summary” output In Q/OutQ field.If the system is configured with in the scalability limits, please call up support team for help.
 
If the reason is “Administer configured” then the administrator has modified the fields which could trigger BGP session reset. Eg:- BGP Graceful restart configuration.If the flapping is continuous, check for interface flap, bad connectors and bgp process unstable at other end and traffic and rate limiting parameters. Check for interoperability issues too.
 
If the reason is “Malformed packet” then BGP has received a invalid packet from the peer. This is mostly caused by oversized BGP packet as BGP TLVs are variable length. Please call up the support team for help.
 
If none of these, then the issue could be PATH MTU related.Try pinging the peer with various size packet like above 1500 bytes etc. Normal ping succeeds but extended ping fails.Trouble shooting the path MTU issues is beyond the scope of this document.Please call up the support team.
Missing routes
Routes not seen in BGP table
Irregular network connectivity
For IBGP peers, the topology should be fully meshed if no Route Reflectors are configured. If Route Reflectors are used, ensure IBGP is established between all iBGP peer and the RRs and between the RRs.
If confederations are configured to avoid IBGP mesh, ensure that the confederation configuration is proper.
 
Route origination issues - If BGP is not originating the route and If the route is injected via “network prefix” command, Verify that the exact match (not best match) for the route exists in the RIB (IP RIB) using the “show ip route | include prefix “. If exact match does not exist, add a static route for the exact prefix and verify the static route is active in the RIB. BGP should originate the route now.
 
Aggregate route origination issue - If route aggregation is configured and aggregate route is missing in BGP table (“Show ip bgp”) but available in IP RIB (“show ip route”), then the configuration is not complete. For route aggregation, route needs to be there in BGP table.Add the aggregated route in BGP via the “network <aggregate prefix/mask>. Now the aggregated route can be seen in the “Show ip bgp” command also.
 
Originator/cluster id collisions - If Router reflectors are used and topology is proper, still routes not populated. The problem could be clashing cluster ids and router/originator ids. To debug this issue, check for the BGP table from the originator of the route using “show ip bgp “
Check whether the route is advertised to the peer using the “show ip bgp neighbor <peer address> advertised-routes” command.
Check whether the route is received at the peer using the “show ip bgp neighbor <peer address>“ at the peer router.
If route is not received, check for the access-list configured on the peer router.
If access list are also permitting the route, enable bgp debugs and clear the bgp session using “clear ip bgp <peer-address> out “and figure out the reason for the denial of the route.
If the reason for route ignore/drop is “originator id same as router id” Change the router ids in one of the router.
If the reason for route ignore/drop is “reflected from same cluster” then the All RRs are not peered with each other. Ensure ibgp peering between all RRs.
 
Filtering issues - If Routes are not seen with proper configuration, look for the filters/route-maps configured at the inbound and outbound of each peer. Verify that there are no typos in the filters or in the expressions used for filtering.Verify that access-list configured are for exact match.
 
Community config/mismatch issues – verify the configuration has “neighbor <peer address> send community“ to advertise the community strings. Ensure that the community match strings configured via route-map are matching/correct/proper.
 
IBGP meshing issues – Routes are marked as valid and internal but not marked as the best in the “show ip bgp” output. The nexthop for the route (mostly ebgp route) is not reachable and hence not advertised to peer. Configure static route or IGP for nexthop reachability.Another reason for missing route in an IBGP network is that not fully meshed. Ensure that IBGP is fully meshed or use RR + peer group config for ease of maintenance
High CPU utilization
In case of recursive BGP routes, ie where BGP nexthop is also learned via BGP, recursive look up may end up in invalid/illegal. IT is advisable to learn the BGP Nexthop via IGP also.
Route flapping could be one cause for High CPU utilization.
Routing loops caused by lack of IBGP meshing. Use RR or ensure IBGP full meshing.
OSPFv2
This section contains steps to resolve OSPFv2 issues.
Neighborship Formation
 
Symptom/Cause
Solution
OSPF not enabled on the interface or the corresponding interface is down.
Use network command to enable ospf on a particular network address.
Do “no shutdown” on the corresponding interface.
Use these commands:
show ip ospf interface
show ip ospf
show running-config ospf
show ip ospf neighbor
show ip ospf neighbor detail
OSPF Interface network address mismatch or subnet mask mismatch
Use these commands to find the output/find the mismatch:
show ip ospf interface
show ip interface brief
show running-config ospf
show ip ospf neighbor
show ip ospf neighbor detail.
Hello packet attribute mismatch I.e. interface hello interval or dead interval mismatch
Use these commands to find the output/mismatch:
show running-config ospf
show ip ospf interface
debug ospf nfsm
debug ospf packet hello detail
OSPF interface configured as passive interface. Passive interfaces will not send hello packets.
Use these commands:
show ip ospf interface
show ip ospf
show running ospf
OSPF option field mismatch i.e. Ospf External Routing Capability mismatch due to stub area mismatch.
Configure same stubby-area.
Use these commands:
debug ospf packet hello
show ip ospf
show running ospf
OSPF gets struck in two-way state when there is no DR/BDR elected i.e. both routers configured with priority 0
One router should be configured with a priority other than 0.
Use these commands:
show ip ospf neighbor
show running ospf
OSPF can get stuck in Exstart/exchange state when the maximum transmission unit (MTU) do not match
Use these commands:
show ip ospf interface
show running ospf
show ip ospf neighbor
OSPF network type mismatch can cause timers (hello-interval) mismatch
Use these commands:
show ip ospf interface
debug ospf packet hello
show running ospf
Virtual Link Neighborship Formation
 
Symptom/Cause
Solution
OSPF same router-id and loopback address
Use these commands:
 
show ip ospf
show running-config ospf
show ip ospf interface
OSPF area mismatch for virtual-link
Use these commands:
 
show running-config ospf
show ip ospf virtual-link
OSPF virtual-link router-id mismatch causing virtual-link down
Use these commands:
 
show running-config ospf
show ip ospf virtual-link
show ip ospf interface
show ip ospf neighbor
OSPF not enabled on the interface or the corresponding interface is down causing vlink down
Use these commands:
 
show ip ospf
show running-config ospf
show ip ospf virtual-link
show ip ospf interface
Multi-area Adjacency Formation
 
Symptom/Cause
Solution
OSPF Multi-Area Adjacency happens only if the adjacency over the primary link is up.
Use these commands:
 
show ip ospf neighbor
show ip ospf interface
Multi-area configuration mismatch, such as area-id or process-id mismatch.
Use these commands:
 
show running-config
show ip ospf multi-area-adjacencies
show ip ospf neighbor
Multi-Area link remains down, if the Router is not an "ABR"
Use these commands:
 
show ip ospf
show ip ospf multi-area-adjacency.
Multi-Area link will be removed if the primary link is down
Use these commands:
 
show running-config
show ip ospf interface
show ip ospf multi-area-adjacency
For multi access networks, it is required to specify the neighbor's interface address.
 
Multi-area configuration mismatch such as when the neighbor's address does not match any of the OSPF networks or the neighbor’s address is incorrect.
Use these commands:
 
show running-config ospf
show ip ospf multi-area-adjacency
Multi-area adjacency not applicable for the area on which virtual-link is enabled and vice-versa.
Use this command:
 
show running-config ospf
Graceful Restart (using Link Local Signaling) Neighborship Formation
 
Symptom/Cause
Solution
Daemon restarted after maximum router dead interval of all OSPF interfaces on restarting node
Use this command on restarting node:
 
show ip ospf interface
Capability mismatch between restarting and helper node
Enable capability lls in router node.
Use these commands on both nodes:
 
show ip ospf
show running-config ospf
Configurations not saved before restart
Use any one of these commands and check the saved file in /usr/local/etc:
 
write <file_path>
write file
write memory
write terminal
Two routers on same segment get restarted at same time
Use these commands on restarting node:
 
debug ospf nfsm
debug ospf packet hello recv detail
show ip ospf neighbor
Helper router got its LSDB changed while helping
Use these commands on restarting node:
 
debug ospf nfsm
debug ospf packet hello recv detail
show ip ospf neighbor
“Resync timeout timer” is not sufficient to sync the whole database
Use these commands on restarting node:
 
debug ospf nfsm
show ip ospf neighbor
OSPFv3
This section contains steps to resolve OSPFv3 issues.
Neighborship Formation
 
Symptom/Cause
Solution
OSPF not enabled on the interface or the corresponding interface is down
Use network command to enable OSPFv3 on a particular network address. Do no shutdown on the corresponding interface. Use these commands:
 
show ipv6 ospf interface
show ipv6 ospf
show running-config ospfv3
show ipv6 ospf neighbor
show ipv6 ospf neighbor detail
Hello packet attribute mismatch i.e. interface hello interval or dead interval mismatch
Use these commands to find the output/mismatch:
 
show running-config ospfv3
show ipv6 ospf interface
debug ipv6 ospf nfsm
debug ipv6 ospf packet hello detail
OSPF option field mismatch i.e. Ospf External Routing Capability mismatch due to stub area mismatch
Configure the same stubby-area. Use these commands:
 
debug ipv6 ospf packet hello
show ipv6 ospf
show running-config ospfv3
OSPF gets stuck in two-way state when there is no DR/BDR elected i.e. both routers configuration with priority 0
One router should be configured with a priority other than 0. Use these commands:
 
show ipv6 ospf neighbor
show running-config ospfv3
OSPF can get stuck in Exstart/Exchange state when the maximum transmission unit (MTU) does not match
Use these commands:
 
show ipv6 ospf interface
show running-config ospfv3
show ipv6 ospf neighbor
OSPF network type mismatch can cause timers (hello-interval) mismatch
Use these commands:
 
show ipv6 ospf interface
debug ipv6 ospf packet hello
show running-config ospfv3
OSPF same router-id and loopback address
Use these commands:
 
show ipv6 ospf
show running-config ospv3
show ipv6 ospf interface
Ospf area mismatch for virtual-link
Use these commands:
 
show running-config ospfv3
show ipv6 ospf virtual-link
OSPF virtual-link router-id mismatch cause virtual-link down.
Use these commands:
 
show running-config ospfv3
show ipv6 ospf virtual-link
show ipv6 ospf interface
show ipv6 ospf neighbor
OSPF vlink Global remote address is NULL causing virtual-link adjacency down.
Use these commands:
 
show ipv6 ospf interface
show ipv6 ospf virtual-link
OSPF not enabled on the interface or the corresponding interface is down causing vlink down.
Use these commands:
 
show ipv6 ospf
show running-config ospfv3
show ipv6 ospf virtual-link
show ipv6 ospf interface
VRRP
This section contains steps to resolve VRRP issues.
 
Symptom/Cause
Solution
Incorrect VRRP States
Make sure the interfaces are up and running by using the show interface command. If the interface is down, give the no shutdown command in interface mode to bring up the interface.
Or
Use the ifconfig IFNAME up command to bring up the interface.
 
Make sure the interface has an IP address in the that matches the subnet of the VRRP session’s virtual-ip.
If not exist, add the ip address in interface mode using the command “ip address A.B.C.D/M
The configured IP address is displayed in the output of “show running-config interface <IFNAME>
 
Make sure that both VRRP routers can reach each other by pinging.
If both routers cannot reach each other, check the network connections for the default Master and default Backup routers.
 
Check the advertisement interval on Master and Backup routers. The advertisement interval must be the same on both. The default advertisement interval = 1 second.
 
Use the advertisement-interval command in router mode to configure the advertisement interval.
BFD
This section contains steps to resolve BFD issues.
 
Symptom/Cause
Solution
BFD session not created
Use the show run command to make sure that the interface is not administratively shutdown. If shutdown is configured, remove this configuration with the no shutdown command.
Use the show interface command to make sure that the interface is up.
 
Check if minimum BFD configuration exists for the respective client. Client list includes static route, RIP, OSPF, BGP, ISIS. For configuration refer BFD command reference guide.
 
Check if BFD is administratively down. If BFD is admin-down, session will show state as Admin-Down for 1 minute and then session information is deleted. No session will be seen after that.
 
The next hop for which BFD is enabled should be reachable. For example in OSPF, OSPF neighbor adjacency should be formed for BFD session to be created to monitor the neighbor next hop. This applies to all clients.
 
If configuration is as expected, then enable BFD debug logs and check if packets are received, transmitted for that session. To turn on logging, enter the debug bfd all command
BFD session down
Check the diagnostic reason which can be Neighbor Signaled Down (Remote admin Down) or Control Detect Expiry (non-receipt of hello packets from neighbor for detect multiplier time).
show bfd session detail
IS-IS
Adjacency Problems
Normally, the causes for IS-IS adjacency related problems are because of link failures and configuration mistakes. The link failures can be easily detected by checking show isis interface command.
The first step to troubleshoot IS-IS adjacency is the show clns neighbors command which displays the basic configuration. The show clns is-neighbors command can also be used but it lists only neighboring routers, while the former command lists all types of adjacencies both for IS-IS and for ES-IS.
 
Symptom/Cause
Solution
Expected adjacencies not formed or not seen in the output of show clns neighbors
 
The interfaces might have been administratively shut down
The IS-IS configurations are incorrect.
The levels configured on the interfaces might be mismatching
The IP subnet configured is incorrect.
Duplicate system ID is configured in IS-IS area.
Check for link failures. We can verify whether all the interfaces on which IS-IS adjacency is enabled are in UP state. This can be confirmed by checking the output of sh ip interface brief command. Once the state of the interface is verified to be in UP state, do a ping to the other end and check the connectivity is proper. If the ping fails, that means the physical connectivity problem exits, which should be resolved before going further.
 
If the link is fine, check the IS-IS configurations. IS-IS is enabled in two steps, first is creating isis process as shown below:
 
router isis
net 49.0010.0000.0001.00
 
A misconfigured NET command could also lead to IS-IS adjacency problem. Next step is to attach this process to the appropriate interfaces with command ip router isis.
 
By default, IS-IS router processes have Level 1-2 capability. We can configure IS-IS routers to be level-1 only or level-2 only by using the is-type command. If the levels are mismatching between two directly connected routers adjacency is not formed. By correcting the levels the adjacency issue can be resolved.
 
If the directly connected routers are not present in the same IP subnet, adjacencies are not formed. In this case, the hellos received will be rejected as the interface addresses are not in same subnet. Hence make sure that the interfaces are configured in the same IP subnet.
 
The system ID configured is unique throughout the network. If same system ID is configured for any two IS-IS routers adjacency will not be established. By enabling debug logs we can find the interface which is sending hellos with duplicate system ID. Hence make sure that system IDs are different across the network.
The adjacency state of some or all neighbors is struck in INIT state in show clns neighbors
 
Authentication problems.
The MTU (Maximum Transmission Unit) mismatch has occurred.
If IS-IS authentication is enabled, first resolve this issue. If IS-IS authentication is not enabled, the problem might be with mismatched MTUs. First verify the authentication configurations on the routers. Make sure that proper authentication method is configured and the passwords are consistent. Sometimes, authentication may be enabled on only one side in which case the other side will not be able to process the hellos and hence the neighbor state will be stuck in INIT state.
 
If the authentication problem is resolved and still the neighbor state is stuck in INIT, the possible cause will be because of mismatched MTU. The show isis interface command displays the MTU size of the link. You can also enable debug logs and check the MTU of the packets being sent on the interfaces.
Routing Update Problems
This section covers IS-IS routing update problems based on the assumption that there are no adjacency problems.
As a first step, check the contents of the LSPs. The show isis database detail command gives the detail of the specific LSP contents as shown below:
sh isis database level-1 0010.0000.0001.00-00 detail
Area 1:
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
0010.0000.0001.00-00 0x00000002 0x7746 1172 0/0/0
Area Address: 49
NLPID: 0xCC
IP Address: 11.11.11.1
Metric: 10 IS 0010.0000.0001.01
Metric: 10 IP 11.11.11.0 255.255.255.0
Another importatnt command is show isis topology which displays all known routers.
sh isis topology
 
Area 1:
IS-IS paths to level-1 routers
System Id Metric Next-Hop Interface SNPA
0010.0000.0001 10 0010.0000.0001 p7p1 0800.275a.1f66
0010.0000.0002 --
 
IS-IS paths to level-2 routers
System Id Metric Next-Hop Interface SNPA
0010.0000.0001 10 0010.0000.0001 p7p1 0800.275a.1f66
0010.0000.0002 --
 
Symptom/Cause
Solution
Route advertisement
Most route advertisement problems are caused because of incorrect configurations. If some routes are missing, use the show commands mentioned above to find more information about topology and LSPs. Using the knowledge about topology you can narrow down the problem to a single router.
 
As IS-IS is a link-state protocol, the routers depend on LSPs to learn the topology and routing information. If a route is missing, it might be because the routers did not receive the original LSP or the LSP was received corrupted and hence was purged. In such cases, enabling debug logs for LSPs will help to determine the problem.
Route flaps
Route flaps occur because of unstable links between the routers. As the links flap between UP and DOWN state, they induce SPF calculation resulting in high CPU utilization which might lead to crashes
show clns neighbors detail
Route flaps can be identified by checking the Uptime for the neighbor:
 
In these cases physical connectivity should be stabilized to resolve the problem.
 
In more complicated cases, the flapping might happen because of corrupted LSP storms or a routing loop. In such cases enabling debug logs for spf calculation helps to know which LSPs are changing more frequently and triggering SPF calculations. Care should be taken while enabling logs for these cases as CPU will be already overloaded.
Route redistribution
IS-IS allows external routes like static, connected, or routes from other protocols to be distributed into IS-IS levels. The main reasons for external routes missing in routing table could be because of the wrong configuration. The source of the route may not be active in which case the external route will not be installed in the routing table.
show ip route
Verify that the source of the route is active.
 
In case of static routes, the nexthop might not be reachable as the interface is down and hence it is not present in the routing table.
show ip interface brief
Check the interface state.
 
External routes might be filtered in the route-map or distribute-list at the source, in which case it is the correct behavior to not install the route in the routing table.
Graceful Restart for IS-IS
 
Symptom/Cause
Solution
Restarting node does not send RR bit in Hello packet when "graceful restart" is performed.
Use this command on restarting node:
show running-config isis
Check if "no capability restart graceful" is not configured.
graceful restart capability is enabled by default.
Helper node does not respond with RA bit for the Restart request received from neighbor.
Use this command on helper node:
show running-config isis
 
Check if "isis restart helper" is configured on the helper node.
 
Configurations not saved before restart
Use any one of these commands and check the saved file in /usr/local/etc:
 
write <file_path>
write file
write memory
write terminal
Restarting router does not remove the stale marked routes from RIB (after coming up).
Use these commands on restarting node:
debug isis ifsm
show rib forwarding-timer
Check the show command output. Timer should not be running. On successful DB sync, this timer should be cancelled.
The starting router does not send SA bit in hello packet.
Use these commands on starting node:
show running-config isis
 
Check whether "isis restart suppress-adjacency" is configured.
FAQ
Q: What happens to the RIP learned routes whose network address is same as one of the directly connected IPs, when the prefix length is greater than, less than, or equal to, that of the directly connected interface?
All routes with greater prefix length and less prefix length will be displayed in the RIP routing table. The equal prefix- length entry will be discarded.
For example. if the 1.1.0.0/24, 1.1.0.0/25 and 1.1.0.0/23 routes are redistributed into RIP, and a neighbor has an interface with IP 1.1.0.2/24, the RIP route entry of the 1.1.0.0/24 network will not be available. But, the 1.1.0.0/23 and
1.1.0.0/25 entries will be available in the RIP routing table. The 1.1.0.0/24 entry is available as a directly connected entry in the routing table. If this interface is down, the RIP route will become active, until the interface comes up.
Q: When redistributing other routes to RIP, why does the redistributed route always override the routes learned by RIP?
RIP learned routes have lower priority than redistributed routes (for example, connected/static/ISIS). Therefore, the redistributed routes always override the routes learned by RIP.
Q: Why is the BGP session reset after any BGP capability is configured?
In BGP, capabilities are advertised in the OPEN message during session initialization. If a capability is enabled or disabled after the session is established, the BGP session needs to be reset, and a new capability is included in the OPEN message.
Q: How do I set up “neighbor send-community” in BGP?
The “neighbor send-community” is set up by default. By default, on receiving the communities attribute, the router re- announces them to the neighbor. This command does not appear in the list of available commands in the Router mode. It is visible only when the user has used the no neighbor send-community command. Please refer to the BGP Command Reference for details on how to use this command.
Use the show ip bgp neighbor command to confirm that the neighbor send-community is set up.
Q: What is Route Reflection used for?
Route Reflection is used in IBGP to resolve the IBGP full mesh problem. Configuring one or more routers as Route
Reflectors reduces the number of connections between BGP peers within an Autonomous System (AS).
The Route Reflecting BGP peer has to be configured with the peer addresses of all its route reflection clients. The Route Reflector is responsible for:
Sending updates from a client peer to other client peers, as well as non-client peers.
Sending updates from non-client peers to client peers.
Q: Can you explain more about the BGP “neighbor next-hop-self” command?
The neighbor next-hop-self command is only effective in the case of IBGP. For example:
                             EBGP                        IBGP
              R3 -----------------------  R1 -----------------------  R2
On executing the neighbor <a.b.c.d> next-hop-self command on R1, the R1 router advertises the routes (if any) with the next-hop attribute that equals the R1 IP address.
This command is useful for advertising the routes learned by R1 from other routers, and are not reachable by R2.
Q: Does the “no bgp graceful restart” command turn off graceful restart? Or does it just set the parameters back to the default?
The no bgp graceful-restart command turns off the graceful restart functionality.
The no bgp graceful-restart restart-time and no bgp graceful-restart stalepath-time commands reset the timer values to the default values.
Q: Which BGP draft version is used to test conformance?
IP Infusion Inc. uses the IXIA ANVL test suite for testing conformance. The latest version of ANVL is based on draft- ietf-idr-bgp4-26.txt.
Q: Can I change the Area ID of an existing OSPF network configuration?
No, you cannot change the Area ID without deleting the existing configuration. You need to remove the network
A.B.C.D/X area Y before changing the area ID of this network.
For example, entering “network 10.73.0.0/16 area 0.0.0.5” when “network 10.73.0.0/16 area 0.0.0.1” already exists, will display a warning message.
Q: How do I display information about max-age? I used the “show ip ospf database max-age” command: max-age was not displayed.
The show ip ospf database max-age command maintains a list of the all the LSAs in the database that have reached the max-age (3600 seconds).
If the LSAs have not reached the max-age, it is not displayed. To test the functionality of max-age, follow these steps:
1. Connect two routers, R1 and R2 both of them running the OSPF daemon.
2. After a few minutes, kill the OSPF daemon on one of the routers (say on R2).
3. Wait for one hour to get a display of the list of LSAs that have reached the max-age on R1.
The following is a sample output of the show ip ospf database max-age command on R1:
# show ip ospf database max-age
OSPF Router process 100 with ID (3.3.3.4)
MaxAge Link States:
Link type: 7
Link State ID: 37.37.37.0
Advertising Router: 3.3.3.1
LSA lock count: 6
Link type: 7
Link State ID: 10.0.0.0
Advertising Router: 3.3.3.1
LSA lock count: 6
Link type: 7
Link State ID: 20.255.37.37
Advertising Router: 3.3.3.1
LSA lock count: 6
Q: How do I create a secondary loopback address? This address has to be advertised by LSAs to make it reachable from other routers and hosts.
Configure a secondary loopback address as follows:
(config)# interface lo
(config-if)# ip address A.B.C.D/32
For this loopback address to be advertised by LSAs, enable OSPF on this interface by configuring the routing process, and specifying the Process ID. The Process ID should be a unique positive integer identifying the routing process. Then define the interface and associate the area ID with the interface.
(config)# router ospf [process id]
(config-router)# network A.B.C.D/32 area 0