Claudio Jeker wrote:
On Wed, Oct 05, 2005 at 06:33:05PM -0400, Daniel Ouellet wrote:
======================
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.
The interesting facts here for me were how different it was for each
side. I did this many times 10x+ on each setup to see. bgpd master to
Cisco and clear from bgpd side to Cisco, the Cisco session comes back up
instantly. As for Cisco master initiate clear to bgpd, was the slowest
by far. I mean much longer. The other two possibilities are pretty much
equal. It was interesting finding never the less. Why, I am not sure
however.
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.
I will try current again, and send even more details on my setup, or if
you ever want to check it out, I have no problem what so ever to provide
you access to both boxes directly for you to check it out as well. Just
say the words if interested? I try Cisco IOS 12.3x and 12.4x, same
results so far.
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.
Last tests at ~5 AM this morning, still show me this and nothing was in
the path for blocking it a tall. I will recheck as it's been a few days
without sleep so far, so I admit, I could start to be fussz a bit. Lack
of sleep, but I will make sure before saying false things here. But in
any case, not that I like it what so ever, I am not sure of the
Cizzz-coee stuff. The sad thing is that they have a huge portions of the
Internet routers still, hopefully changing quickly, but still, we need
to interact with them a lots.
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.
I can deal with that delay and I agree that it makes sense to refuse the
reset, or ignore it, however, looks like so far, the session doesn't
resets. May be because it does receive message still from the Cisco side
on wrong ports, but somehow see it as keep alive. I really don't know
what I am saying here, just a weird thoughts, but so far the results are
that it doesn't resets. I will tests in more details again. But just
know that something is not active in the best interest of the session
here somewhere.
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.
No, not if you killed it, but that was with trying to have bgpod slave,
not master. More to come on this as well.
===============
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.
No PF what so ever. The setup was describe in the first posting.
In short, I have both boxes connected to a switch and I ONLY put a
filter on the Cisco router to force the direction to the port tcp/179 to
force witch side will be initiate the session. The filter use was one of
the two below, depending what side I wanted to force to be master, or
slave. This was apply to the FastEthernet facing the bgpd side
obviously. That was/is legal no. Not in normal operation, but for
testing reason, it should really do what I am trying to do and force one
side to become the master no? Based on the RFC anyway, it sure should be.
I tested that on both a Cisco 5350 and 7206 VXR. I can most likely also
tests this on 26xx, but I didn't think it was going to be different.
Also, soft-reconfig inbound was enable in all tests, may be I should
check without, but when you peer, most likely many peers will have that
enable by defaults.
ip access-list extended bgpd-master
permit tcp host 66.63.12.108 neq bgp host 66.63.12.107 eq bgp
deny tcp host 66.63.12.108 eq bgp host 66.63.12.107 neq bgp
permit ip any any
ip access-list extended bgpd-slave
permit tcp host 66.63.12.108 eq bgp host 66.63.12.107 neq bgp
deny tcp host 66.63.12.108 neq bgp host 66.63.12.107 eq bgp
permit ip any any
Regards,
Daniel
