On Tue, Nov 27, 2018 at 06:23:53PM +0100, Claudio Jeker wrote:
> On Tue, Nov 27, 2018 at 04:21:53PM +0100, Job Snijders wrote:
> > On Fri, Nov 23, 2018 at 03:55:18PM +0100, Claudio Jeker wrote:
> > > For origin validation I chacked the source_as in struct rde_aspath
> > > this is not really the right place. It should be in struct aspath
> > > since that holds all the ASPATH related stuff. Change this, move
> > > aspath_match out of util.c back into rde_attr.c and adjust code to use
> > > the cached value also in match from any source-as XYZ rules.
> > > This last bit causes a minor behavioural change since the old code
> > > extracted the last non AS_SET asnumber. The new code follows the ROA
> > > RFC and returns the rightmost AS for AS_SEQUENCE, the local AS for
> > > empty paths and AS_NONE (which is 0) for everything else.
> > > So now 'match from any source-as 0' will return all paths that do not
> > > have a final AS_SEQUENCE segment.
> > > 
> > > The reason for this change is that I don't want to have two different
> > > behaviours for what we call source-as (the one in roa-set and the one on a
> > > filter).
> > 
> > Something is off, it seems 'source-as 0' is matching anything that has
> > an AS_SET attribute set:
> > 
> >     $ bgpctl show rib source-as 0 | head
> >     flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >            S = Stale, E = Error
> >     origin validation state: N = not-found, V = valid, ! = invalid
> >     origin: i = IGP, e = EGP, ? = Incomplete
> > 
> >     flags ovs destination          gateway          lpref   med aspath 
> > origin
> >     I*>     N 5.39.176.0/21        192.147.168.1      100     0 2914 8530 { 
> > 198753 } ?
> >     I*>     N 5.101.110.0/24       192.147.168.1      100     0 2914 14061 
> > { 46652 } i
> >     I*>     N 5.175.0.0/19         192.147.168.1      100     0 2914 1299 
> > 20773 { 8972 } i
> >     I*>     N 8.41.202.0/24        192.147.168.1      100     0 2914 13789 
> > 30372 { 40179 } i
> > 
> > Similarly, this should return at least 5.39.176.0/21:
> > 
> >     $ bgpctl show rib source-as 8530
> >     flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >            S = Stale, E = Error
> >     origin validation state: N = not-found, V = valid, ! = invalid
> >     origin: i = IGP, e = EGP, ? = Incomplete
> > 
> >     flags ovs destination          gateway          lpref   med aspath 
> > origin
> >     I*>     N 80.87.16.0/20        192.147.168.1      100     0 2914 8530 ?
> >     I*>     N 87.236.128.0/21      192.147.168.1      100     0 2914 8530 ?
> >     I*>     N 88.151.152.0/21      192.147.168.1      100     0 2914 8530 ?
> >     I*>     N 89.38.120.0/21       192.147.168.1      100     0 2914 8530 i
> >     I*>     N 93.115.176.0/20      192.147.168.1      100     0 2914 8530 i
> >     I*>     N 185.52.144.0/22      192.147.168.1      100     0 2914 8530 ?
> > 
> 
> I implemented source-as the way ROA is defining it. So anything which ends
> with a AS_SET will return AS_NONE (which is 0). OpenBGPD has no way to
> have an AS_PATH that has a real 0 in the AS_PATH (those UPDATES are
> treated as withdraw). Because of this also the 5.39.176.0/21 is no longer
> matching in 'bgpctl show rib source-as 8530'.

I'm not sure it should behave that way.

'bgpctl show rib source-as 8530' really ought to return prefixes like
80.87.16.0/20 but also 5.39.176.0/21.

> I'm a bit on the edge here about where to go and currently prefer to
> follow a RFC (which in this case is RFC6811).
> 
>  o  Route Origin ASN: The origin AS number derived from a Route as
>     follows:
> 
>     *  the rightmost AS in the final segment of the AS_PATH attribute
>          in the Route if that segment is of type AS_SEQUENCE, or
> 
>     *  the BGP speaker's own AS number if that segment is of type
>        AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty,
>        or
> 
>     *  the distinguished value "NONE" if the final segment of the
>        AS_PATH attribute is of any other type.
> 
> As mentioned above I found it strange when behaviour is different because
> of where it is used.

RFC 6811 describes how BGP Origin Validation should be performed, but is
not a guideline how to treat AS_SETs in general or how CLIs should
function. Perhaps 'source-as 0' should just throw an error in all
contexts (both bgpd.conf and bgpctl), since 0 can never be in an AS_SET
or AS_SEQUENCE. Perhaps we shouldn't overload the number.

1/ Maybe 'source-as self' or 'source-as none' can be used to match all
routes originated by the AS in which this bgpd instance runs.

2/ Similarly, the program could be made so that 'AS 15562' (lets use
15562 as example) from the Global Configuration passed on to bgpctl and
used in the filter ruleset means both "what is originated by 15562" and
also what is originated in the own AS (and doesn't have AS_PATH yet, but
we know the router runs in 15562 because of the global config parameter).

Kind regards,

Job

Reply via email to