Attached is packet capture of the BGP on 192.168.10.1 router.
The the config of the 192.168.10.1 (Packet number 23)
router bgp 400
bgp router-id 192.168.10.1
bgp default local-preference 150
neighbor 192.168.10.5 remote-as 65000
neighbor 192.168.10.5 weight 1
neighbor 192.168.10.5 soft-reconfiguration inbound
neighbor 192.168.10.5 route-server-client
The BGP peers are not forming between the two Routers. The router 192.168.10.5 is ISP and we do not have control over it.
Is there a way to remove optional parameters from the packet 23 or any configuration changes are required from the above config to remove the optional parameters.
Or is there any other issue which I am overlooking.
Your assistance will be highly appreciated.
is the BGP session failing? Or you just don't exchange any prefixes with the neighbor?
As Rais is suggesting, I'd try to remove the 'route-server-client' command from your config, as it can be modifying the AS_PATH of your prefixes advertised considerably, see
in you packet capture, are there any details visible in the BGP Notification message?
Have you tried to remove the
command from your config?
you received a notification message which should have appeared in the logs and which is in your capture file can you tell us what it is fussing about because when there is a mismatch in supported capibilities it doesn't bring the neighborship down.
My requirement is that I do not want the optional parameters to be part of my config. Please let us know what configs should I eradicate from the config.
Do you mean the relatationship does not come down when optional paramters are not same?
We saw one more error of the AS bit. The opposite brand supported only 2 byte ASN so it used to send warning.
Please explain the behavior and the use of optional parameters.
I mean that it is a negotiation and if a bgp speaker sees acapability as not supported by the peer with a notification message then it will try to bring up the peering again this time not sending this capability but it should not bring the neighborship down.
But in your case apparently the peer has no optional parameter so maybe this is why it won't bring the neighbourship up and that's why I proposed the command I found in my previous post.
It makes sense.
the behavior which we have seen was that the peers were failing so we captured the logs (pcap above). But we lost the access after removing the route-server-client command as we were connected on the WAN IP address.
We found that opposite brand has advertised a default static route. So which means that the command route-server-client did work.
We used prefix list to stop the default route being advertised to our router.
and it worked fine. Considered this as closed and you guys saved my day.
Thank you very much.