[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.