[j-nsp] Parameters/variables in policy-statements

[Jason Lixfeld]

Hey there,

I’m somewhat green to JunOS coming from a primarily IOS/IOS XR background. IOS XR’s route-policy language supports the use of variables, or parameters, which essentially allows me to create a template that accepts some variables, and adjust the parameters that set those variables at various levels in the config.

For example:

!
route-policy GLOBAL-POLICY($LP, $MED, $SERVICE)
set local-preference $LP
set med $MED
set community (21949:$SERVICE) additive
end-policy
!
route-policy IXP-OUT($IXP, $IXP_RTBH_ASN, $IXP_RTBH_ID)
apply GLOBAL-FILTER
if community matches-any ANNOUNCE--UPSTREAM then
pass
if community matches-any (21949:666) then
set community ($IXP_RTBH_ASN:$IXP_RTBH_ID)
done
elseif community matches-any (21949:2000) then
drop
elseif community matches-any (21949:$IXP) then
drop
else
delete community all
done
endif
drop
endif
end-policy
!
route-policy IXP-IN($IXP, $LP, $MED, $SERVICE)
set community (21949:$IXP)
apply GLOBAL-FILTER
apply GLOBAL-POLICY($LP, $MED, $SERVICE)
end-policy
!
neighbor-group IXP-V4
address-family ipv4 unicast
route-policy IXP-IN($IXP, $LP, $MED, $SERVICE) in
maximum-prefix 100000 90 restart 5
route-policy IXP-OUT(2010, 0, 0) out
!
!
…
…
…
neighbor 1.2.3.4
remote-as 1234
use neighbor-group IXP-V4(2010, 390, 0, 2000)
neighbor 2.3.4.5
remote-as 2345
route-policy IXP-V4(2020, 190, 0, 3000) in
route-policy IXP-OUT(2020, 2345, 666) out
…
…


I don’t believe JunOS supports the same functionally directly, so I think I’d have to use commit scripts to accomplish something similar. As I’m trying to familiarize myself with it all, I can’t seem to determine the various ways that the parameters could be pulled from the config for the commit scripts to utilize.

2 possibilities come to mind:

- Create a BGP group for each different set of parameter combinations and have the commit script set parameters for the neighbor based on what group they are in.
or,
- Come up with a standard convention for defining the neighbor description, such that the parameters could be encoded into the description. The commit script could then set parameters based on the values in the appropriate positions within the description.

Both of these seem somewhat complex, but perhaps only because they are unfamiliar. Are there other ways of doing this that might prove to be (more) effective?

Thanks in advance.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/ju

[Saku Ytti]

Hey,

Post by Jason Lixfeld
- Create a BGP group for each different set of parameter combinations and have the commit script set parameters for the neighbor based on what group they are in.
or,
- Come up with a standard convention for defining the neighbor description, such that the parameters could be encoded into the description. The commit script could then set parameters based on the values in the appropriate positions within the description.
Both of these seem somewhat complex, but perhaps only because they are unfamiliar. Are there other ways of doing this that might prove to be (more) effective?

My recommendation is to minimally rely on vendor tooling, generate
entire configuration offline and you have same tooling, same logic
available to every current and future platform, making changing vendor
much OPEX friendlier process.

The issue what you explain is real, and you can dig yourself to
similar hole going to opposite way from JunOS to IOS-XR, by relying
heavily on apply-groups and apply-paths (IOS-XR groups are inferior
and cannot express same things).
I'm sure similarly we can see any V1=>V2 transition being complicated
and expensive when we heavily commit on V1 specific tooling.

Not the answer you probably wanted, but I think network engineers
really need to start embracing less CLI-jockey and more centralised
logic.

[Jason Lixfeld]

Post by Saku Ytti
Not the answer you probably wanted, but I think network engineers
really need to start embracing less CLI-jockey and more centralised
logic.

I agree whole heartedly, and that is a work currently in progress. However until then, here we are :)
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp