BIG-IP Advanced Routing™ · CHAPTER 5 Troubleshooting RIP ... This guide is intended for all...

BIG-IP® Advanced Routing™Troubleshooting Guide

Version 7.5.1

Publication DateThis document was published on June 25, 2013.

Legal Notices

CopyrightCopyright 2001-2013, F5 Networks, Inc. All rights reserved.

F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice.

TrademarksAAM, Access Policy Manager, Advanced Client Authentication, Advanced Firewall Manager, Advanced Routing, AFM, Alive With F5, APM, Application Acceleration Manager, Application Security Manager, ARX, AskF5, ASM, BIG-IP, BIG-IQ, Cloud Extender, CloudFucious, Cloud Manager, Clustered Multiprocessing, CMP, COHESION, Data Manager, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client, Edge Gateway, Edge Portal, ELEVATE, EM, Enterprise Manager, ENGAGE, F5, F5 [DESIGN], F5 Certified [DESIGN], F5 Networks, Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM, GUARDIAN, iApps, IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iControl, iHealth, iQuery, iRules, iRules OnDemand, iSession, L7 Rate Shaping, LC, Link Controller, Local Traffic Manager, LTM, LineRate, LineRate Systems [DESIGN], LROS, Message Security Manager, MSM, OneConnect, Packet Velocity, PEM, Policy Enforcement Manager, Protocol Security Manager, PSM, Real Traffic Policy Builder, ScaleN, Signalling Delivery Controller, SDC, SSL Acceleration, StrongBox, SuperVIP, SYN Check, TCP Express, TDR, TMOS, Traffic Management Operating System, Traffix Systems, Traffix Systems (DESIGN), Transparent Data Reduction, UNITY, VAULT, VIPRION, vCMP, VE F5 [DESIGN], Virtual Clustered Multiprocessing, WA, WAN Optimization Manager, WebAccelerator, WOM, and ZoneRunner, are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without F5's express written consent.

All other product and company names herein may be trademarks of their respective owners.

A portion of this reference guide is copyrighted by IP Infusion, Inc.

ZebOS is a registered trademark, and IP Infusion and the ipinfusion logo are trademarks of IP Infusion.All other trademarks are trademarks of their respective companies.

This documentation is subject to change without notice. The software described in this document and this documentation are furnished under a license agreement or nondisclosure agreement. The software and documentation may be used or copied only in accordance with the terms of the applicable agreement. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or any means electronic or mechanical, including photocopying and recording for any purpose other than the purchaser's internal use without the written permission of IP Infusion Inc.

F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no responsibility for the use of this information, nor any infringement of patents or other rights of third parties which may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right to change specifications at any time without notice.

All other product and company names herein may be trademarks of their respective owners.

i

Table of Contents

CHAPTER 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Useful System Commands and Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

CHAPTER 2 Debugging and Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Logging to stdout (terminal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Logging information to a file or syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Turning off debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

CHAPTER 3 Troubleshooting BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5No BGP Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Useful Show Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

show ip bgp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

show ip bgp summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

show ip bgp neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

CHAPTER 4 Troubleshooting OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11No OSPF Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Useful Show Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

show ip ospf interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

show ip ospf neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

show ip ospf database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

CHAPTER 5 Troubleshooting RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17No RIP Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17


show ip rip interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

show ip rip database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

CHAPTER 6 Troubleshooting LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21LDP Session is not UP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

CHAPTER 7 Troubleshooting VRRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Incorrect VRRP States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

CHAPTER 8 Troubleshooting PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25No PIM adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

No BSR and RP information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

RP not advertised in the BSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Troubleshooting Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26


show ip pim sparse-mode mroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

show ip pim sparse-mode interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

iii

Table of Contents

CHAPTER 9 Troubleshooting BGP4+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31No BGP Adjacency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Useful Show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

show bgp ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

show bgp ipv6 summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

CHAPTER 10 Troubleshooting OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35No OSPF Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Useful Show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

show ipv6 ospf database link [adv-router] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

show ipv6 ospf database intra-prefix [adv-router]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

CHAPTER 11 Troubleshooting RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41No RIPng Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

CHAPTER 12 Route Selection in NSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43How Does NSM Add Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

How does NSM Delete Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Show Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

show ip route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

show ip route database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

CHAPTER 13 Miscellaneous Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51Kernel does not notify the NSM about updating the MTU/metric . . . . . . . . . . . . . . . . . . . . 51

OSPF adjacency lost (System Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Remote Devices are unreachable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index - 1

iv

CHAPTER 1 Introduction

This guide is intended for all network administrators and application developers who install and configure ZebOS® IP routing software. It requires that the user has a broad understanding of networking principles and network configuration. Use this information with the other F5 Networks technical information available with the software.

This guide contains tips for troubleshooting basic issues faced during installation, configuration and management of ZebOS IP routing software.

Useful System Commands and Utilities

These Unix Commands and GNU Utilities are useful in troubleshooting. Unix commands might have different syntax when used on different platforms.

Note: Use man <command> to get detailed information about any Unix command.

id This id utility displays the system identifications (ID) for a specified user. The system IDs identify users and user groups to the system. This utility displays the user name, user ID, as well as the group name and group ID of the user.

In addition, id also displays the effective user and group IDs (euid). Install ZebOS as a root user. Use this command to verify that you are the root user.

ifconfig Configures a network interface. It is used at boot time to set up interfaces or for debugging purposes. Use the -a flag with this command to instruct ifconfig to display information about all interfaces on the system.

You can use this utility to configure the loopback address:

ifconfig lo 127.0.0.1

ls Lists the contents of the current working directory.

man It provides access to online manual pages and information on how to run a specified command. For example, to learn more about rm (file-removal) command type:

man rm

Use option -k with the man command if you do not know which command to look for. This option directs man to search for manual pages containing the specified keyword.

If the information is more than one screenful of text, the man command shows the first screen and prompts you with More at the bottom of the screen. Hit the spacebar when you are ready for the next screenful. Type q to quit.

netstat Displays different network related data structures. You can use various options to get different outputs, such as -r option displays routing tables. The -n option used along with the -r option displays network addresses as numbers.

ping It is used to see if a system is operating and also to see if network connections are intact. It uses the Internet Control Message Protocol (ICMP) Echo function (detailed in RFC 792). A small packet is sent through the network to a particular IP address. The sender then listens for a return packet, if connections are good and the target system is up, a good return packet is received.

1

Introduction

ping6 It uses the ICMPv6 Echo function (detailed in RFC 2463) to report errors encountered in processing packets and to perform diagnostics.

This utility is available on Linux and FreeBSD systems. On a Solaris system the ping utility has both IPv4 and IPv6 capability.

ssh Use Secure Shell (SSH) to log into another computer over a network, to execute commands from a remote machine, and to move files from one machine to another. SSH can be used in place of telnet, rlogin, rsh etc. It provides authentication and secure communications over insecure channels.

su The su command changes the user ID to those of the root user or to any other specified user.

telnet It is a User Interface to the TELNET protocol. It runs on your computer and connects it to a server on the network. You can then enter commands through the Telnet program and they are executed as if you were entering them directly on the server console. This enables you to control the server and communicate with other systems on the network.

traceroute Traces a packet from your system to a host showing the number of hops the packet requires to reach the host and how long each hop takes.

traceroute6 Displays information about the route taken by the IPv6 packets to reach the destination.

This utility is available on Linux and FreeBSD systems. On a Solaris system the traceroute utility has IPv4 and IPv6 capability.

uname Displays information about the name and version of the current Operating System.

useradd Creates a new User or updates default User information.

This utility works on Linux and Solaris systems. On a FreeBSD system use the pw utility to create a new user.

userdel Deletes a User Account and its related files.

This utility works on Linux and Solaris systems. On a FreeBSD system use the pw utility to delete an User Account.

which Shows the complete path of the given command. If the command is missing in the path, a message is displayed stating that the command is missing. For example, using which telnet confirms if telnet is installed on your system and gives the path to reach it.

2

CHAPTER 2 Debugging and Logging

ZebOS has a comprehensive debugging and logging facility in various protocols and components. This chapter describes how to start/stop debugging and logging using the NSM commands. For complete information about the logging commands, refer to the ZebOS NSM Command Reference. The protocol debug commands are in corresponding Command References.

DebuggingIn the ZebOS implementation, every protocol has debug commands. Debug commands, when used with the parameters, log parameter-specific information. For example, using the debug ldp nsm command, results in the router writing all messages exchanged between LDP and NSM such as: interface, bandwidth and address updates.

On using a debug command, the router continues to generate output until the no parameter is used with the command. The debug output and system error messages are written on the virtual terminal. Use the logging commands in the configure mode to redirect the debugging output to a file or syslog. You can set the logging levels by using parameters with these commands. Refer to the NSM Command Reference for details on these commands.

Logging to stdout (terminal)

To start debugging to stdout:

1. Turn on the debug options by using the relevant debug command.

2. Run the terminal monitor command.

ZebOS> enableZebOS# configure terminalZebOS(config)# debug <protocol> (parameter)ZebOS(config)# exitZebOS# terminal monitor

Sample Output

This is a sample output of the debug rsvp events command displayed on the terminal:

ZebOS# terminal monitor

Dec 2 16:41:49 localhost RSVP[6518]: RSVP: RSVP message sent to 10.10.23.60/32 via interface eth0

Dec 2 16:41:57 localhost RSVP[6518]: RSVP: Received an RSVP message of type RSVP Reservation from 192.168.0.60 via interface eth0

Dec 2 16:41:57 localhost RSVP[6518]: RSVP: Received a RESV message from 10.10.23.60/32

Logging information to a file or syslog

To send logging information to a file:

1. Use the log file command and specify the path and file name where the information is to be logged.

3

Debugging and Logging

2. Turn on the debug option by using the relevant debug command.

ZebOS> enableZebOS# configure terminalZebOS(config)# log file <filename>ZebOS(config)# debug <protocol> (parameter)

When logging to a file, user can simultaneously log to stdout by running the terminal monitor command.

3. To log information in the system log, use the log syslog command:

ZebOS(config)# log syslog

The system log enables logging and analyzing configuration events and system error messages centrally. This helps in monitoring interface status, security alerts and CPU process overloads. It also allows real-time capturing of client debug output sessions. Use the no parameter with this command to disable system logging:

ZebOS(config)# no log syslog

Turning off debugging

To turn off debugging, use the no debug or undebug command. When a protocol is specified with the no debug or undebug commands, debugging is stopped for the specified protocol. To stop all debugging, use the all parameter with these commands.

ZebOS(config)# no debug bgp events

or

ZebOS# undebug all

To turn off logging information to a file, use the no parameter with the log file command:

ZebOS(config)# no log file (filename)

4

CHAPTER 3 Troubleshooting BGP

In this chapter the topics are arranged sequentially. Depending on the event and time when the problem occurred, select the relevant section and follow steps sequentially. If the issue is not resolved, refer to the Miscellaneous Issues chapter in this document and the FAQs available at the Customer Support Web site.

Refer to the ZebOS BGP Command Reference for details on commands used in this chapter.

No BGP Adjacency

Interface status Use the show ip interface brief command to make sure that the interface is not administratively shutdown. Remove this configuration setting with the no shutdown command, if shutdown is configured.

ZebOS# configure terminalZebOS(config)# interface eth0ZebOS(config-if)# no shutdown

Use the show interface command to make sure that the interface is up.

Neighbor configuration Make sure that the BGP configuration is correct. To establish BGP, configure a TCP session with another router using the neighbor remote-as command.

When using iBGP:

• Make sure the two routers know how to reach each other’s loopback addresses, if you have established iBGP using loopback interface. Typically, you have an IGP (say OSPF) running between the two routers. In this case, enable OSPF on the loopback interface or redistribute the loopback address into OSPF.

• Ping to each other’s loopback address to ensure mutual reachability.

When using eBGP:

• Make sure you have configured the multihop number for an eBGP neighbor that is not directly connected.

• Use the neighbor ebgp-multihop command to specify the maximum hop count to reach the neighbor.

Connectivity Make sure you can reach the neighbor using the ping A.B.C.D command.

Firewall Verify if a firewall is present. If there is a firewall, it might be configured to block TCP packets. Verify the existing firewall configurations (in Linux) by using:

ipchains -L

Flush the existing firewall configurations by using:

ipchains -F

5

Troubleshooting BGP

Useful Show Commands

show ip bgp

This command displays the current state of the BGP routing table.

When to use this command

Use this command to check whether a specific route has been installed into the BGP routing table or not and to view information about various attributes of a route, such as, nexthop, metric and AS path.

Sample Output

BGP table version is 0, local router ID is 10.100.0.77Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S stale,

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path*> 172.16.1.0/24 10.10.10.78 0 1 4 i*> 192.16.1.0 10.10.10.78 200 0 1 4 ?* 10.100.0.62 100 0 3 4 ?*>i 192.17.1.0 10.100.0.62 100 0 i

Line by Line Description

This routing table shows routes learned from both iBGP and eBGP peers.

BGP table version is 0, local router ID is 10.100.0.77

• The Table version is 0. This version number increases whenever the table changes.

• The Router ID of the local router is 10.100.0.77.

Status codes: s suppressed, d damped, h history, p stale, * valid, > best, i - internal

The possible status codes displayed at the beginning of the route entry. They display the status of the routes.

Status Code Description Comments

s suppressed Indicates that the route is suppressed and will not be advertised to the neighbors.

d damped When the penalty of a flapping route exceeds the suppress limit, the route is damped and remains in a WITHDRAWN state until its penalty decreases below the reuse limit.

h history When the penalty of a flapping route does not exceed the suppress limit, the route is not damped and BGP maintains a history of the flapping route.

S stale When the BGP neighbor, from which a route is learned, is experiencing graceful restart, the route is retained in the BGP routing table and labeled by symbol p.

* valid Indicates that the route is a valid route. When a route is not suppressed, damped or present in the history, it is a valid route.

> best The selected route to be installed in the kernel routing table.

i internal Indicates that the route is learned from an iBGP peer. An absence of this status code indicates that the route is learned from an eBGP peer.

6

Troubleshooting BGP


Origin codes are at the end of each line in the routing table and provide information about where the route has originated from.

*> 172.16.1.0/24 10.10.10.78 0 1 4 i

• The absence of status code i indicates that it is learned from an eBGP peer.

• The > indicates that this route is selected to be installed in the kernel routing table. Its network address is 172.16.1.0/24.

• The IP address of the nexthop for this route is 10.10.10.78.

• The weight parameter applies only to routes within an individual router. Since this route was learned from a peer, it has a default weight of 0. All routes generated by the local router have a weight of 32,768.

• The path attribute 1 4 indicates that the prefix advertisement passed through the ASs AS1 and AS4.

• The origin code i indicates that the prefix was added by network statement at originating AS.

*> 192.16.1.0 10.10.10.78 200 0 1 4 ?* 10.100.0.62 100 0 3 4 ?

• The same prefix is learned from two different ASs, AS1 and AS3.

• The route learned from AS1 is chosen as the best route because AS1 has a lower Router ID (10.10.10.78) than AS2 (10.100.0.62). Although the Metric or MED (MULTI_EXIT_DISC) of the route learned from AS1 is higher (200) than the route learnt from AS3 (100), this attribute is not used in the best path selection decision because MEDs are compared only if the first (neighboring) AS is the same in the two paths.

• The origin code ? indicates that the routes are learned through redistribution.

*>i192.17.1.0 10.100.0.62 100 0 i

• The route is learned through an iBGP peer as indicated by the status code i.

• The LOCAL_PREF attribute of the route, which is used only with the local AS, is set to 100 (the default value).

show ip bgp summary

This command displays the state summary of BGP neighbor connections.


Use this command to check the state of the BGP neighbor connections and to view information about the:

• Current state of BGP neighbor connections.

• Number of prefixes received from specific neighbor after BGP connection is established.

Sample Output

BGP router identifier 10.10.10.77, local AS number 100 BGP AS-PATH entries0 BGP community entries

Origin Code Description Comments

i IGP Origin of the route is an Interior Gateway Protocol.

e EGP Origin of the route is an Exterior Gateway Protocol.

? incomplete Origin not known. Typically, redistributed routes from IGP.

7

Troubleshooting BGP

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd10.10.10.78 4 20 1088 1094 0 0 0 16:22:53 2Total number of neighbors 1



• BGP router ID is 10.10.10.77 and the local router AS number is 10.

• There are no BGP AS-PATH or community entries.

10.10.10.78 4 20 1088 1094 0 0 0 16:22:53 2

• There is only one BGP neighbor available, with an IP address 10.10.10.78 and AS Number 20.

• The neighbor uses BGP version 4.

• 1088 messages are received by the local BGP.

• 1094 messages are sent by the local router since the BGP connection has been established.

• The current BGP routing table version (TblVer) is 0. When the table changes, the version will increase.

• The input queue (InQ) indicates that there are no received messages waiting in the input queue for further processing.

• The output queue (OutQ) indicates that there are no messages waiting in the output queue to be sent.

• The connection has been up for 16 hours, 22 minutes and 53 seconds.

• The local router has received two prefixes from this neighbor.

show ip bgp neighbors

This command gives detailed information about all BGP peering sessions that the local system is currently involved in. You can view information pertaining to a specific neighbor, by specifying the IP address of the neighbor with this command (show ip bgp neighbors <ipaddress>).

Sample Output (on 10.10.10.77)

ZebOS# show ip bgp neighborsBGP neighbor is 10.10.10.78, remote AS 2, local AS 1, external link BGP version 4, remote router ID 40.40.40.78 BGP state = Established, up for 00:00:56 Last read 00:00:01, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv4 Unicast: advertised and received Received 4 messages, 0 notifications, 0 in queue Sent 5 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast BGP table version 1, neighbor version 1 Index 1, Offset 0, Mask 0x2 Community attribute sent to this neighbor (both) 2 accepted prefixes

8

Troubleshooting BGP

1 announced prefixes

Connections established 1; dropped 0Local host: 10.10.10.77, Local port: 2713Foreign host: 10.10.10.78, Foreign port: 179Nexthop: 10.10.10.77Nexthop global: aaaa:bbbb::77Nexthop local: fe80::204:75ff:fe9e:c936BGP connection: non shared networkRead thread: on Write thread: off

The following is a line-by-line description of the output:

BGP neighbor is 10.10.10.78, remote AS 2, local AS 1, external link

• The IP address of the BGP neighbor is 10.10.10.78

• The AS number of the neighbor is 2.

• The AS number of the local system is 1

• The type of BGP peering is external (eBGP). If the neighbor is in the same AS, this line would display internal link.

BGP version 4, remote router ID 40.40.40.78

• The negotiated BGP version for this peering session is BGP4.

• The neighbor’s Router ID is 40.40.40.78. BGP uses the highest loopback address as the Router ID. If no loopback interface is configured, BGP uses the highest configured IP address on a system.

BGP state = Established, up for 00:00:56

• The peering session is in an Established state.The session can be in a Idle, Active, OpenSent, OpenConfirm or Established state. Only after the neighbor session is in an Established state, the exchange of routing information begins between peers. Detailed information about BGP states is in the Section 8 of the IETF RFC 1771 - A Border Gateway Protocol - 4 or the latest IETF BGP (draft version 22).

• The current peering session has been running for 56 seconds.

Last read 00:00:01, hold time is 180, keepalive interval is 60 seconds

• The time elapsed since a message was last received from this neighbor is 00:00:01.

• The maximum time that can elapse between successive messages from this neighbor is 180 seconds. If no message is received for 180 seconds, this neighbor will be declared dead.

• The time interval between successive keepalive messages is 60 seconds. Typically, the hold time value is set to three times the keepalive interval.

Neighbor capabilities: Route refresh: advertised and received (old and new) Address family IPv4 Unicast: advertised and received

• The Route Refresh and Address Family IPv4 unicast capabilities are advertised and received from the neighbor.

Received 4 messages, 0 notifications, 0 in queueSent 5 messages, 0 notifications, 0 in queue

• Received 4 messages and 0 notifications from the neighbor and sent 5 messages and 0 notifications to the neighbor.

• There are 0 messages to be or received from the neighbor.

Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 30 seconds

9

Troubleshooting BGP

• No route refresh requests have been sent or received from the neighbor.

• The minimum advertisement interval for the neighbor is 30 seconds. This means that the minimum time gap between successive route updates sent to the neighbor is 30 seconds. Generally, a jitter (of 25%) is applied to this time interval, which means that if the time between advertisements is configured as 30, successive advertisements can have a time gap of as low as 22.5 (after applying a 25% jitter to the 30 seconds, which is 7.5 seconds).

For address family: IPv4 Unicast BGP table version 1, neighbor version 1 Index 1, Offset 0, Mask 0x2 Community attribute sent to this neighbor (both) 2 accepted prefixes 1 announced prefixes

• The peers have exchanged IPv4 Unicast address family capability, which is the default. For each of the address families agreed upon, a separate table is maintained by BGP. This can be seen from the BGP table version number (1).

• One prefix (route) is advertised to and 2 received from the neighbor. Also, both the community attributes (standard and extended) have been sent.

Connections established 1; dropped 0

• The router has established a TCP connection once, and the two peers have agreed to speak BGP with each other once.

• The good connection has not failed or brought down (0).

Local host: 10.10.10.77, Local port: 2713

• The IP address and the port number on the local system used for the peering session are 10.10.10.77 and 2713.

Foreign host: 10.10.10.78, Foreign port: 179

• The IP address 10.10.10.78 and the port 179 is used for the neighbor. BGP always uses the TCP port number 179. In this example, the local system (10.10.10.77) has initiated the TCP connection, thus, the port number on the peer is 179. If the connection had been initiated by the remote peer, 179 would be a port number on the local system.

Nexthop: 10.10.10.77Nexthop global: aaaa:bbbb::77Nexthop local: fe80::204:75ff:fe9e:c936

• The IP address of the next-hop (10.10.10.77) is used to reach the neighbor. The BGP peers eBGP or iBGP do not require to be directly connected. Peering sessions can be set up across multiple hops. In this example, since the neighbors are directly connected, the IP address of the local system (10.10.10.77) is listed as the next-hop.

• The global IPv6 address of the nexthop is aaaa:bbbb::77.

• The link-local IPv6 address of the next-hop is fe80::204:75ff:fe9e:c936.

BGP connection: non shared network

• The peering session is running on a non shared network.

Read thread: on Write thread: off

• The read/write status for the socket shared with this particular peer is off. Both are generally in off state when the state of the BGP session between peers is Idle.

10

CHAPTER 4 Troubleshooting OSPF


Refer to the ZebOS OSPF Command Reference for details on the commands used in this chapter.

No OSPF Adjacency

Interface Status Use the show ip interface brief command to make sure that the interface is not administratively shutdown. Remove this configuration setting with the no shutdown command, if shutdown is configured.



OSPF Enabled on the Interface

Make sure that OSPF is enabled on the interface. To enable OSPF on a particular interface, use the network area command with a specified Area ID. Use the show ip ospf interface to confirm that OSPF is enabled for the interface.

Sample output

eth2 is up, line protocol is up Internet Address 56.168.1.7/24, Area 0.0.0.0, MTU 1500 Router ID 7.7.7.7, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 7.7.7.7, Interface Address 56.168.1.7 Backup Designated Router (ID) 8.8.8.8, Interface Address 56.168.1.8 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:05 Neighbor Count is 1, Adjacent neighbor count is 1 Crypt Sequence Number is 0 Hello received 625 sent 645, DD received 3 sent 4 LS-Req received 1 sent 1, LS-Upd received 5 sent 13 LS-Ack received 8 sent 5, Discarded 0

11

Troubleshooting OSPF

Passive Interface Make sure that interface is not configured as a passive interface using the show run command:

!router ospfpassive interface eth0!

If the interface is configured as passive (as shown above), remove this configuration setting by using this command:

no passive interface eth0

Exchange of Hello Packets Check on the interface to make sure that OSPF Hello packets are being sent and received on the interface. You can use either packet sniffer (such as, Ethereal or TCP dump) or ZebOS log messages to verify the hello packet.

To turn on ZebOS logging, type:

ZebOS# configure terminalZebOS(config)# debug ospf eventZebOS(config)# debug ospf packet hello

To display the logging message on the terminal, type:


Mismatch between Hello Parameters

It is possible that there is a mismatch between Hello parameters. Make sure that you have specified the same hello interval and dead interval values on both machines by using the show ip ospf interface command on each machine.

Mismatch between MTU sizes Run show ip ospf neighbor, if you see the neighbor but the state is not full.

Make sure that both routers have the same MTU size for the interfaces.

12



show ip ospf interface

This command displays interface information for OSPF.


Use this command when you want to check the interfaces enabled for an OSPF process. It provides important information about the OSPF parameters. Confirm that the OSPF parameters match that of the neighbors. If the intended interfaces are not shown in the OSPF information, check the configuration to make sure that the IP address of the missing interface is included.

Sample Output

eth1 is up, line protocol is up Internet Address 10.100.10.72/24, Area 0.0.0.0, MTU 1500 Router ID 100.100.100.72, Network Type BROADCAST, Cost: 10, TE Metric 0 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 100.100.100.72, Interface Address 10.100.10.72 Backup Designated Router (ID) 10.100.12.57, Interface Address 10.100.10.105 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:05 Neighbor Count is 1, Adjacent neighbor count is 1 Crypt Sequence Number is 0 Hello received 19 sent 106, DD received 4 sent 3 LS-Req received 1 sent 1, LS-Upd received 3 sent 3 LS-Ack received 2 sent 3, Discarded 0

Description of displayed fields

Internet Address The IP address and subnet mask of the interface.

Area The OSPF area to which the interface belongs.

MTU The Maximum Transmission Unit (MTU) of the interface.

Transmit Delay The transmit delay of the interface.

Priority The OSPF priority of the current interface. It is used for election of Designated Router (DR) and Backup Designated Router (BDR).

Hello The OSPF hello-interval.

Dead The OSPF dead-interval.

Wait The Hello wait-interval.

Retransmit The period, in seconds, for which the router waits between retransmissions of OSPF packets that have not been acknowledged.

Hello due in The time period for which router expects to receive hello packet.

Neighbor Count The OSPF neighbor count.

Adjacent neighbor The OSPF adjacent neighbor count.

13


show ip ospf neighbor

This command displays information about OSPF neighbors.


Use this command to check OSPF neighbors and their states. If the expected neighbors do not show the OSPF information, make sure that the OSPF parameters match the intended neighbors and they are configured in the same area.

Sample Output

ZebOS# show ip ospf neighbor

OSPF process 100:

Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL

10.100.12.57 1 Full/Backup 0:00:37 10.100.10.105 eth1:10.100.10.72 0 0 0

show ip ospf database

This command displays information about OSPF link-state database on the router.

Sample OutputQA72# show ip ospf database

OSPF Router process 100 with ID (100.100.100.72)

Router Link States (Area 0.0.0.0)

Link ID ADV Router Age Seq# CkSum Link count

Crypt Sequence Number This is used for authentication.

Hello received 19 sent 106, DD received 4 sent 3

This line shows that this router received 19 and sent 106 Hello packets. It has received 4 and sent 3 DD packets out.

LS-Req received 1 sent 1, LS-Upd received 3 sent 3

This line indicates that this router received and sent 1 LSA request. It sent and received 3 LSA updates.

LS-Ack received 2 sent 3, Discarded 0

This line indicates that this router received 2 and sent 3 LSA acknowledgements. It discarded no LSA acknowledgement.

OSPF process The OSPF process involved.

Neighbor ID The OSPF Router ID of the neighbor.

Pri The OSPF priority of the neighbor.

State The functional state of the OSPF neighbor.

Dead Time If a new Hello is not received within this duration, the neighbor is declared dead.

Address The IP address of neighbor’s interface attached to the network.

Interface The interface attached to the network on which the neighbor is located.

14


10.100.12.57 10.100.12.57 930 0x80000003 0x90de 2100.100.100.72 100.100.100.72 933 0x80000004 0x7592 2

Net Link States (Area 0.0.0.0)

Link ID ADV Router Age Seq# CkSum10.100.10.72 100.100.100.72 933 0x80000001 0x0bef

Summary Link States (Area 0.0.0.0)

Link ID ADV Router Age Seq# CkSum Route10.60.0.0 10.100.12.57 928 0x80000001 0x5108 10.60.0.0/2471.87.120.0 10.100.12.57 928 0x80000001 0xc2c5 71.87.120.0/24127.0.0.1 10.100.12.57 928 0x80000001 0x23fb 127.0.0.1/32

Description of displayed fields

Link ID

Link ID has a different meaning for different types of Link-State Advertisements.

• Link ID for Router Link States: Depends on the type of network the router connects to:

• Link ID for Net Link States: The IP address of the DR's interface.

• Link ID for Summary Link States: The IP address of the network or subnet being advertised.

ADV Router

The router ID of the router advertising the LSA.

Age

The age of the LSA.

Seq#

The sequence number of the LSA. This number increments each time a new instance of the LSA originates. This update helps other routers identify the most recent instance of the LSA.

CkSum

The Fletch checksum of the complete LSA except the Age field.

• Point to Point network Neighbor’s Router ID.

• Transit network IP address of the Designated Router’s interface.

• Stub network IP network or subnet address

• Virtual link Neighbor’s Router ID.

15


16

CHAPTER 5 Troubleshooting RIP


Refer to the ZebOS RIP Command Reference for details on commands used in this chapter.

No RIP Adjacency

Interface Status Use the show ip interface brief command to make sure that the interface is not administratively shutdown. Remove this configuration using the no shutdown command, if shutdown is configured.



RIP enabled on Interface Confirm that RIP is enabled on the interface. To enable RIP on a particular interface, use the network command. Use the show ip rip interface to make sure that RIP is enabled for the interface.

Sample Output

ZebOS# show ip rip interfacefxp0 is up, line protocol is up Routing Protocol: RIP Receive RIP packets Send RIP packets Passive interface: Disabled Split horizon: Enabled with Poisoned Reversed IP interface address:

10.15.0.60/16

Passive Interface Make sure that the interface is not configured as a passive interface using the show run command:

!router rippassive interface eth0!



17

Troubleshooting RIP

Exchange of RIP Advertisements

Make sure that RIP advertisements are being sent and received on the interface. You can use either a packet sniffer (such as, Ethereal or TCP dump) or the ZebOS log messages to verify the RIP advertisements.


ZebOS# configure terminalZebOS(config)# debug rip eventZebOS(config)# debug rip packet detail



RIP Version Mismatch One router configured as RIPv1 and the other router as RIPv2 results in no RIP adjacency.

Configure the router running RIPv2 as follows:

!interface eth1ip rip send version 1-compatibleip rip receive version 1 2!

Firewall Verify if a firewall is present. If there is a firewall, it blocks the UDP packet. You must remove the firewall if you have one. To display the existing firewall configurations, in Linux, use:

ipchains -L


ipchains -F

18

Troubleshooting RIP


show ip rip interface

This command displays information about RIP interfaces.


Use this command to verify that RIP is enabled on an interface.

Sample Output

ZebOS# show ip rip interface eth1eth1 is up, line protocol is up Routing Protocol: RIP Receive RIP packets Send RIP packets Passive interface: Disabled Split horizon: Enabled with Poisoned Reversed IP interface address: 10.10.10.10/24

Line by line description

In the above output:

eth1 is up, line protocol is up Routing Protocol: RIP

These lines denote that the interface is UP and RIP is enabled.

Receive RIP packetsSend RIP packets

These lines indicate that the interface is capable of receiving/sending both RIP version 1 and 2 packets, which is the default.

If RIP is configured to send only version 1 packets using the ip rip send version 1 command, the output displays: Send RIPv1 packets only

Passive interface: Disabled

This line denotes that the specified interface is not passive and can send and receive RIP updates.

If passive interface is configured using the passive-interface <IFNAME> command, RIP updates are received but not sent. This configuration is required when a router does not want to advertise itself but still wants to learn RIP routes.

Split horizon: Enabled with Poisoned Reversed

This line denotes that the split-horizon with poisoned reversed feature is enabled on the displayed interface (eth1). This means that routes will not be advertised on the interface from which they are learnt avoiding the problem of counting to infinity.

IP interface address: 10.10.10.10/24

These lines display the IPv4 address of the RIP enabled interface.

19

Troubleshooting RIP

show ip rip database

This command displays the different routes learnt by RIP.


Use this command to view details of all the routes learnt by RIP.

Sample Output

ZebOS# show ip rip database

Codes: R - RIP, K - Kernel, C - Connected, S - Static, O - OSPF, I - IS-IS, B - BGP

Network Next Hop Metric From If TimeR 192.1.1.0/24 10.10.10.68 2 10.10.10.68 eth1 02:47O 193.1.1.0/24 20.10.10.50 2 20.10.10.50 eth2 03:06S 196.6.6.0/24 1 eth1


In the above output:

Codes: R - RIP, K - Kernel, C - Connected, S - Static, O - OSPF, I - IS-IS, B - BGP

Refer to the show ip route command description for details about these codes.

R 192.1.1.0/24 10.10.10.68 2 10.10.10.68 eth1 02:47

This line denotes a RIP route learnt from a neighbor (10.10.10.68) through interface eth1. This route belongs to the 192.1.1.0/24 network, its metric value is 2 and its nexthop is 10.10.10.68. It will remain in the RIP routing table for 2 minutes 47 seconds.

O 193.1.1.0/24 20.10.10.50 2 20.10.10.50 eth2 03:06

This line denotes an OSPF route learnt from a neighbor (20.10.10.50) through interface eth2. This route belongs to the 193.1.1.0/24 network, its metric value is 2 and nexthop is 20.10.10.50. It will remain for 3 minutes and 6 seconds in the RIP routing table.

S 196.6.6.0/24 1 eth1

This line denotes a static route connected through interface eth1. It has a metric value of 1 to reach the network prefix.

Network Is the network prefix

Next hop Is the IPv4 address of the nexthop router.

Metric Is the metric to reach the network prefix.

From Is the IPv4 address of the neighbor's interface.

If Is the local router's interface through which the router reaches the Network prefix.

Time Is the duration for which the network prefix is stored in the RIP routing table.

20

CHAPTER 6 Troubleshooting LDP


Refer to the ZebOS LDP Command Reference for details on commands used in this chapter.

LDP Session is not UP

Selection of the Transport Address

Make sure that the transport address is selected correctly by the system. The transport address is the IP address that the LDP router advertises in its Hello message so that other routers can communicate using this IP address while setting up a TCP connection for the LDP session.

F5 Networks recommends that the loopback address be used as a transport address so that link loss on any one interface does not cause the LDP session to go down.

Use the show ldp command to verify the status of the transport address. The following is a section from the output of the show ldp command:

Router# show ldpRouter ID : 192.168.0.42LDP Version : 1Global Merge Capability : N/ALabel Advertisement Mode : Downstream UnsolicitedLabel Retention Mode : Liberal...Targeted Hello Receipt : DisabledTransport Address data : Labelspace 0 : 192.168.0.42 (in use)Import BGP routes : No

In this show output, the transport address data indicates that 192.168.0.42 is the transport address and is using 0 labelspace.

When loopback address is configured, it is automatically selected as transport address. If no loopback address is available, the LDP process selects the first available physical interface IP address.

21

Troubleshooting LDP

Reachability to transport address

When the transport address is verified to be correct on the peering systems, make sure that the transport address of the remote peer is reachable from both the routers.

To verify that the remote transport address is reachable, ping the remote transport address.

Use the show ip route command and check if there is a route to the neighbor’s transport address.

Sample Output

....S 23.23.23.0/24 [1/0] is directly connected, eth0O 48.48.48.48/32 [110/30] via 172.168.27.82, eth1, 15:44:20C 81.81.81.81/32 is directly connected, loO 82.82.82.82/32 [110/20] via 172.168.27.82, eth1, 17:45:31C 127.0.0.0/8 is directly connected, lo...

In the output above, 82.82.82.82/32 is the neighbor’s transport address and can be reached via 172.168.27.82.

If there is no route to the neighbor’s transport address:

Add a static route to the neighbor’s transport address.

Or

Use an IGP (OSPF) to reach the neighbor’s transport address.

Verify the status of LDP Use the show ldp interface command to verify the status of LDP.

QA16# show ldp interfaceInterface LDP Identifier Label-switching Merge Capabilitylo 10.30.0.16:0 Disabled N/Aeth0 10.30.0.16:0 Disabled N/Aeth1 10.30.0.16:0 Enabled Merge capableeth2 10.30.0.16:0 Enabled Merge capable

If the label-switching is disabled on an interface, use the show run command to ensure that LDP and label-switching are enabled on that interface. The configuration should show as follows:

!interface eth1 label-switching ip address 172.168.27.81/24 enable-ldp!

Targeted peers Use the show run command to ensure that targeted peer hello receipt is enabled.

If not, then run the targeted-peer-hello-receipt command to configure the LSR to respond to requests for targeted hello messages.

22

CHAPTER 7 Troubleshooting VRRP


Refer to the ZebOS VRRP Command Reference for details on commands used in this chapter. The following topology has been used for illustration.

Incorrect VRRP States

Interface running Make sure the interfaces are up and running by using the show interface command. In the following sample output interface eth1 is:

ZebOS# show interface eth1Interface eth1 Hardware is Ethernet, address is 0002.b3d4.436f index 3 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,MULTICAST> ... input errors 0, length 0, overrun 0, CRC 0, frame 0, fifo 0..

If the interface is down:

Use no shutdown command, in the interface mode, to bring up the interface.

Or

Use the ifconfig <IFNAME> up command to bring up the interface.

R1 R2

Host1 Host3Host2

MASTER BACKUP

eth2eth2

10.10.11.0/24

10.10.10.0/24

VRID = 1

Host5

eth3 eth3

23

Troubleshooting VRRP

Reachability of routers Make sure that both VRRP routers can reach each other by pinging.

ZebOS# ping 10.10.11.2PING 10.10.11.2 (10.10.11.2) 56(84) bytes of data.64 bytes from 10.10.11.2: icmp_seq=1 ttl=255 time=0.202 ms64 bytes from 10.10.11.2: icmp_seq=2 ttl=255 time=0.201 ms

If both routers cannot reach each other, check the network connections for the default Master and default Backup routers.

Advertisement Intervals on both routers

Check the advertisement interval on Master and Backup routers. The advertisement interval must be the same on both.

The default advertisement interval = 1.

Use the advertisement-interval command, in Router mode, to configure the advertisement interval.

24

CHAPTER 8 Troubleshooting PIM-SM


Refer to the ZebOS PIM-SM Command Reference for details on commands used in this chapter.

No PIM adjacency

No BSR and RP information

RP not advertised in the BSR

Interface Status 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.



PIM Enabled on the Interface Make sure that PIM-SM is enabled on the interface by using the show ip pim sparse-mode interface command.

Adjacency between ZebOS and CISCO

If you are trying to establish adjacency between ZebOS and CISCO and are not successful, use the ip pim exclude-genid command on the interface.

Some old CISCO IOS do not recognize the GenID option in the PIM-SM Hello packet and discard the packet.

Unicast Routing Configuration Check your Unicast routing configuration to make sure that you can reach BSR and RP. Use the show ip route command to display the unicast routing table.

CISCO BSR and ZebOS RP This happens when CISCO is a BSR and ZebOS is the candidate RP. In this case, you must configure the following command, in the Configure mode, on ZebOS candidate RP router.

ip pim crp-cisco-prefix

25

Troubleshooting PIM-SM

Troubleshooting Example

In this example, PIM-SM is running on all routers, ZebOS and the Check Point FireWall are running on R3. NAT is configured to translate Source address of the packets coming from eth1 to eth2 interface address. The multicast Source address is 192.168.2.2.

R2 is the RP and has a Receiver attached to it.

Problem

The Source router sends multicast data packets to R3. R3 acts as the Designated Router (DR) of the Source and sends unicast Register packets to the RP. At the Receiver end, double multicast traffic is coming out. For each multicast packet sent by Source, the Receiver is receiving two copies of the packet instead of one.

Recommended Action

1. Using your packet sniffer, observe the packets sent out by R3. Notice that both native multicast traffic and Register packets come out from eth2 and the Register packet encapsulates the multicast packet.

2. Check the ZebOS multicast routing table by running the show ip pim sparse-mode mroute command on ZebOS:

ZebOS# show ip pim sparse-mode mrouteIP Multicast Routing Table

(*,*,RP) Entries: 0(*,G) Entries: 0(S,G) Entries: 1(S,G,rpt) Entries: 1

(192.168.1.1, 224.0.1.3)RPF nbr: 0.0.0.0RPF idx: NoneSPT bit: 1Upstream State: JOINED Local .l.............................. Joined ..j............................. Asserted ................................ Outgoing .oo.............................

(192.168.1.1, 224.0.1.3, rpt)RP: 0.0.0.0

Source

ReceiverR2

R1

ZebOS

192.168.1.1

192.168.2.2192.168.1.2

eth2eth1 R3

RP

26


RPF nbr: 192.168.2.35RPF idx: eth2Upstream State: RPT NOT JOINED Pruned ................................ Outgoing ................................

3. In this output, the SPT bit for the (S,G) state is set to 1, indicating that the source tree is formed on R3 and is already delivering multicast traffic over the source tree. However, Register VIF is still on outgoing list. This indicates that ZebOS is not receiving Register-Stop from RP. This is confirmed by observing packets coming in on R3 eth2. It also explains what we observed in step 1, both native multicast traffic and encapsulated Register packets come out from eth2.

4. Using your packet sniffer, observe the packet on R3 eth2 further. All multicast packets coming out from eth2 have the same source IP address 192.168.2.2, except the Register packet, which has an IP address 192.168.1.2.

5. Run the show ip route command on R2 (RP). There is no route to reach 192.168.1.2. Because RP does not have a route to source, it failed to send the Register-stop message.

6. According to the protocol specification, the Source address of the Register packet is the DR address of the source, which is the IP address of the interface toward the source (in this case, 192.168.1.2).

Typically, the firewall does not NAT locally generated packets. When the Register packet is sent out from eth2 on R3, the Source address (in this case, eth1) is not NATed by the fireWall.

A solution for this is to change the IP source address of the Register packet. Use the ip pim register-source command to configure the source address of Register packet:

ZebOS# configure terminalZebOS(config)# ip pim register-source 192.168.2.2

After changing the source address, ZebOS sends Register packets with source address as 192.168.2.2 and receives Register-Stop packet from the RP. ZebOS stops encapsulating multicast data packet in the Register packet. The receiver now receives only one copy for each multicast data packet.

Note: When running ZebOS PIM-SM with checkpoint NAT, the Register source address must be a reachable address (visible to the external network) to be used by the RP to send corresponding Register-Stop messages in response. You might use the ip pim register-source command to change the Register packet source address.


show ip pim sparse-mode mroute

This command displays multicast routing entries.


This is a very useful PIM-SM command and should be used whenever there is a multicast routing problem.

Show OutputZebOS# show ip pim sparse-mode mroute IP Multicast Routing Table

(*,*,RP) Entries: 0

27


(*,G) Entries: 1(S,G) Entries: 1(S,G,rpt) Entries: 1FCR Entries: 1

(*, 224.0.1.3)RP: 10.10.5.4RPF nbr: 192.168.1.22RPF idx: eth1Upstream State: JOINED Local ................................ Joined ..j............................. Asserted ................................FCR:Source: 10.10.1.100 Outgoing ..o............................. KAT timer running, 208 seconds remaining Packet count 1, Byte count 0

(10.10.1.52, 224.0.1.3)RPF nbr: 192.168.1.22RPF idx: eth1SPT bit: 1Upstream State: JOINED Local ................................ Joined ..j............................. Asserted ................................ Outgoing ..o.............................

(10.10.1.52, 224.0.1.3, rpt)RP: 10.10.5.4RPF nbr: 192.168.1.22RPF idx: eth1Upstream State: NOT PRUNED Pruned ................................ Outgoing ..o.............................

Description(*,*,RP) Entries: 0(*,G) Entries: 1(S,G) Entries: 1(S,G,rpt) Entries: 1FCR Entries: 1

These entries display statistical information for the multicast group entries.

(*, 224.0.1.3)RP: 10.10.5.4RPF nbr: 192.168.1.22RPF idx: eth1Upstream State: JOINED Local ................................

28


Joined ..j............................. Asserted ................................

This is a (*,G) state entry that maintains the RP tree for group G. In this output the group G address is 224.0.1.3.

10.10.5.4 is the Rendezvous Point (RP).

192.168.1.22 is the Reverse Path Forwarding (RPF) neighbor or the upstream neighbor toward RP.

The RPF index is the upstream interface (eth1) used to reach the RPF neighbor.

The Upstream state is joined. A joined upstream indicates that the router has already joined the RP tree for this (*, G) state.

Local indicates a local member Join. In this output there is no local member.

Joined indicates a downstream router Join. In this output, a downstream router has joined the RP tree.

Asserted indicates Asserts on the interface, which could be either a Winner or a Loser.

The dots (.) indicate the VIF index in an ascending order starting from left to right from 0-31. To display the VIF index of an interface, use the show ip pim interface command.

FCR:Source: 10.10.1.100 Outgoing ..o............................. KAT timer running, 208 seconds remaining Packet count 1, Byte count 0

This entry indicates that multicast traffic is received from source 10.10.1.100 on the RP tree.

Outgoing indicates the outgoing interface for this state.

The Keep Alive Timer (KAT) is running and there are 208 seconds remaining.

The packet count indicate the number of packets forwarded on the RP tree for the source 10.10.1.100.

(10.10.1.52, 224.0.1.3)RPF nbr: 192.168.1.22RPF idx: eth1SPT bit: 1Upstream State: JOINED Local ................................ Joined ..j............................. Asserted ................................ Outgoing ..o.............................

This is a (S,G) state entry that maintains a source-specific tree for source S and group G. In this output the source is 10.10.1.52 and the group is 224.0.1.3.

SPT bit 1 indicates that forwarding is taking place on the (S,G) Shortest Path Tree.

The other fields have already been described above.

(10.10.1.52, 224.0.1.3, rpt)RP: 10.10.5.4RPF nbr: 192.168.1.22RPF idx: eth1Upstream State: NOT PRUNED Pruned ................................ Outgoing ..o.............................

29


This is a (S,G,rpt) entry. It indicates the source-specific multicast information on the RP tree for group G. For example, if multicast traffic is being received on the source-specific tree, it is normally pruned off the RP tree. In this output, 10.10.1.52 is the source and 224.0.1.3 is the group.

The Upstream State “Not Pruned” indicates that the router does not prune itself for source 10.10.1.52 from RP tree.

Pruned displays an interface that is pruned from the RP tree. This output shows that there are no interfaces pruned from the RP tree.

Outgoing indicates interfaces on the RP tree. This output shows one interface on the RP tree for the source 10.10.1.52.

show ip pim sparse-mode interface

Use this command to display interface information for a PIM-SM enabled interface.

Show Output

ZebOS# show ip pim sparse-mode interface

Address Interface VIFindex Ver/ Nbr DR DR Mode Count Prior

10.10.3.39 eth1 0 v2/S 1 1 10.10.3.39

Fields Description

Address The IP address of the interface is 10.10.3.39

Interface Name of the interface is eth1.

VIF index Virtual Interface (VIF) index.

Ver The PIM-SM version 2.

Mode The PIM-SM Sparse mode.

Nbr Count The number of neighbors. Here it is 1.

DR Prior The priority of the Designated Router. Here it is 1.

DR The IP address of the Designated Router 10.10.3.39.

30

CHAPTER 9 Troubleshooting BGP4+


Refer to the ZebOS BGP Command Reference for details on commands used in this chapter.

No BGP Adjacency

Interface status Use the show ipv6 interface brief command to make sure that the interface is not administratively shutdown. Remove this configuration setting with the no shutdown command, if shutdown is configured.



Neighbor configuration Make sure that the configuration is correct. To establish BGP, configure a TCP session with another router using the neighbor remote-as command. Refer to the ZebOS BGP Command Reference for details on this command.

When using iBGP:

• Make sure the two routers know how to reach each other’s loopback address, if you have established iBGP using loopback interface. Typically, you have IGP (say OSPF) running between the two routers. In this case, enable OSPF on the loopback interface or redistribute the loopback address into OSPF.

• Ping to each other’s loopback address to ensure mutual reachability.

When using eBGP:

• Make sure you have configured the multihop number for an eBGP neighbor that is not directly connected.

• Use the neighbor ebgp-multihop command to specify the maximum hop count to reach the neighbor.

Connectivity Make sure you can ping to the neighbor using the ping A.B.C.D command.

Firewall Verify if a firewall is present. If there is a firewall, it might be configured to block TCP packets. Verify the existing firewall configurations (in Linux) by using:

ipchains -L


ipchains -F

31

Troubleshooting BGP4+


show bgp ipv6

This command displays the current state of the BGP routing table.


Use this command to check whether the specific route has been installed into the BGP routing table or not.

Use this command to view information about:

• Routes installed in the BGP routing table.

• Various attributes of the route, such as nexthop, metric and AS path.

Sample OutputBGP table version is 0, local router ID is 10.100.0.77Status codes: s suppressed, d damped, h history, * valid, > best, i - internal S stale, Origin codes: i - IGP, e - EGP, ? - incomplete

Network Metric LocPrf Weight Path*> 2001:58::/32 0 20 ? fe80::202:b3ff:fec8:9fdb*> 2002:58::/32 0 20 i fe80::202:b3ff:fec8:9fdb*>i2003:58::/32 100 0 i fe80::208:a1ff:fe16:797d

LIne by line Description

This routing table shows routes learned from both iBGP and eBGP.

Status codes: s suppressed, d damped, h history, p stale, * valid, > best, i - internal

This section of output displays the possible status codes displayed as the first character of the route entry.

Status Code Description Comments

s suppressed Indicates that the route is suppressed and will no be advertised to neighbors.

d damped When the penalty of a flapping route exceeds the suppress limit, the route is damped and remains in a WITHDRAWN state until its penalty decreases below the reuse limit.

h history When the penalty of a flapping route does not exceed the suppress limit, the route is not damped and BGP maintains a history of the flapping route.

S stale When the BGP neighbor, from which a route is learned, is experiencing graceful restart, the route is retained in the BGP routing table and labeled by symbol p.

* valid Indicates that the route is a valid route. When a route is not suppressed, damped or present in the history, it is a valid route.

32



Origin codes are at the end of each line in the routing table and provide information about where the route has originated from.

*> 2002:58::/32 fe80::202:b3ff:fec8:9fdb 0 20 i

• This route entry shows that this route is learned from eBGP.

• The origin code i indicates that the prefix is added by the network statement at originating AS.

• The path attribute 20 indicates that the prefix advertisement originated from AS20.

• The administrative weight parameter applies only to routes within an individual router.

• Since this route was learned from a peer, it has a default weight of 0. All routes generated by the local router have a weight of 32,768.

*> 2001:58::/32 fe80::202:b3ff:fec8:9fdb 0 20 ?

This route entry shows that the prefix is learnt from eBGP.The origin code i indicates that the prefix is added by network statement at originating AS.The path attribute 20 indicates that the route advertisement originated from AS20.The administrative weight parameter applies only to routes within an individual router. Since this route was learned from a peer, it has a default weight of 0. All routes generated by the local router have a weight of 32,768.The origin code ? indicates that the route is learnt through redistribution.

*>i2003:58::/32 fe80::208:a1ff:fe16:797d 100 0 i

The status code i in this route entry indicates that the route is learnt through iBGP. The Local Preference attribute of the route, which is used only with the local AS, is set to 100 (the default value).

show bgp ipv6 summary

This command displays the state summary of BGP neighbor connections.


Use this command to check the state of BGP neighbor connections and to view information about:

• Current state of BGP neighbor connections

• Number of prefixes received from specific neighbor after BGP connection was established

Sample Output


Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcdfe80::202:b3ff:fec8:9fdb

> best The selected route to be installed in the kernel routing table.

i internal Indicates that the prefix is learned from an iBGP peer.

Origin Code Description Comments

i IGP Origin of the route is an Interior Gateway Protocol.

e EGP Origin of the route is an Exterior Gateway Protocol.

? incomplete Origin not known. Typically, redistributed routes from IGP.

33


4 20 24 24 0 0 0 00:20:34 2fe80::208:a1ff:fe16:797d 4 10 19 22 0 0 0 00:17:13 1

Total number of neighbors 2

Description

• This output shows that currently there are two BGP neighbors available with the link-local IPv6 address fe80::202:b3ff:fec8:9fdb and fe80::208:a1ff:fe16:797d respectively.

• The version of BGP used by these neighbors is BGP4 and AS numbers are 20 and 10. 24 and 19 messages are received from these two neighbors and 24 or 22 messages are sent to them.

• The current BGP routing table version (TblVer) is 0, with any change in the table the version will increase.

• The input queue (InQ) indicates the number of received messages waiting in the input queue for further processing and output queue (OutQ) indicates the number of messages waiting in the output queue to be sent.

• The connection with the first neighbor is up for 20 minutes and 34 seconds and the connection with the second neighbor is up for 17 minutes and 13 seconds.

• Two prefixes are received from the first neighbor and one from the second.

34

CHAPTER 10 Troubleshooting OSPFv3


Refer to the ZebOS OSPF Command Reference for details on the commands used in this chapter.

No OSPF Adjacency

Interface Status Use the show ipv6 interface brief command to make sure that the interface is not administratively shutdown. Remove this configuration setting with the no shutdown command, if shutdown is configured.



OSPF Enabled on the Interface

Make sure that OSPF is enabled on the interface. To enable OSPF on a particular interface, use the ipv6 router ospf area command with a specified Area ID. Use the show ipv6 ospf interface to confirm that OSPF is enabled for the interface.

Sample output

ZebOS# show ipv6 ospf interface eth0 is up, line protocol is up Interface ID 3, Instance ID 0, Area 0.0.0.0 IPv6 Link-Local Address fe80::248:54ff:fec0:f32d/10 Router ID 1.2.3.4, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State Backup, Priority 1 Designated Router (ID) 5.6.7.8 Interface Address fe80::203:47ff:fe4c:776e Backup Designated Router (ID) 1.2.3.4 Interface Address fe80::248:54ff:fec0:f32d Timer interval configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:01 Neighbor Count is 1, Adjacent neighbor count is 1lo is up, line protocol is up OSPFv3 not enabled on this interfacesit0 is down, line protocol is down OSPFv3 not enabled on this interface

35

Troubleshooting OSPFv3


!router ipv6 ospfpassive interface eth0!



Exchange of Hello Packets Check on the interface to make sure that OSPF Hello packets are being sent and received on the interface. You can use either packet sniffer (such as, Ethereal or TCP dump) or ZebOS log messages to verify the Hello packets.


ZebOS# configure terminalZebOS(config)# debug ipv6 ospf eventZebOS(config)# debug ipv6 ospf packet hello



Mismatch between Hello Parameters

It is possible that there is a mismatch between Hello parameters. Make sure that you have specified the same hello interval and dead interval values on both machines by using the show ipv6 ospf interface command.

Mismatch between MTU sizes Run the show ipv6 ospf neighbor command; if you see the neighbor but the state is not full, make sure that both routers have the same MTU size for the interfaces.


ipchains -L


ipchains -F

36



show ipv6 ospf database link [adv-router]

This command displays the information about the Link LSAs (Link State Advertisements).


Use this command to view information about the:

• Link Local address of a router

• IPv6 prefixes associated with the link of the router

Sample OutputZebOS# show ipv6 ospf database link adv-router 10.70.0.58

OSPFv3 Router with ID (10.70.0.58) (Process 100)

Link-LSA (Interface eth1)

LS age: 492 LS Type: Link-LSA Link State ID: 0.0.0.3 Advertising Router: 10.70.0.58 LS Seq Number: 0x80000001 Checksum: 0xC2D6 Length: 68 Priority: 1 Options: 0x000013 (-|R|-|-|E|V6) Link-Local Address: fe80::204:75ff:feaa:fedb Number of Prefixes: 2

Prefix: 5f00:1:2:10::/64 Prefix Options: 0 (-|-|-|-)

Line by line descriptionOSPFv3 Router with ID (10.70.0.58) (Process 100)

The router ID and OSPFv3 process tag of the local router.

Link-LSA (Interface eth1)

Interface name (eth1) of the router associated with this Link-LSA.

Ls age: 492

The length of time in seconds since the LSA was originated.

LS Type: Link-LSA

The type of LSA (in this case Link LSA)

Link State ID: 0.0.0.3

Interface ID of the originating router.

37


Advertising router:10.70.0.58

The router ID of a router advertising this link LSA.

LS Seq Number"0x80000001

Successive instance of an LSA.

Checksum:0xC2D6

LSA header checksum (excluding the LS age field).

Length: 68

The length in bytes of the LSA (including 20 byte header).

Priority: 1

The router priority of the interface attaching the originating router of the link.

Options: 0x000013 (-|R|-|-|E|V6)

The set of option bits that the router would like set in the Network-LSA that will be originated for the link. Options field is 24 bit field.

R-bit indicates whether the router is an active router.If this bit is cleared, routes which transit the advertising node cannot be computed.

E-bit indicates that AS-External-LSAs are flooded.

V6-bit indicates that router/link should be included in routing calculations.

Link-Local Address: fe80::204:75ff:feaa:fedb

The originating router's (here 10.70.0.58) Link -Local interface address (fe80::204:75ff:feaa:fedb).

Number of Prefixes: 2

The number of ipv6 prefixes contained in this LSA. There are two ipv6 prefixes advertised in this link LSA (5f00:1:2:10::/64 and 6f00:1:2:10::/64)

Prefix: 5f00:1:2:10::/64

The global ipv6 prefix (5f00:1:2:10::/64) associated with this link.

Prefix Options: 0 (-|-|-|-)

Each prefix is advertised along with an 8-bit capabilities field.They serve as input to the various routing calculations allowing, for example, certain prefixes to be ignored in some cases or to be marked as not re-advertisable in others.

38


show ipv6 ospf database intra-prefix [adv-router]

This command displays the information about Intra-Area-Prefix-LSA.


Use this command to list information about a ipv6 prefixes associated with the router itself, transit network or attached stub network segment.

Note: The above information for OSPFv2 can be viewed with Router LSA and Network LSA. However, for ipv6 all addressing information has been removed from router-LSA and network-LSAs, leading to the introduction of Intra-Area-Prefix-LSA. On Transit network Intra-Area-Prefix-LSA serves the same purpose as Network LSA and on point-to-point or point-to-multipoint network serves the same purpose as router LSA)

Sample outputZebOS# show ipv6 ospf database intra-prefix adv-router 10.70.0.58


Intra-Area-Prefix-LSA (Area 0.0.0.0)

LS age: 1435 LS Type: Intra-Area-Prefix-LSA Link State ID: 0.0.0.2 Advertising Router: 10.70.0.58 LS Seq Number: 0x80000001 Checksum: 0x1B4E Length: 56 Number of Prefixes: 2 Referenced LS Type: 0x2002 Referenced Link State ID: 0.0.0.3 Referenced Advertising Router: 10.70.0.58

Prefix: 5f00:1:2:10::/64 Prefix Options: 0 (-|-|-|-) Metric: 0

Prefix: 6f00:1:2:10::/64 Prefix Options: 0 (-|-|-|-) Metric: 0



The router ID and OSPFv3 process tag for the router on which this command was used.

Intra-Area-Prefix-LSA (Area 0.0.0.0)

Intra-Area-Prefix-LSA has area flooding scope. This LSA belongs to Area 0.0.0.0.

LS age: 1435

The time in seconds since the LSA was originated.

LS Type: Intra-Area-Prefix-LSA

The type of LSA (here Intra-Area-Prefix-LSA).

39


Link State ID: 0.0.0.2

Link State ID in Intra-Area-LSA. This ID is an identity for multiple Intra-Area-Prefix-LSAs originated by the same router.

Advertising router:10.70.0.58

The Router ID of the router advertising this link LSA. On a Transit network it is always the Designated Router’s ID.

LS Seq Number"0x80000001

Successive instance of an LSA.

Checksum:0x1B4E

LSA header checksum (excluding the LS age field).

Length: 56

The length of the LSA in bytes (includes the 20 byte header).

Number of Prefixes: 2

The number of ipv6 prefixes contained in this LSA. There are two ipv6 prefixes advertised in this link LSA (5f00:1:2:10::/64 and 6f00:1:2:10::/64).

Referenced LS Type: 0x2002

Identifies the Router-LSA or Network-LSA with which the ipv6 prefixes are associated. When the Referenced LS Type is 0x2001 the prefixes are associated with Router-LSA and when the Referenced LS Type is 0x2002 the prefixes are associated with Network-LSA.

Referenced Link State ID: 0.0.0.3

When the Referenced LS Type is 0x2001, this field is 0 and when the Referenced LS Type is 0x2002, this field is the Interface ID of the link's DR (Designated Router).

Referenced Advertising Router: 10.70.0.58

When the Referenced LS Type is 0x2001, this field is the ID of the originating Router and when the Referenced LS Type is 0x2002 this field is the ID of the Designated Router (DR).

Prefix: 5f00:1:2:10::/64

The global ipv6 prefix (5f00:1:2:10::/64) associated with the router (when the Referenced LS Type is 0x2001) or transit link (when the Referenced LS Type is 0x2002).

Prefix Options: 0 (-|-|-|-)

Each prefix is advertised along with an 8-bit capabilities field.These prefixes options provide information for different routing calculations, for example, some prefixes are marked to be ignored or marked not to be readvertised.

Metric: 0

The cost of this prefix.

40

CHAPTER 11 Troubleshooting RIPng


Refer to the ZebOS RIP Command Reference for details on commands used in this chapter.

No RIPng Adjacency

Interface Status Use the show ipv6 interface brief command to make sure that the interface is not administratively shutdown. Remove this configuration by no shutdown command, if shutdown is configured.



RIPng enabled on Interface Make sure that RIPng is enabled on the interface. To enable RIPng on a particular interface, use the ipv6 router rip command. Use the show ipv6 rip interface to confirm that RIP is enabled for the interface.

Sample Output

ZebOS# show ipv6 rip interface eth1eth1 is up, line protocol is up Routing Protocol: RIPng Passive interface: Disabled Split horizon: Enabled with Poisoned Reversed IPv6 interface address: 3ffe:1::10/64 fe80::204:76ff:fec8:28cc/10


!router ipv6 rippassive interface eth0!



41

Troubleshooting RIPng

Exchange of RIPng Advertisements

Check on the interface to make sure that RIPng advertisements are being sent and received on the interface. You can use either a packet sniffer (such as, Ethereal or TCP dump) or the ZebOS log messages to verify the RIPng advertisements.


ZebOS# configure terminalZebOS(config)# debug ipv6 rip eventZebOS(config)# debug ipv6 rip packet detail




ipchains -L


ipchains -F

42

CHAPTER 12 Route Selection in NSM

Understanding the NSM route selection process helps in analyzing and troubleshooting route-related problems. This chapter describes the route selection process in NSM. It also describes relevant show commands and their outputs.

For every known prefix, NSM maintains a route node entry in its route table. NSM populates this table upon receiving routes from clients (BGP, OSPF, RIP), from static routes configured using CLI, from the kernel's Forwarding Information Base (FIB) or connected routes derived from interface information.

When multiple routes are available for the same prefix, NSM uses an internal route selection mechanism to select routes to be added to the FIB. The primary factor for route selection is the "Administrative Distance" of the protocol. The following table lists the default administrative distances of protocols.

ProtocolsAdministrative

Distance Preference

Connected - 1 (highest)

Kernel - 2

Static 1 3

eBGP 20 4

OSPF 110 5

ISIS 115 6

RIP 120 7

iBGP 200 8 (lowest)

43

Route Selection in NSM

How Does NSM Add RoutesNSM prefers routes learned from protocols with a loweradministrative distance over routes learned from proto-cols with a higher administrative distance.

For example, the following route entries display that the Static Routes (administrative distance 1) is preferred over the OSPF Route (administrative distance 110):

S *> 10.10.34.0/24 [1/0] via 10.10.31.16, eth2

O 10.10.34.0/24 [110/31] via 10.10.31.16, eth2, 00:21:19

Note: The administrative distance of routing protocols can be configured using the distance command.

This flowchart displays how a route is selected in NSM.

Routing protocols use different metrics to calculate the best path for a destination. The best path is sent to NSM. However, when two paths have an equal cost/metric and Equal Cost Multipath (ECMP) is enabled on a system, NSM might receive two paths from the same protocol.

NSM receives a route from a

routing protocol

Adds route to its database

Checks if a route for this prefix

already exists in the FIB

Checks if the administrative

distance of this new route is lower than the existing

route’s.

Deletes the old route from the FIB

Adds this new route to the FIB

End of the Route Selection Process

in NSM

Leaves the FIB unchanged

Yes

No

No

Yes

44


How does NSM Delete RoutesWhen NSM receives a route delete request from a routing protocol, NSM deletes the specified route from its database. Then it checks if the specified route is in the FIB. If the route is in the FIB, NSM deletes it from the FIB and checks if another route is available in its database for the same prefix. If there is another route in the database, NSM installs this route in the FIB. When multiple such routes exist, NSM runs the route selection mechanism to choose the best route to be added to the FIB.

NSM receives a route delete

request from a routing protocol

Deletes route from NSM database

Checks if specified route is in the FIB

Deletes route from the FIB

Sends best route to FIB

End of the Route Selection Process

in NSM

No

No

Other route/ routes available in the

database

Yes

Yes

Runs route selection mechanism if multiple

routes available.

45


Show CommandsThe show ip route and the show ip route database commands are important tools for troubleshooting. Use these commands in conjunction to get complete information about routes received and selected by NSM. Use the show ip route database command to list all the routes received by NSM and use the show ip route command to list only routes that are selected by NSM and installed in the FIB.

show ip route

The show ip route command displays the contents of the IP routing table maintained by NSM. Routes displayed in this table are also added to the kernel routing table.


Use this command to view only the routing entries selected by NSM.

Sample Output

ZebOS# show ip routeCodes: K - kernel, C - connected, S - static, R - RIP, B - BGP 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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate defaultGateway of last resort is 10.30.0.11 to network 0.0.0.0

K* 0.0.0.0/0 via 10.30.0.11, eth0O 9.9.9.9/32 [110/31] via 10.10.31.16, eth2, 00:18:56K 10.10.0.0/24 via 10.30.0.11, eth0C 10.10.31.0/24 is directly connected, eth2S 10.10.34.0/24 [1/0] via 10.10.31.16, eth2O 10.10.37.0/24 [110/11] via 10.10.31.16, eth2, 00:20:54C 10.30.0.0/24 is directly connected, eth0S 11.22.11.0/24 [1/0] via 10.10.31.16, eth2O E2 14.5.1.0/24 [110/20] via 10.10.31.16, eth2, 00:18:56S 16.16.16.16/32 [1/0] via 10.10.31.16, eth2O 17.17.17.17/32 [110/31] via 10.10.31.16, eth2, 00:20:54C 45.45.45.45/32 is directly connected, loO 55.55.55.55/32 [110/21] via 10.10.31.16, eth2, 00:20:54C 127.0.0.0/8 is directly connected, lo


Each entry in this table has a code preceding it, indicating the source of the routing entry. For example, O indicates OSPF as the origin of the route and K indicates that the route has been learned from the Kernel (most operating systems add some implicitly learnt routes when the device is started up). The first few lines of the output list the possible codes that may be seen with the route entries.

Typically, route entries are composed of the following elements:

• Code

• network/ host ip address

46


• outgoing interface name

• administrative distance and metric

• nexthop ip address

• time since route entry was added

• a second Label indicating the sub type of the route.

To avoid repetition, only selected route entries comprised of different elements are described here:

O 10.10.37.0/24 [110/11] via 10.10.31.16, eth2, 00:20:54

This route entry denotes:

• This route in the network 10.10.37.0/24 was added by OSPF.

• This route has an administrative distance of 110 and metric/cost of 11.

• This route is reachable via nexthop 10.10.31.16.

• The outgoing local interface for this route is eth2.

• This route was added 20 minutes and 54 seconds ago.

C 10.10.31.0/24 is directly connected, eth2


• Route entries for network 10.10.31.0/24 are derived from the IP address of local interface eth2.

• These routes are marked as Connected routes (C) and always preferred over routes for the same network learned from other routing protocols.

• Routes for connected networks always exist in the kernel routing table but as an exception are not marked as kernel routes because NSM always calculates entries for these routes upon learning interface information from the kernel.

K 10.10.0.0/24 via 10.30.0.11, eth0


• This route in the network 10.10.0.0/24 was learned from the kernel routing table (route was statically added using kernel commands).


• The outgoing local interface for this route is eth0.

Note: The static routes added using kernel commands and static routes added using NSM commands are different. The kernel static routes are not redistributed when the redistribute static command is used in a protocol. However, the kernel static routes can be redistributed using the redistribute kernel command.

O E2 14.5.1.0/24 [110/20] via 10.10.31.16, eth2, 00:18:56


• This route is the same as the other OSPF route explained above; the only difference is that it is a Type 2 External OSPF route.

K* 0.0.0.0/0 via 10.30.0.11, eth0


• This is a default route and was learned from the kernel (route was statically added using kernel commands).


• The local interface for this route is eth0.

47


show ip route database

The show ip route database command displays all routing entries known by NSM. When multiple entries are available for the same prefix, NSM uses an internal route selection mechanism based on protocol administrative distance and metric values to choose the best route. All best routes are entered into the FIB and can be viewed using the show ip route command.


Use this command to view all the routing entries known by NSM.

Sample Output

ZebOS# show ip route databaseCodes: K - kernel, C - connected, S - static, R - RIP, B - BGP 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, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area > - selected route, * - FIB route, p - stale info

K *> 0.0.0.0/0 via 10.30.0.11, eth0O *> 9.9.9.9/32 [110/31] via 10.10.31.16, eth2, 00:19:21K *> 10.10.0.0/24 via 10.30.0.11, eth0O 10.10.31.0/24 [110/1] is directly connected, eth2, 00:28:20C *> 10.10.31.0/24 is directly connected, eth2S *> 10.10.34.0/24 [1/0] via 10.10.31.16, eth2O 10.10.34.0/24 [110/31] via 10.10.31.16, eth2, 00:21:19O *> 10.10.37.0/24 [110/11] via 10.10.31.16, eth2, 00:21:19K * 10.30.0.0/24 is directly connected, eth0C *> 10.30.0.0/24 is directly connected, eth0S *> 11.22.11.0/24 [1/0] via 10.10.31.16, eth2O E2 *> 14.5.1.0/24 [110/20] via 10.10.31.16, eth2, 00:19:21O 16.16.16.16/32 [110/11] via 10.10.31.16, eth2, 00:21:19S *> 16.16.16.16/32 [1/0] via 10.10.31.16, eth2O *> 17.17.17.17/32 [110/31] via 10.10.31.16, eth2, 00:21:19C *> 45.45.45.45/32 is directly connected, loO *> 55.55.55.55/32 [110/21] via 10.10.31.16, eth2, 00:21:19K * 127.0.0.0/8 is directly connected, loC *> 127.0.0.0/8 is directly connected, lo

Line-by-line description

The routes added to the FIB are marked with a *. When multiple routes are available for the same prefix, the best route is indicated with the > symbol. All unselected routes have neither the * nor the > symbol.

In the case of Connected routes, 2 entries exist in the route database; one learned from the kernel and the other derived from interface information.

K * 10.30.0.0/24 is directly connected, eth0

C *> 10.30.0.0/24 is directly connected, eth0

These route entries denote:

• Both these routes are in the same network 10.30.0.0/24.

48


• The first route has originated from the kernel. The * indicates that it has been added to the FIB (Forwarding Information Base).

• The second route is derived from the IP address of local interface eth0. It is marked as a Connected route (C). Since a Connected route has the lowest administrative distance, it is the selected route.

S *> 10.10.34.0/24 [1/0] via 10.10.31.16, eth2O 10.10.34.0/24 [110/31] via 10.10.31.16, eth2, 00:21:19

These route entries denote:

• The same prefix was learned from OSPF and from static route configuration.

• Since Static routes are preferred over OSPF routes, the static route is selected and installed in the FIB.

Note: When the static route becomes unavailable, NSM automatically selects the OSPF route and installs it in the FIB.

49


50

CHAPTER 13 Miscellaneous Issues

Kernel does not notify the NSM about updating the MTU/metric

Live MTU/metric updates are sent by NSM to the protocols on Linux and all flavors of BSDs. For Solaris, the kernel does not notify the NSM about updating the MTU/metric. To trigger this information from NSM to protocols, you need to administratively bring the interface DOWN, modify the MTU/metric and then bring the interface UP. This sends the new MTU/metric update to the protocols.

OSPF adjacency lost (System Clock)

When changing the system clock (moving it backward or forward) the OSPF daemon on Solaris loses adjacency. OSPF adjacency is lost and stuck in "Init" state. This is a known Solaris issue.

When changing the system time using any mechanism, users need to shutdown the system and bring it up. So when changing system time on Solaris, shutdown the system and restart ZebOS protocols.

Remote Devices are unreachable

If you cannot reach remote devices when restarting NSM, make sure that there is at least one static IP address configured from the primary interface of the OS. Failure to do so can result in the device becoming unreachable from the outside. The connectivity established through ZebOS is lost when ZebOS is killed and the device requires manual intervention.

To configure a static address from the primary interface, use the ifconfig command or edit a file in the network-scripts:

1. Edit file ifcfg-eth<x> in /etc/sysconfig/network-scripts with this minimum configuration:

DEVICE = eth<x> ONBOOT = yes PADDR = 10.10.10.222 NETMASK = 255.255.255.0 BROADCAST = 10.10.10.255

2. Make sure /etc/rc.d/init.d/network does exist to configure a network interface with a static IP address at boot time.

51

Miscellaneous Issues

52

Index

A

administrative distance 44show ipv6 ospf database intra-prefix 39show ipv6 ospf database link 37

B

BGP AS-PATH entries 8bgp issues 5BGP state 9BGP table version 6bgp4+ issues 31

C

Cannot reach host when Master is down 23cannot reach remote device 51changed system clock 51community entries 8configure multihop number for an eBGP neighbor 5, 31configuring PIM-SM with NAT 27

D

damped route 6description of show ip bgp neighbors command 8description of show ip bgp summary command 7double multicast traffic comes out at receiver end 26DR Prior 30

E

eBGP routes 43enable ospf 11enable ospfv3 35Ethereal 18, 42

F

firewall present 5

H

history 6how NSM selects routes 43how to configure static routes on primary interface 51how to debug routing protocols 3how to enable ospf on the interface 11

how to enable ospfv3 on the interface 35how to get details on unix commands 1how to log 3how to log information to a file 3how to log information to system log 3, 4how to log into stdout 3how to make sure the neighbor is reachable 5how to see the debugging output 3how to stop debugging 4how to turn off debugging 4how to use log file command 3

I

iBGP routes 43id 1ifconfig 1Incorrect VRRP States 23interface is administratively shutdown 17, 41interface is shutdown 11, 35interface is up but no ospf adjacency 11, 35ipconfig command 51ISIS routes 43issues when running BGP 5issues when running BGP4+ 31issues when running LDP 21issues when running rip 17issues when running ripng 41issues when running VRRP 23

K

kernel routes 43

L

ldp issues 21list all routes received by NSM 44list only routes selected by NSM 44log file 3logging to stdout 3logging to terminal 3ls 1

M

man 1man command 1metrics 44

Index - 1

Index

N

Nbr Count 30Neighbor capabilities 9netstat 1no bgp adjacency 5, 31No BSR and RP information 25No OSPF Adjacency 35no ospf adjacency 11no ospfv3 adjacency 35No PIM adjacency 25no rip adjacency 17no ripng adjacency 41no shutdown command 17, 41

O

Origin codes 7ospf daemon looses adjacency after changing system

clock 51OSPF issue 11ospf issue 11OSPF routes 43OSPFv3 issue 35ospfv3 issue 35

P

PIM-SM troubleshooting example 26ping 1ping6 2preference according to admin distance 43

R

Reachability to transport address 22receiving neighbor’s hello messages but no ospf

adjacency 12receiving neighbor’s hello messages but no ospfv3

adjacency 36Register-Stop 27remote devices unreachable 51rip enabled but no adjacency 18, 42RIP routes 43Route refresh request 9Route selection in NSM 43RP not advertised in the BSR 25

S

Selection of the Transport Address 21show ip bgp command 6show ip bgp neighbors 8show ip bgp summary 7show ip mroute command 27show ip ospf database command 14show ip ospf interface command 11, 13, 35show ip ospf neighbor command 14show ip pim interface command 30

show ip rip database command 20show ip rip interface command 19show ip route command 44show ip route database command 44show ipv6 bgp command 32show ipv6 bgp summary command 33show run command 17, 41ssh 2stale route 6static routes 43Status codes 6su command 2suppressed route 6system clock 51System Commands and Utilities

ls 1su 2

T

Targeted peers 22TCP dump 18, 42TCP packet blocked 5telnet 2traceroute 2traceroute6 2Transmit Delay 13troubleshooting bgp 5troubleshooting bgp4+ 31troubleshooting ldp 21Troubleshooting OSPF 11troubleshooting OSPF 11Troubleshooting OSPFv3 35troubleshooting OSPFv3 35Troubleshooting PIM-SM 25troubleshooting rip 17troubleshooting ripng 41troubleshooting vrrp 23turn off debugging 4

U

uname 2undebug 4Unix System Commands and Utilities

id 1ifconfig 1man 1netstat 1ping 1ping6 2ssh 2telnet 2traceroute 2traceroute6 2uname 2useradd 2userdel 2which 2

Index - 2

Index

Unix system utitlities 1useradd 2userdel 2

V

valid route 6Verify the status of LDP 22

VIF index 30vrrp issues 23

W

what does show ip bgp output mean 6which 2

Index - 3

Index

Index - 4

BIG-IP Advanced Routing™ · CHAPTER 5 Troubleshooting RIP ... This guide is intended for all...

Documents

Transcript of BIG-IP Advanced Routing™ · CHAPTER 5 Troubleshooting RIP ... This guide is intended for all...