On Tue, Nov 27, 2018 at 06:55:51PM +0100, Job Snijders wrote:
> 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.
But isn't this different from other implementations? At least I would
expect that the AS-path regex '8530$' would not match on the AS_SET path
either. My issue is that we have 'source-as' in roa-set, origin-set and on
filters in bgpd.conf plus the source-as used by bgpctl. Depending on
context they behave differently. So if AS 8530 is in the roa-set
and I do bgpctl show rib source-as 8530 the result will be different to
what would match in the roa-set.
We already had a lot of confusion about announce and that is why I decided
to make them behave the same.
> > 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.
The overloading is done to simplify some internals. It is indeed possible
to disallow direct use of 0 in bgpctl and replace it with 'none'. On the
other hand it seems people are used to write belt&suspenders like configs
where filter rules (e.g. deny form any AS 0) are added which are not needed.
> 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.
'source-as self' and 'source-as none' are two different things in my
opinion. The empty AS path case is convered by 'empty-as' in the filters
and introducing 'source-as none' with a different meaning then the one
used by RFC6811 will not imporve anything.
> 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).
This is the behaviour with this diff:
bgpctl show rib source-as 196618
flags ovs destination gateway lpref med aspath origin
AI*> N 10.12.12.0/24 0.0.0.0 100 0 i
AI*> N 10.12.13.0/24 0.0.0.0 100 0 i
196618 is the AS of this instance.
I see two different discussion points here. Or two distinct behaviour
changes that get introduced by this diff:
1/ source-as behaviour for empty AS_PATH. With this diff 'source-as $myAS'
will match for empty AS_PATH. In my opinion this makes sense but the
interaction with empty-as should be reconsidered. (e.g. are people
currently using both forms to achieve different behaviour in their own
AS).
2/ source-as handling of AS_PATH that end with an AS_SET (bgpd currently
does not support any other segment type). Here there is two things:
a) should 'source-as 8530' match for the path with the AS_SET e.g:
2914 8530 { 198753 }
Should we really consider AS 8530 being the source of that prefix?
What about 198753?
b) handling of 'source-as 0' ideally this should be disallowed and
instead 'source-as none' introduced. Which would then collect all
the AS_SET paths from above. b) depends on the outcome of a)
As mentioned above the idea of making source-as behave like the source-as
in roa-set for consitency is my reason but if people think the current
behaviour has to be preserved (with the behaviour difference between
source-as usage) then that is fine and I will adjust the diff.
--
:wq Claudio
