We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
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.
The text was updated successfully, but these errors were encountered: