Skip to main content
journeyman
journeyman
New Member
February 14, 2013
Question

BGP - help to diagnose neighbor not coming up

  • February 14, 2013
  • 2 replies
  • 24095 views
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?

    2 replies

    emnoc
    emnoc
    New Member
    February 14, 2013
    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
    journeymanAuthor
    New Member
    February 14, 2013
    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
    emnoc
    New Member
    February 14, 2013
    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
    journeymanAuthor
    New Member
    February 14, 2013
    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!!
    Terms & ConditionsAccessibility statement