In my case MED is changed with +<value> on every eBGP hop. I use it to calculate the total MED over several hops to decide the best path from a latency point of view.
My intention with listing the advertised prefix from R1 was to show that there is a MED present. As per the tcpdump I did, the MED attribute is not included in the BGP update packets. This I have confirmed is the case for all prefixes on R1 that has an iBGP nexthop. Any prefixes that in R1 has an eBGP nexthop advertises MED as expected. The "bgpd -vn" for R1: AS 64660 router-id 172.30.37.1 socket "/var/run/bgpd.sock.0" holdtime 9 rde med compare always nexthop qualify via bgp prefix-set "internal" { <snip> } rde rib Adj-RIB-In no evaluate rde rib Loc-RIB rtable 0 fib-update yes neighbor 172.30.1.54 { descr "R2" remote-as 64840 enforce neighbor-as yes enforce local-as yes announce IPv4 unicast } group "rr" { neighbor 172.30.37.25 { descr "rr1" remote-as 64660 local-address 172.30.37.1 enforce neighbor-as no enforce local-as yes announce IPv4 unicast } neighbor 172.30.37.39 { descr "rr2" remote-as 64660 local-address 172.30.37.1 enforce neighbor-as no enforce local-as yes announce IPv4 unicast } } deny from any deny to any allow to ebgp prefix-set "internal" allow to ibgp prefix-set "internal" allow from ebgp prefix-set "internal" allow from group "rr" prefix-set "internal" match to ibgp set { nexthop self } match from 172.30.1.54 set { metric +23 } On Thu, Jan 28, 2021 at 2:01 PM Claudio Jeker <cje...@diehard.n-r-g.com> wrote: > 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 >