Hello Claudio,
Thank you for the clarification. Your suggestion works splendidly.
On Thu, Jan 28, 2021 at 3:12 PM Claudio Jeker <cje...@diehard.n-r-g.com>
wrote:
> 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
>
