28.06.2014 Views

Discussion

Discussion

Discussion

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

lem with BGP itself. When the TCP session doesn’t work properly, the BGP session<br />

times out, and BGP signals the problem by sending hold-time expired messages and<br />

generating a BGP Notification message to the remote peer. Notification messages are<br />

logged at the system logging severity level warning.<br />

Some of the most frequent causes of hold-time expired errors are MTU issues on a<br />

directly connected link, issues related to forwarding of Internet control packets, and<br />

IGP failures on IBGP sessions.<br />

Looking at the TCP MTU path behavior, first let’s look at the TCP session. By<br />

default, a TCP session transmits 576 bytes in a single packet to minimize the chances<br />

that the packet will be fragmented at a device along the path to the destination. Most<br />

links use an MTU of at least 1,500 bytes. Path MTU discovery, which is disabled by<br />

default in the JUNOS BGP, allows BGP to dynamically determine how large the<br />

packets can be in a TCP session without being fragmented. This means that BGP<br />

tries to use 576-byte packets for the TCP sessions. However, on directly connected<br />

EBGP sessions, TCP uses MTU-sized packets. If there is an MTU mismatch between<br />

the two sides of the TCP connection, the BGP session cannot be established. One<br />

workaround is to enable path MTU discovery within the BGP group:<br />

[edit protocols bgp group external]<br />

aviva@RouterF# set mtu-discovery<br />

When path MTU discovery is enabled, the don’t fragment (DF) bit is set on all TCP<br />

packets sent by the BGP session.<br />

When you are testing session connectivity, in addition to the standard ping command,<br />

send packets in which the Internet control CoS bit is set:<br />

aviva@RouterF> ping tos 0xc0 RouterD<br />

If the QoS parameters are misconfigured on a transit router, TCP connectivity can<br />

work for regular best-effort traffic but will break for Internet control traffic. The<br />

same behavior can happen when you are testing new software or new PICs.<br />

Another way to get information about the TCP session and what might be malfunctioning<br />

is to look at the current state of TCP sessions:<br />

aviva@RouterF> show system connections extensive | find tcp<br />

tcp4 0 2 192.168.70.143.23 172.17.28.108.3350 ESTABLISHED<br />

sndsbcc: 2 sndsbmbcnt: 256 sndsbmbmax: 266432<br />

sndsblowat: 2048 sndsbhiwat: 33304<br />

rcvsbcc: 0 rcvsbmbcnt: 0 rcvsbmbmax: 463360<br />

rcvsblowat: 1 rcvsbhiwat: 57920<br />

iss: 2677798142 sndup: 2677853922 sndcc: 0<br />

snduna: 2677853922 sndnxt: 2677853924 sndwnd: 57920<br />

sndmax: 2677853924 sndcwnd: 65535 sndssthresh: 1073725440<br />

irs: 1577022682 rcvup: 1577023284 rcvcc: 0<br />

rcvnxt: 1577023292 rcvadv: 1577081212 rcvwnd: 57920<br />

Diagnosing TCP Session Problems | 437<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2008 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!