On Thu, Jan 28, 2021 at 12:41:29PM +0100, open...@kene.nu wrote: > Hello, > > I am experiencing this on 6.8, fully syspatched. > > root@R1():~ # uname -a > OpenBSD R1 6.8 GENERIC.MP#4 amd64 > > The problem is that R1 sends updates with MED set to 0 even though I expect > it not to be. Upon reviewing a tcpdump pcap taken at R2, the MED attribute > is not even included in said update sent from R1. > > This only applies to some, not all updates, in my case it seems to affect > routes where R1 has an ospf discovered nexthop. (172.30.37.2) > > root@R1():~ # route -n get 172.30.37.2 | grep priority > priority: 32 (ospf) > > root@R1():~ # route -n get 172.30.1.110 | grep priority > priority: 8 (static) > > root@R1():~ # bgpctl sh ip bgp neigh R2 out | egrep "172.30.194.[1234]" > * N 172.30.194.1/32 172.30.1.110 100 210 64750 i > * N 172.30.194.2/32 172.30.37.2 100 251 64750 i > * N 172.30.194.3/32 172.30.1.110 100 210 64750 i > * N 172.30.194.4/32 172.30.1.110 100 210 64750 i > > root@R2():~ $ bgpctl sh ip bgp neigh R1 in | egrep "172.30.194.[1234]" > * N 172.30.194.1/32 172.30.1.55 100 210 64660 64750 i > * N 172.30.194.2/32 172.30.1.55 100 0 64660 64750 i > * N 172.30.194.3/32 172.30.1.55 100 210 64660 64750 i > * N 172.30.194.4/32 172.30.1.55 100 210 64660 64750 i
Please remember that MED is not really a transitive attribute. It only hops into an AS but not accross it. So a MED recv from an EBGP session is not forwarded. If the MED is changed (e.g. set med +1 -- maybe set med +0 works as well, don't remember) then the MED will be passed on. >From the output the session between R1 and R2 is EBGP so it very much depends on your filter rules. If the MED was changed by the ruleset it will be sent if not it will be filtered. With the limited information it is not really possible to know. Note, the adj-rib-out output on R1 shows the prefix before the attribute is stripped. Also the ASPATH prepend happens then. -- :wq Claudio
