Date: Wed, 4 Jan 2012 07:33:25 +0200 From: Nikolay Denev <ndenev@gmail.com> To: sthaug@nethelp.no Cc: dougb@FreeBSD.org, freebsd-net@FreeBSD.org, hrs@FreeBSD.org, emaste@FreeBSD.org, borjam@sarenet.es Subject: Re: openbgpds not talking each other since 8.2-STABLE upgrade Message-ID: <5739312A-614C-492A-BB89-F386B7F74CF5@gmail.com> In-Reply-To: <20120103.203608.74677765.sthaug@nethelp.no> References: <6FE9FF15-487F-4A31-AEE0-A0AD92F5DC72@sarenet.es> <20DC0C8A-DD9E-408E-9ACA-82532DB31871@lists.zabbadoz.net> <20120104.040611.1847309275485655567.hrs@allbsd.org> <20120103.203608.74677765.sthaug@nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 3, 2012, at 9:36 PM, sthaug@nethelp.no wrote: >> Doug, does your kernel have TCP_SIGNATURE option? The patch[*] for >> net/openbgpd can be used as a workaround if it was due to TCP_MD5SIG >> option on the listening sockets. >>=20 >> [*] http://people.allbsd.org/~hrs/FreeBSD/openbgpd.20120104-1.diff >>=20 >> While this is an ugly hack and I will investigate more reasonable >> solution for that, I want to narrow down the cause first. Can anyone >> who are using a 8-STABLE kenrel with TCP_SIGNATURE let me know if >> this works or not? >=20 > 8-STABLE on several servers, csup'ed only a couple of days ago, with=20= >=20 > options TCP_SIGNATURE > options IPSEC > device crypto > device cryptodev >=20 > and Quagga bgpd talking to Juniper M/MX routers using MD5 key on the > BGP sessions. No problems. >=20 > Steinar Haug, Nethelp consulting, sthaug@nethelp.no This was always working for me. My problem was that I had two routers having BGP sessions to an ISP with md5 and a session between themselves = without md5. After I upgraded to 8-STABLE some time ago, the md5 sessions still = worked, but the ones without did not. tcpdump showed packets with md5 digest fields = all zeroes. If one of the machines does not have md5 signature support it will = probably work, since when one of the routers tries to speak tcpmd5 even with incorrect = digest field, the other one tries to respond also with tcpmd5. Also there are some things in the tcp(4) manual page that should be = fixed to reflect the new behaviour (the part mentioning that incoming digests are not = verified): TCP_MD5SIG This option enables the use of MD5 digests (also known = as TCP-MD5) on writes to the specified socket. In the = current release, only outgoing traffic is digested; digests on incoming traffic are not verified. The current = default behavior for the system is to respond to a system = advertis- ing this option with TCP-MD5; this may change. Also in the case of my failing BGP sessions I expected to see errors as = per the man page : If an SADB entry cannot be found for the destination, = the outgoing traffic will have an invalid digest option prepended, and the following error message will be = visible on the system console: tcp_signature_compute: SADB = lookup failed for %d.%d.%d.%d. But this was not happening. Regards, Nikolay
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5739312A-614C-492A-BB89-F386B7F74CF5>