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 <[email protected]>
wrote:
> On Thu, Jan 28, 2021 at 12:41:29PM +0100, [email protected] 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
>
