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. >
> ====================== > > 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 see similar delays with my test setup. Most of the time it takes longer for a session to come back up because of different timers that are run. After a clear a reopen is tried immediately and that is most often blocked. In my case the cisco seems to be to slow to close the session in time for the reopen. It also matters where you close the connection because in one case the idle timer is run (30s) instead of the connect retry timer (120s). Also the idle timer has starts to grow if you flap the session often. > ================ > > 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 > I can't reproduce this. On my test setup all session come back up. ... > 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) > This is a Cizzz-coee / RFC feature. They enforce a TCP MD5 digest on TCP RST packets. Now that's just stupid because it is not possible to do that in some cases because the other side does not know the key at that time (e.g. to signalize that the port is unavailable). In your case this means that somehow the connection from the cisco to your OpenBSD box is blocked or there is nothing listening on port 179. > Looks like the OpenBSD side do not provide the MD5 to the Cisco to > establish the session. > OpenBSD only misses the MD5 digest on the RST packets and that is actually OK. RFC 2385 actually mentions this special case in 4.1: A connectionless reset will be ignored by the receiver of the reset, since the originator of that reset does not know the key, and so cannot generate the proper signature for the segment. This means, for example, that connection attempts by a TCP which is generating signatures to a port with no listener will time out instead of being refused. Similarly, resets generated by a TCP in response to segments sent on a stale connection will also be ignored. Operationally this can be a problem since resets help BGP recover quickly from peer crashes. > 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. > Does it initially come up? As I said I can not reproduce 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. > Are you running pf? Perhaps the packet get blocked or modified on the way in and so the session is reset. Check with netstat -sptcp for the md5 counters. BTW. I mostly reused your config. I just disabled soft-reconfig inbound because my 2500 testbox would probably not survive that. -- :wq Claudio
