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.
================
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.
===============
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.
================
Setup and tests done with results.
OpenBSD 3.7 and Cisco 5350 connected via Fast Ethernet switch.
OpenBSD <-> switch <-> Cisco 5350
BGP minimal configurations used:
================================
OpenBSD side:
dev1# more /etc/bgpd.conf
# Macros
Peer_Test="66.63.12.107"
# Default global configuration
holdtime 30
holdtime min 10
listen on 66.63.12.108
AS 65001
router-id 66.63.12.108
# List of networks to announce from the router.
network 10.0.1.0/24
# neighbors and peers
group "Peering iBGP on AS65001" {
remote-as 65001
local-address 66.63.12.108
announce all
neighbor $Peer_Test {
descr "iBGP Test"
}
}
==================================
Cisco side:
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 10.0.0.0 mask 255.255.255.0
neighbor 66.63.12.108 remote-as 65001
neighbor 66.63.12.108 version 4
neighbor 66.63.12.108 soft-reconfiguration inbound
no auto-summary
===================================
Filters used and apply to the Fast Ethernet configuration of the Cisco
router like this:
interface FastEthernet0/0
description Connection to OpenBSD Test Lab
ip address 66.63.12.107 255.255.255.192
ip access-group bgpd-master in
duplex auto
speed auto
or
interface FastEthernet0/0
description Connection to OpenBSD Test Lab
ip address 66.63.12.107 255.255.255.192
ip access-group bgpd-slave in
duplex auto
speed auto
and the filters used are:
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
===========================================
So the tests and logic are:
Force BGPd to initiate the session -> Cisco router with the filter:
ip access-group bgpd-master in
So, the traffic will be like this.
bgpd (tcp/!179) -> Cisco (tcp/179)
with replay
Cisco (tcp/179) -> bgpd (tcp/!179)
Session comes up right away.
vng2#sh ip bgp summ
BGP router identifier 66.63.12.107, local AS number 65001
BGP table version is 15, main routing table version 15
2 network entries using 234 bytes of memory
2 path entries using 104 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 710 total bytes of memory
BGP activity 7/5 prefixes, 8/6 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
66.63.12.108 4 65001 12357 12374 15 0 0 00:07:30 1
===========================================
Force Cisco router to initiate the session -> BGPd with the filter:
ip access-group bgpd-slave in
So, the traffic will be like this.
Cisco (tcp/!179) -> bgpd (tcp/179)
with replay
bgpd (tcp/179) -> Cisco (tcp/!179)
Session is never establish!
==========================================
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.
