BGP - help to diagnose neighbor not coming up

[journeyman]

We have a BGP implementation to an external peer which has just been put in place. There is traffic but the neighbor does not come up, any clues are most welcome. In diagnostics and we see:

[diag sni pac wan1 none 4]
 wan1 1.1.1.3.24072 -> 1.1.1.11.179: syn
 wan1 1.1.1.11.179 -> 1.1.1.3.24072: syn ack
 wan1 1.1.1.3.24072 -> 1.1.1.11.179: ack
 wan1 1.1.1.11.179 -> 1.1.1.3.24072: fin ack
 wan1 1.1.1.3.24072 -> 1.1.1.11.179: psh ack
 wan1 1.1.1.11.179 -> 1.1.1.3.24072: rst
 
 [diag ip router bgp  level info and all enable]
 " BGP: [NETWORK] Accept Thread: Incoming conn from host 1.1.1.3 (FD=14)" 
 " BGP: 1.1.1.3-Outgoing [FSM] State: Idle Event: 14" 

We also used the sniffer with level 6 and converted to pcap; this shows the PSH packet is a BGP open packet. Other than containing capability advertisements there is nothing unexpected in it, all data matches. Our BGP config is very basic:

config router bgp
 set as 100
 config neighbor
 edit 1.1.1.3
 set remote-as 200
 set send-community6 disable
 end
 config network
 edit 1
 set prefix 2.2.2.0/24
 end
 set router-id 1.1.1.11
 end

We have other BGP connections that work fine with this level of simplicity What is the meaning of the 14 in " Outgoing .. Event: 14" in the diagnostics messages, does this provide a clue? Can anyone suggest why our FGT is refusing the connection from the neighbor we have configured?

[emnoc]

could be host of issues, but here what I would do; are both neighbors on the same subnet/lan are your remote-as/local-as correct 200/100 what are you connecting juniper/cisco? ( have they looked at their logs ) are they using a md5 passcode? if yes can they temp remove this? Since the remote-as is establishing the connecting and you fin-ack' ing it, I suspect a md5 passcode or remote-as mismatch . PSH ack is weird also. If it' s the cisco, it will tell you the mismatch in HEX on what' s it' s expecting from the peer. If it' s a cisco/juniper, it would give you any md5 passcode mismatch. So I would validate the neighbor as and md5 is applicable

[journeyman]

Thanks for your reply. Neighbors are not on the same subnet AS numbers have been checked. Also the " My AS" field in the incoming BGP open packet is as expected. I believe the neighbor is cisco. We were using md5 but when that didn' t work we stripped it out. Currently running with no password. Some more observations: - We have end to end connectivity (evidenced by SYN-SYNACK-ACK). - The FGT never initiates a connection. I would have thought it would. - We are receiving loopback frames from the adjacent router (which is not the neightbor but is a Cisco and is owned by the same people) - When converted to pcap, the trace shows that we are sending FIN immediately after SYN is complete, before the BGP open hence before any md5 or AS is exchanged. I' ll query their logs and hardware. But it looks like I' m shutting down the BGP before it any data is exchanged. Add - all peer hardware is cisco

[emnoc]

You need to disable direct-connect check if the neighbor-ships is not on the same subnet as in a directly connected neighbor. cisco ( e.g router bgp no direct-connect or ebgp-multihop " ttl" fortinet I haven' t looked into that, so do some research. Also make sure your not using a default-route to peer with that neighbor. One of you need at least a /32 host route to peer with a remote-hop neighbor.

[journeyman]

Thank you very much, that was exactly the problem. I had no idea. The setting to change is:

config neighbor
   edit 1.1.1.3
     set ebgp-enforce-multihop enable
   next
 end

We have a couple of different bgp peers, obviously all are on local subnets. Thanks very much again!!