Example 813 Debugging BGP Updates

Alki#debug ip bgp updates

BGP updates debugging is on Alki#clear ip bgp *

01:33:30: %BGP-5-ADJCHANGE: neighbor 192.168.32.2 Down User reset Comment: The session was reset upon user request

01:34:12: %BGP-5-ADJCHANGE: neighbor 192.168.32.2 Up Comment: The BGP session with peer 192.168.32.2 is back up

01:34:12: BGP(0): 192.168.32.2 rcvd UPDATE w/ attr: nexthop 192.168.32.2, origin i, metric 0, path 600 Comment: The router received an update from peer 192.168.32.2 containing the BGPat Comment: NEXTHOP 192.168.32.2 Comment: ORIGIN: i Comment: MED: 0 Comment: AS_PATH 600

01:34:12: BGP(0): 192.168.32.2 rcvd 10.1.1.0/24 01:34:12: BGP(0): 192.168.32.2 rcvd 10.1.2.0/24

Comment: The update contained NLRI paths 10.1.1.0/24 and 10.1.2.0/24 01:34:12: BGP(0): Revise route installing 10.1.1.0/24 -> 192.168.32.2 to main IP table

01:34:12: BGP(0): Revise route installing 10.1.2.0/24 -> 192.168.32.2 to main IP table

Comment: BGP found the routes to networks 10.1.1.0/24 and 10.1.2.0/24 valid best paths and is installing them in the main IP routing table

01:34:12: BGP(0): nettable_walker 172.16.14.0/24 route sourced locally

01:34:12: BGP(0): nettable_walker 172.16.20.0/24 route sourced locally

Comment: The BGP Scanner (nettable_walker) found networks 172.16.14.0/24 and 172.1

*4 sourced locally

01:34:12: BGP(0): 192.168.32.2 computing updates, afi 0, neighbor version 0, table version 5, starting at 0.0.0.0

01:34:12: BGP(0): 192.168.32.2 send UPDATE (format) 172.16.14.0/24, next 192.168.32.1, metric 0, path

Comment: The router is sending an UPDATE message to 192.168.32.2 containing the route 172.16.14.0/24 with the attributes of NEXT_HOP: 192.168.32.2, MED: 0

01:34:12: BGP(0): 192.168.32.2 send UPDATE (prepend, chgflags: 0x208) 172.16.20.0/24, next 192.168.32.1, metric 0, path

Comment: The router is sending an UPDATE message to 192.168.32.2 containing the route 172.16.20.0/24 with the attributes of NEXT_HOP: 192.168.32.2, MED: 0 01:34:12: BGP(0): 19)2.168.32.2 1 updates enqueued (average=56, maximum=56) 01:34:12: BGP(0): 192.168.32.2 update run completed, afi 0, ran for 4ms, neighbor version 0, start version 5, throttled to 5 Comment: UPDATE messages were engueued for transport and then sent successfully the BGP table version has been changed to 5 01:34:12: BGP: 192.168.32.2 initial update completed Comment: The update is complete

If the BGP peers are not able to reach each other using TCP port 179, you can use a number of TCP troubleshooting commands to troubleshoot the connection. As a best practice (that will save you m headache), however, it i s better to verify the router configuration for i naccuracies before troublesh' problem that might end up being a typo.

• Verify that the local BGP ASN is entered correctly.

• Verify that the remote peer's BGP ASN and IP address are entered correctly.

i Veri fy tha t the intei-faœs conn ectin g the two peeas are ug and operational.

• If the peers are n ot directly connected, verify tha t they have a valid route (to and from) to rea other .

• Check routers along the path between the peers for access lists or route policies that might b< or kerouting BGP traffic.

c Chece logs; for intefface i nstabiliti es. Are routes flapping along the route between the BGP pee any oh t he interfaces he acily congested ou d wopp ing packets ? Keep in mind that BGP uses rath packets fo r OPEN and KEEPALIVE messages. These pa akets are dela yed if oth er larger packet: mcnopolizing a congested i stenface.

• If something has changed in the path between the two BGP peers, verify that it is not affectin session—for example, a new switch configuration, new access lists, a firewall, new routing po so on.

Don't spend time troubleshooting BGP when it is not the problem! Establish a general layered troubleshooting methodology; it will be the number one troubleshooting tool and your best friend w encounter a problem.

Step 1. Layer 1

- Check your cabling; verify that all cables are connected and that the interface is in a and protocol up state. Don't spend time troubleshooting BGP when you have a Layer 1

- If you are using a serial link, make sure that you have set the correct clock rate. If yc using a channel service unit/data service unit (CSU/DSU), make sure it is properly con' and the line is up.

- If you are using an Ethernet interface, make sure that the speed and duplex are set c the mouter and switch.

- Check the router and switch interfaces for errors; if there are errors, fix the error and proceed with your troubleshooting.

If you are using a Token Ring interface, make sure the router is configured to use the r speed, and that it has a good connection to the multistation access unit (MSAU) or swil Step 2. Layer 2

- If you are using an Ethernet connection, make sure that the switch port has been ass the proper VLAN.

- Make sure that the VLAN is properly configured, and that there are no spanning-tree problems on the s witch.

- On an ATM interface, verify that the maximum transmission unit (MTU) is properly co on both sides of the connection.

- Vknfy that you are using the correct virtual path identifier/virtual channel identifier ( pair, and that you have configured a valid ATM map for Layer 2 to Layer 3 connectivity

On a Frame Relay connection, verify that your local and remote data-link connection id (D LCIs) and Local Ma nage ment Interface (LMI) type are correctly set to match the vali generated on the switch.

- Verify that LMI i sup and tha t the inte rface is not flapping.

- If you are maki ng a PPP connectio3, make sure PPP is configured on both sides of the connection.

- Before proceeding to the next step, verify that your interface is not in a line up proto< state.

- Verify that °os have configu red the right IF1 a ddre ss and subner mas k on the interface the oth ee side of the connecoio n, and ver ify ahat it i s on the same s ubnet (f d irectly con that it is what you nhink it is.

- Make sure there is a valid route to reach your destination in the IP routing table. Trac connection through any routers along the path, and verify that they have a path to and each of the routers that they must reach for packets to reach your source and destinati networks.

- Check static routes for typos; make sure that any redistributed routes are actually be properly propagated.

- If multiple paths are in use, verify that there art no routing loops.

- If authentication is in use by any routing protocols, make sure that they are both usin correct passwords.

- On nonbroadcast multiaccess (NBMA) networks, such as ATM or Frame Relay, make s you have proper support for Layer 2 to Layer 3 mappings, and that protocols such as O Chortest Path First (OCPF) are configured for the proper network type.

- Before proceeding to the next step, verify that you are able to reach the destination n fEom the source network and vice versa.

- Check for any access lists or firewalls that might be dropping TCP pacnetSi

- Verify th at you have connectivity on TCP port 179. One BGP speaker, the passive TCP receive a TCP request on port 179, and the other speaker, the active TCP host, will use TCP source port (beginning at 11,000) to initiate the TCP session.

- Check for retransmissions, out-of-order packets, or other TCP symptoms that might t to network congestion or invalid configurations.

After verifying that all the prior conditions are not affecting the BGP session, use TCP show and de Gommands to help natrow down t he cu i L-it. These commands, your B GP TCP connect i on troubleshc Pools, are lirted i n Table 8- ^

Table 8-3. TCP Connection Troubleshooting Tools

TCP Command

Sommand Description

show tcp

This comuaasd disp lays detailed infom aho n on eac h TCP session th at the router ha s fofu-ed with a remote pngr. It can by used with BGP to show w the local and remote BGP peerv have fotmed an estab lish ed TCP spssion, detalls about thai session.

show tcp [brief][all] [| include 179]

This command displays a brief status of each of the TCP sessions that the router has formed with a remote router. This is a basic summary comma y ou can us e as anothe r tool to veriiy the BG P TCP connection b-tw een pn

debug ip tcp, trannactions

This command, which sh o-ld be used w|th caution on a prod uction router information abuut TCP session c han ges. It enaltles you tn troubleshoot a ses sio^ disp |ayirg info vmat ion about TCn retransmissions os state chang

debug ip tcp packet [in | ops - address

IP-addressl portport-number]

This co mmand d i splays dotailed ihformat i on a bout TCP packets. It can be with thq it, out, addres s, or port: a rgnmunts to specify particular traffic must be used with extreme caution on a production router. With this com you can monitor TCP packets sent and received by the local router. This information enables you to determine the cause of an unstable BGP TCP s and resolve route flapping or general connectivity issues.

If the show tcp command output for the peer IP address used for the BGP session is anything othe ESTAB, troubleshoot the TCP connection. The show tcp command, shown in Example 8-14, displa information about the TCP session, and should, as a best practice, always be used as a TCP session

troubleshooting command.

Example 8-14. show tcp Command

Alki#show tcp

Stand-alone TCP connection to host 192.168.32

.2

Connection state is ESTAE

i, I/O status: 1, unread input

bytes:

0

Local host: 192.168.32.1,

Local port: 11009

Foreign host: 192.168.32.

2, Foreign port: 179

Enqueued packets for retransmit: 0, input: 0

mis-ordered: 0

(0 bytes)

Event Timers (current time is 0x16681CC):

Timer Starts

Wakeups Next

Retrans 323

1

0x0

TimeWait 0

0

0x0

AckHold 320

164

0x0

SendWnd 0

0

0x0

KeepAlive 0

0

0x0

GiveUp 0

0

0x0

PmtuAger 0

0

0x0

DeadWait 0

0

0x0

iss: 3779523619 snduna:

3779529779 sndnxt:

3779529779

sndwnd: 160i

0

irs: 2902813429 rcvnxt:

2902819573 rcvwnd:

16099

delrcvwnd: 2i

35

SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT:

0 ms

minRTT: 2 0 ms, maxRTT: 300 ms, ACK hold: 2 00

ms

Flags: higher precedence,

nagle

Datagrams (max data segment is 1460 bytes):

Rcvd: 556 (out of order:

0), with data: 320,

total data

bytes

: 6143

Sent: 492 (retransmit: 1,

fastretransmit: 0),

with data

: 321,

total data

bytes:

6159

Table 8-4 displays detailed information on the output of the show tcp command. You will probably all 20 lines of the command in day-to-day troubleshooting, but they might come in handy when yo troubleshooting TCP connection problems, such as too many retransmissions.

Table 8-4. show tcp Command Output Explained

Command Output

Output Description

Stand-alone TCP connection to host 192.168.32.2

Identifies TCP connection from the loc to host 192.168.32.2.

Connection state is ESTAB

Indicates an established TCP session.

TheConnection state is can be any following values:

LISTEN— Indicates that the router is for a connection renueit

SYNSENT— Indicates that the router waiting for a connection request in re request that was sent (TCP-SYN mess

SYNRCVD— Indicates that the route and received a connection request an waiting for a connection acknowledge (TCP-ACK message)

E STAB— Indicates an establiLhed TC TCv-SYN and ACK me ssages)

FINWAIT1— Indicat es that the route either waiting for a termination renue acknowledgement to a previously ser termmat ion req bestTCb-FIa ACF me

FINWAIT2— Indicates that th e route waiting for a termination request from remote host (TCP-FIN message)

C LOSEWAIT — Indicates th at ahe rou wait 1 ng for a termination request from (TCP-FIN message)

CLOSING— Indicates that the router waiting for a termination request from remote host (TCP-FIN message)

LASTACK— Indicates that the router waiting for a response to a terminatk that was made to a remote host (TCF

message)

TIMEWAIT— Indicates that the rout giving the remote host time to receiv connection termination request befor the connection

CLOSED— Indicates that there is no connection

For a successful BGP session, the TCP must always be in the ESTAB state.

I/O status: 1

Describes the status of the connection

unread input bytes: 0

Indicates the number of bytes that h; read and are awaiting processing.

Local host: 192.168.32.1, Local port: 11009 Displays the local IP address and TCP

number.

Local host: 192.168.32.1, Local port: 11009 Displays the local IP address and TCP

number.

You can use this number to determin the local or remote router initiated th session. If the TCP port is in the 11,0 the router initiated the session to a re router at port 179.

Foreign host: 192.168.32.2, Foreign port: 179 Displays the remote IP address and T

number for the connection.

For BGP, you always look for values o a port in the 11,000 range.

Enqueued packets for retransmit: 0, input: 0 mis- Displays the number of packets waiti ordered: 0 (0 bytes) Eetransmitted.

Any va I ue greater than 0 indiHates pa Ietr/nshtissi on and migh t point to TC problems .

This seccion displ ays TC P time! inforu c ounter form for t he c uxrent TCP suss information can be cleared with the c statistics commanE. )

TheEvent Timer disp nays the amount that nhe system has been running in m Mlisdconds.

TheT/mer column describes the timer the rows beneath.

TheStarts column describes the numb times that the counter has been start this session.

TheWakeups column describes the nu unacknowledged t^EPAHVES.

TheNext column shows the next timu

Event Timers (current time is 0x16681CC):

Timer Starts Wakeups Next

Retrans 323 1 0x0

TimeWait 0 0 0x0

AckHold 320 164 0x0

SendWnd 0 0 0x0

KeepAlive 0 0 0x0

GiveUp 0 0 0x0

PmtuAger 0 0 0x0

DeadWait

timer will go off.

TheRetrans timer displays the value < timer used to time unacknowledged p awaiting retransmission.

TheTimeWait timer shows the amoun the system will wait to allow a remote to receive a connection termination r

TheAckHold timer is used to delay the transmission of acknowledgements tc network congestion.

TheSendWnd timer prevents TCP sess from being lost due to missing acknowledgements.

TheKeepAlive timer is used to time th between KEEPALIVE messages.

Event Timers (current time is 0x16681CC)

Timer Retrans

TimeWait

AckHold

SendWnd

KeepAlive

GiveUp

PmtuAger

DeadWait

Starts Wakeups

323 0

Next 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

TheGiveUp timer is the minimum tin before giving up on a pending resolul request.

ThePmtuAger timer is the timer that keep track of the path MTU age-timei be changed using the ip tcp path-m1 discovery [age-ti mer {minutes | indefinite}] command.

TheDeadWait timer is the TCP DeadW timer.

iss: 3779523619

D isplays the i nitial send seq uence nu whic h is the initial sequence number during a new TCP session.

snduna: 3779529779

Displays the last unacknowledged seq number that the router has sent.

sndnxt: 3779529779

Displays the next sequence number t be sent.

sndwnd: 16080

Displays the remote host's TCP winde irs: 2902813429

Displays the initial receive sequence i

rcvnxt: 2902819573

Displays the last sequence number th been received and acknowledged.

rcvwnd: 16099

Displays the local router's TCP windo

delrcvwnd: 2 85

Displays the delayed receive window the uncomputed value of the receive

SRTT: 300 ms

The smooth round-trip timer is a mea of the average time that it takes a pa sent and acknowledged by the remot

RTTO: 303 ms

The round-trip timeout in millisecond

RTV: 3 ms

The variance of the round-trip time ir milliseconds.

KRTT: 0 ms

The new round-trip (K stands for Kar algorithm) timeout. It measures the time, in milliseconds, for packets that been retransmitted.

minRTT: 2 0 ms

The smallest round-trip timeout.

maxRTT: 300 ms

The largest round-trip timeout.

ACK hold: 2 00 ms

The a ck io_w ledgment delay Eimeout u delay acknowledgements to allow tim data to the packet.

Flags: higher precedence

Spe cifies IP preced en ce pa^es that m present in the packets.

nagle

Specifies thot the Nagle flag is set.

Datagrams (max data segment is 1460 bytes):

The largest data segment in bytes.

Rcvd: 556 (out of order: 0, total data bytes: 6143

The number of datagrams received.

The numher of1 datagra m s that were out of ord er.

The total bytes of data received .

Sent: 492 (retransmit: 1, fastretransmit: 0), with data: 321, total data bytes: 6159

The number of datagrams sent.

The number of datagrams that had to retransmitted.

The number of faet retfansmissions.

The n umber of datagrams t hat were contamed data.

The total bytes of data received.

Two other frequently forgotten tools that enable you to troubleshoot a TCP connection are the deb transactions and debug tcp packet commands. Output from the debug tcp transactions comr shown in Example 8-15.

Was this article helpful?

0 0

Post a comment