Mailing List Archive

IOS XR RPL Matching on neighbor IP/ASN
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IOS XR RPL Matching on neighbor IP/ASN [ In reply to ]
Hi,

On Fri, Nov 19, 2021 at 05:48:56PM +0100, Sascha E. Pollok via cisco-nsp wrote:
> So for example if I have a route-policy on a neighbor-group and would like to announce a
> specific prefix only to one of these neighbors, I would like to be able to do something like:
>
> if (neighbor-asn '12731') then
> # Announce this one prefix only, if receiving neighbor is in ASN 12731
> done
> elseif (neighbor-ip '192.168.1.1') then
> # Announce this one prefix only, if receiving neighbor is 192.168.1.1
> done
> endif

Not sure if that is possible (but I can see why you'd want it).

It might be possible by having something like

neigh 192.168.1.1 address-fam ipv6 u route-policy MyPolicy(192.168.1.1) out

... but I'm not sure you can have an IP address there and compare it
to "something". Numbers should work...

https://lukasz.bromirski.net/docs/prezos/2018-IOS-XR-RPL-CLN.pdf

page 23 and 24 have interesting-looking examples.

(And yes, it means "one extra line of config per neighbour", but that's
still better than "one distinct route-policy per neighbour")

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: IOS XR RPL Matching on neighbor IP/ASN [ In reply to ]
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IOS XR RPL Matching on neighbor IP/ASN [ In reply to ]
Hi,

On Mon, Nov 22, 2021 at 10:02:56AM +0100, Sascha E. Pollok wrote:
> I have actually tried to specify a custom community as a parameter and match against that
> in the route-policy's condition but that didn't work with match-any ($community). The
> parser wouldn't let me commit that.
>
> Do the RPL variables only work for numbers? Then I wouldnt also assume that something like
> match-any (12345:$var) would work?

Haven't tried, but that would be extremely annoying.

The use case I have in mind is using large communities to control
per-peer-AS exports, as in:

<myasn>:0:<yourasn> --> "do not announce to $yourasn"
<myasn>:1:<yourasn> --> "prepend to $yourasn"

and if that cannot be done by RPL parameters, this idea already looks
like "meh, nah, not worth the effort of having hundreds of nearly
identical policies"

route-policy export-to-9999
if match-any community in ( 5539:0:9999 )
then
drop
fi
apply decix-generic
end-policy

*scratch head*

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
Re: IOS XR RPL Matching on neighbor IP/ASN [ In reply to ]
On Mon, 22 Nov 2021 at 11:14, Gert Doering <gert@greenie.muc.de> wrote:

> Haven't tried, but that would be extremely annoying.
>
> The use case I have in mind is using large communities to control
> per-peer-AS exports, as in:
>
> <myasn>:0:<yourasn> --> "do not announce to $yourasn"
> <myasn>:1:<yourasn> --> "prepend to $yourasn"

We need to start rejecting complex DSLs for routing policies. And
start asking for correct solution

a) policy api (e.g. gRPC call, where reply gives actions) - could be
your program running on the router itself, not necessarily centralised
server
b) mruby or lua instead of vendor DSL for policy evaluation - ideally
something >1 vendor will implement

So that the built-in DSL is for simple/naive cases, and operators who
need to implement complex policies across multiple vendors have much
simpler time doing that.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/