Re: bgpd not including MED attribute on updates
Hello Claudio,
Thank you for the clarification. Your suggestion works splendidly.
On Thu, Jan 28, 2021 at 3:12 PM Claudio Jeker
wrote:
> On Thu, Jan 28, 2021 at 02:51:33PM +0100, open...@kene.nu wrote:
> > In my case MED is changed with + 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" {
> >
> > }
> >
> > 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
> > 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.55100 210 64660
> 64750
> > > i
> > > > * N 172.30.194.2/32 172.30.1.55100 0 64660
> 64750
> > > i
> > > > * N 172.30.194.3/32 172.30.1.55100 210 64660
> 64750
> > > i
> > > > * N 172.30.194.4/32 172.30.1.55100 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
>
Re: bgpd not including MED attribute on updates
On Thu, Jan 28, 2021 at 02:51:33PM +0100, open...@kene.nu wrote:
> In my case MED is changed with + 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" {
>
> }
>
> 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
> 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.55100 210 64660 64750
> > i
> > > * N 172.30.194.2/32 172.30.1.55100 0 64660 64750
> > i
> > > * N 172.30.194.3/32 172.30.1.55100 210 64660 64750
> > i
> > > * N 172.30.194.4/32 172.30.1.55100 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
Re: bgpd not including MED attribute on updates
In my case MED is changed with + 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" {
}
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
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.55100 210 64660 64750
> i
> > * N 172.30.194.2/32 172.30.1.55100 0 64660 64750
> i
> > * N 172.30.194.3/32 172.30.1.55100 210 64660 64750
> i
> > * N 172.30.194.4/32 172.30.1.55100 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
>
Re: bgpd not including MED attribute on updates
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.55100 210 64660 64750 i > * N 172.30.194.2/32 172.30.1.55100 0 64660 64750 i > * N 172.30.194.3/32 172.30.1.55100 210 64660 64750 i > * N 172.30.194.4/32 172.30.1.55100 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
bgpd not including MED attribute on updates
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.55100 210 64660 64750 i * N 172.30.194.2/32 172.30.1.55100 0 64660 64750 i * N 172.30.194.3/32 172.30.1.55100 210 64660 64750 i * N 172.30.194.4/32 172.30.1.55100 210 64660 64750 i
