On Wed, Oct 05, 2005 at 06:33:05PM -0400, Daniel Ouellet wrote: > More on this with test results, example, setup use, and more details. > > The short of it is that bgpd will not establish an MD5 connection as > slave ever! So, if you do get an MD5 session in normal operation, it may > well not stay stable at all depending of bgp flap and who will try to > become master after a flap. You may end up with bgp down until human > action is perform to get it back up from both side of the session. > > How did I show that. Checking the various possibility without MD5 > configure and then ONLY adding the MD5 on the working setup. > > Tested summary. Try to see the results when one side is always force to > be master or slave and see the impact of it. Also, make sure that after > a reset the master will stay the master. The use of filter will > accomplish this to try to isolate a possible problem. > > Please read on, as I think this show the situation as is. > > Daniel > > ====================== > > Without MD5 configure. > > With bgpd master > Clear session from bgpd side, session comes back up right away. > Clear session from remote side, session comes back up with delay. > > With bgpd slave > Clear session from bgpd side, session comes back up with delay. > Clear session from remote side, session comes back up with possible very > long delay. Much bigger then when master. >
I think this is fixed in -current. Henning commited something to make the delays on neighbor clears faster. > ================ > > Now with MD5 configure. We only add > > tcp md5sig password test on bgpd side and > neighbor 66.63.12.108 password test on the Cisco side. > > With bgpd master > Clear session from bgpd side, session comes back up right away. > Clear session from remote side, session comes back up with possible very > long delay. > > With bgpd slave > Just can't establish a session what so ever! The Cisco side will get > stuck in the OpenSent mode and cycle a few times all without success. > > 66.63.12.108 4 65001 0 1 0 0 0 never OpenSent > > The OpenBSD side will show an active session, but not up yet obviously: > > dev1# bgpctl s neigh 66.63.12.107 > BGP neighbor is 66.63.12.107, remote AS 65001 > Description: iBGP Test > BGP version 4, remote router-id 0.0.0.0 > BGP state = Active > Last read Never, holdtime 240s, keepalive interval 80s > > Message statistics: > Sent Received > Opens 1 0 > Notifications 0 0 > Updates 0 0 > Keepalives 0 0 > Route Refresh 0 0 > Total 1 0 > > Local host: 66.63.12.108, Local port: 179 > Remote host: 66.63.12.107, Remote port: 56923 > > And the Cisco side will keep cycling there from active to open and back > to active to open, etc. > > 66.63.12.108 4 65001 0 2 0 0 0 never Active > > Now looking at the logs from each side. OpenBSD try to use the port > tcp/56923 and from the Cisco side we see this error: > > 000035: *Oct 5 13:38:43.503 EDT: %TCP-6-BADAUTH: No MD5 digest from > 66.63.12.108(179) to 66.63.12.107(56923) (RST) > 000036: *Oct 5 13:38:44.503 EDT: %TCP-6-BADAUTH: No MD5 digest from > 66.63.12.108(179) to 66.63.12.107(56923) (RST) > > Looks like the OpenBSD side do not provide the MD5 to the Cisco to > establish the session. > > It doesn't matter if I clean the session from the Cisco side, or the > bgpd side, order, etc. Both side, many times, what ever. It will simply > not come up! > > Even reloading the Cisco router and killing the bpgd and starting new, > it will not come up! > > Always the same errors in the logs. > > No MD5 digest received from the OpenBSD side looks like. > It looks like the tcpmd5 is enabled to late when opeining a session. I try to have a look at it. > =============== > > Why is bgpd will not establish a session as slave when MD5 is configure > even if the RFC said both sides should be allow to do so? > > bgpd wants to be the master every time? > > Something sure looks weird here. > That's more like a bug. Btw. MD5 between to bgpd is working, at least it works for me. > ========================================== > > But it should be establish however for MD5 for sure as any sides can be > the master in a bgp session. > > However, not here? > > Comments on this? > > I think my tests are valid. Am I doing something I should be doing here? > I don't think so, but that's what I found so far and why I can't keep a > stable session with MD5 enable on it. > For me it looks like a bug for now. -- :wq Claudio
