BGP Multilink PPP active state debug questions

[networkguy09]

Hello,

I encountered a problem bringing up a multilink ppp connection and have a few questions understanding the debug messages from debug ip bgp and debug ip tcp transactions. Here are the relevant messages (ip addresses changed to protect the innocent )

1) First question: I see my side is sending a SYN three times then timing out with remote host not responding. Ideally, would this same debug show the remote side sending a SYN as well? My understanding of BGP is that both sides would do TCP threeway handshakes. However wouldn't that establish two separate sessions?? I know I need to read more on BGP This is the best doc I've found so far: http://www.tcpipguide.com/free/t_BGPConnectionEstablishmentOpenMessages.htm If you have two separate handshakes resulting in two separate TCP connections does BGP use both?

2) What is the TCB4ACC603C created? Just a set of letters and numbers use to designate this session? What is the meaning behind TCB4ACC603C? Further down you see TCB 0x4ACC603C destroyed.

Looks to me like there is a problem with the remote end, either configuration or firewall preventing it from completeing the handshake. Also explains why I don't see SYN from it. Thoughts?

.May  5 05:51:05: BGP: 2.2.2.2 open active, local address 1.1.1.1
.May  5 05:51:05: TCB4ACC603C created
.May  5 05:51:05: TCB4ACC603C setting property TCP_WINDOW_SIZE (0) 4B2BA6E0
.May  5 05:51:05: TCB4ACC603C setting property TCP_MD5KEY (5) 0
.May  5 05:51:05: TCB4ACC603C setting property TCP_TOS (11) 4B2BA6C0
.May  5 05:51:05: TCB4ACC603C setting property unknown (23) 4B2BA6B0
.May  5 05:51:05: TCB4ACC603C setting property TCP_OUT_TTL (30) 49D1B7FE
.May  5 05:51:05: TCP: Random local port generated 39883, network 1
.May  5 05:51:05: TCB4ACC603C bound to 1.1.1.1.39883
.May  5 05:51:05: Reserved port 39883 in Transport Port Agent for TCP IP type 1
.May  5 05:51:05: TCP: sending SYN, seq 1581748373, ack 0
.May  5 05:51:05: TCP0: Connection to 2.2.2.2:179, advertising MSS 1460
.May  5 05:51:05: TCP0: state was CLOSED -> SYNSENT [39883 -> 2.2.2.2(179)]

.May  5 05:51:07: 1.1.1.1:39883 <---> 2.2.2.2:179   congestion window changes
.May  5 05:51:07: cwnd from 1460 to 1460, ssthresh from 65535 to 2920
.May  5 05:51:07: TCP0: timeout #1 - timeout is 4000 ms, seq 1581748373
.May  5 05:51:07: TCP: (39883) -> 2.2.2.2(179)

.May  5 05:51:11: TCP0: timeout #2 - timeout is 8000 ms, seq 1581748373
.May  5 05:51:11: TCP: (39883) -> 2.2.2.2(179)

.May  5 05:51:19: TCP0: timeout #3 - timeout is 16000 ms, seq 1581748373
.May  5 05:51:19: TCP: (39883) -> 2.2.2.2(179)

.May  5 05:51:35: Released port 39883 in Transport Port Agent for TCP IP type 1 delay 240000
.May  5 05:51:35: TCP0: state was SYNSENT -> CLOSED [39883 -> 2.2.2.2(179)]
.May  5 05:51:35: TCB 0x4ACC603C destroyed
.May  5 05:51:35: BGP: 2.2.2.2 open failed: Connection timed out; remote host not responding, open active delayed 33433ms (35000ms max, 28% jitter)

[Marcel Zehnder · Accepted solution]

Hi

1) your neighbor router should answer with a SYN/ACK to setup the TCP session. If the other router also tries to setup a connection there is something like a session collision detection withing BGP: Short explanation: Only the session originated by the router with the higher BGP router-id will survive - the other one gets killed ;-)

2) hmmmm, that strange number is the session-id I guess (not to sure about that...)

HTH

Marcel

[networkguy09]

Hi,

Are you saying both sides attempt TCP threeway handshake still? And only one is used, the other is killed by BGP. Makes sense. Thanks for the reply.

[Marcel Zehnder]

exactly :-)

[Giuseppe Larosa]

Hello,

>> What is the TCB4ACC603C created?

it is a data structure that stores the data of the TCP connection this is part of debug tcp transactions

as Marcel has noted one TCP session is quickly closed as only one is enough for the BGP session

in your case before going so deep on debugging you should try to ping the eBGP endpoint using as source your local address

also if this is eBGP and you are using loopbacks you need to increase ebgp-multihop because eBGP packets are sent out with IP TTL=1 by default.

TCP handshake in short looks like :

SYN --->

SYN/ACK <----

ACK --->

Hope to help

Giuseppe

[networkguy09]

Thanks for the replies everyone and apologies for the delayed follow up. Issue turned out to be a problem on the providers end.