Open richard-chivers opened 2 weeks ago
Hi,
We are having an issue where we can't seem to establish a BGP session with a multi-hop neighbor.
The neighbor is a mainstream T1 ISP with hundreds of active working configurations.
We have a working configuration with this bgp peer, using openbsd.
This worked previously when we were on an older version of Ubuntu, but we cannot get it to work again since the upgrade.
If we remove the password requirement, the connection comes up immediately.
Running a TCP dump we see x.x.x.x.23932 > x.x.x.x: Flags [S], cksum 0x92cf (correct), seq 281719169, win 16384, options [mss 4386,wscale 0,nop,md5 shared secret not supplied with -M, can't check - db77b52562c1345cad6a9367be3830f8,eol], length 0
At the other end, they are seeing UTC: tcp[463]: %IP-TCP-3-BADAUTH : Invalid MD5 digest from x.x.x.x:xx to x.x.x.x:179 for vrf:default
We are running behind nat, and we have tcpdumped at the firewall to show our outgoing nat is correct.
Is it possible that the md5 hash uses the local IP or similar to hash the password?
We have always run in this way, the only change is the OS upgrade, and I guess with that a gobgp upgrade too.
Also, we have checked: CONFIG_TCP_MD5SIG=y
Any help appreciated.
Hi,
We are having an issue where we can't seem to establish a BGP session with a multi-hop neighbor.
The neighbor is a mainstream T1 ISP with hundreds of active working configurations.
We have a working configuration with this bgp peer, using openbsd.
This worked previously when we were on an older version of Ubuntu, but we cannot get it to work again since the upgrade.
If we remove the password requirement, the connection comes up immediately.
Running a TCP dump we see x.x.x.x.23932 > x.x.x.x: Flags [S], cksum 0x92cf (correct), seq 281719169, win 16384, options [mss 4386,wscale 0,nop,md5 shared secret not supplied with -M, can't check - db77b52562c1345cad6a9367be3830f8,eol], length 0
At the other end, they are seeing UTC: tcp[463]: %IP-TCP-3-BADAUTH : Invalid MD5 digest from x.x.x.x:xx to x.x.x.x:179 for vrf:default
We are running behind nat, and we have tcpdumped at the firewall to show our outgoing nat is correct.
Is it possible that the md5 hash uses the local IP or similar to hash the password?
We have always run in this way, the only change is the OS upgrade, and I guess with that a gobgp upgrade too.
Also, we have checked: CONFIG_TCP_MD5SIG=y
Any help appreciated.