On Thu, Jan 28, 2021 at 02:51:33PM +0100, open...@kene.nu wrote:
> 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 }
Any route learned via rr1 or rr2 will not pass the MED on to R2 because
the system does not touch the MED and therefor bgpd considers the received
MED from rr1 and rr2 to have originated from outside and so it is excluded
from UPDATES to EBGP peers.
You should add a 'maych from ibgp set med +0' rule which makes MED learned
via IBGP to be considered to be sent out.
> 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
> >
--
:wq Claudio
