Re: constant not available everywhere and passing variables from protocols

[Jan Maria Matejka]

> Are there considerations in future to pass bgp_neighbour object to
> filter, to discriminate on neighbor address, ifname, asn, etc? JunOS
> allows this. This would allow me to keep single 'define backup_int =
> "XYZ". On ingress I'd match against protocol, on egress I'd match
> against bgp_neighbour.ifname. So only thing I'd define for
> backup/primary selection is single const, which could be included in a
> single line config file.
> 
> Something like this:
> 
> 
> filter bgp_primary_out {
>   if ifname = "lo" then {
> if bgp_neighbor.ifname = backup_int then bgp_path.prepend(local_as);
> accept;
>   }
>   reject;
> }
> 
> filter bgp_primary_in {
>   if proto = backup_int then bgp_local_pref = 50;
>   if net = default_candidate_net then accept;
>   reject;
> }

Probably yes (or something like that) . See this thread.
http://bird.network.cz/pipermail/bird-users/2018-January/011881.html

>> Anyway, it should be possible to 'define default_candidate_ip = 
>> default_candidate_net.ip;'
>> and then use the constant as IP.
> 
> This works. Curiously won't work if the next-hop is
> default_candidate_net.ip; Actually have to assign own constant to it.

Yes, you have to assign an own constant for it due to current
configuration syntax restrictions. It may change in future.

M.

Re: constant not available everywhere and passing variables from protocols

[Saku Ytti]

On 21 March 2018 at 12:13, Jan Maria Matejka  wrote:

>> Why not? It barfs with 'line 10: IP address expected'
>
> In v1.6.x, nobody implemented it. In v2, it should work.

Thanks, will consider upgrading.

> Try 'import where yourCustomImportFunction(arg1, arg2, arg3, ... argN)'.

Thanks.


Are there considerations in future to pass bgp_neighbour object to
filter, to discriminate on neighbor address, ifname, asn, etc? JunOS
allows this. This would allow me to keep single 'define backup_int =
"XYZ". On ingress I'd match against protocol, on egress I'd match
against bgp_neighbour.ifname. So only thing I'd define for
backup/primary selection is single const, which could be included in a
single line config file.

Something like this:


filter bgp_primary_out {
  if ifname = "lo" then {
if bgp_neighbor.ifname = backup_int then bgp_path.prepend(local_as);
accept;
  }
  reject;
}

filter bgp_primary_in {
  if proto = backup_int then bgp_local_pref = 50;
  if net = default_candidate_net then accept;
  reject;
}


>Anyway, it should be possible to 'define default_candidate_ip = 
>default_candidate_net.ip;'
> and then use the constant as IP.

This works. Curiously won't work if the next-hop is
default_candidate_net.ip; Actually have to assign own constant to it.

-- 
  ++ytti

Re: constant not available everywhere and passing variables from protocols

[Jan Maria Matejka]

On 03/21/2018 10:00 AM, Saku Ytti wrote:
> My config:
> 
> define local_ip  = 129.250.14.127;
> define default_candidate_net = 129.250.0.0/16;
> define default_candidate_ip  = 129.250.0.0;
> define default_net   = 0.0.0.0/0;
> include "common.conf";
> 
> protocol static {
>   route 0.0.0.0/0 recursive default_candidate_ip;
> }
> 
> # ens192
> protocol bgp active from NTT {
>   neighbor 204.141.224.0;
> }
> 
> # ens 224
> protocol bgp backup from NTT {
>   neighbor 204.141.224.2;
> }
> 
> 
> 1) constant not available everywhere
> 
> a) this works
> - define default_candidate_ip  = 129.250.0.0;
> - route 0.0.0.0/0 recursive default_candidate_ip;
> 
> b) this does not
> - define default_route = 0.0.0.0/0;
> - route default_route recursive 129.250.0.0;
> 
> Why not? It barfs with 'line 10: IP address expected'

In v1.6.x, nobody implemented it. In v2, it should work.

> 2) passing variables from protocols
> 
> I'm thinking how to tell which neighbour is backup which is primary. My 
> thoughts
> 
> a) 'import (backup, bgp_in)
> => no way to define >1 filter?
> 
> b) 'bool backup = true'
> => no way to set variables in protocols
> 
> c) 'define backup = true'
> => no way to set constants in protocols
> 
> d) ''import bgp_in(true)'
> => no way to pass variables to filters
> 
> I resorted to matching to protocol name, and call the backup group
> backup. But I'd really prefer way to give neighbour or protocol some
> information I can use in filter to discriminate.

Try 'import where yourCustomImportFunction(arg1, arg2, arg3, ... argN)'.

> Are constants considered strings? If so, should the strings have some
> methods, like split, sub, []? I bit needlessly need to define
> 129.250.0.0 and 129.250.0.0/16 as one is used as static route next-hop
> another is used as filter to permit prefix. I could just maybe say
> 'default_candidate_net.split('/')[0]'.

Try 'default_candidate_net.ip' and 'default_candidate_net.len'. Both of them
are available only in filters.

Anyway, it should be possible to 'define default_candidate_ip = 
default_candidate_net.ip;'
and then use the constant as IP.

M.

constant not available everywhere and passing variables from protocols

[Saku Ytti]

My config:

define local_ip  = 129.250.14.127;
define default_candidate_net = 129.250.0.0/16;
define default_candidate_ip  = 129.250.0.0;
define default_net   = 0.0.0.0/0;
include "common.conf";

protocol static {
  route 0.0.0.0/0 recursive default_candidate_ip;
}

# ens192
protocol bgp active from NTT {
  neighbor 204.141.224.0;
}

# ens 224
protocol bgp backup from NTT {
  neighbor 204.141.224.2;
}


1) constant not available everywhere

a) this works
- define default_candidate_ip  = 129.250.0.0;
- route 0.0.0.0/0 recursive default_candidate_ip;

b) this does not
- define default_route = 0.0.0.0/0;
- route default_route recursive 129.250.0.0;

Why not? It barfs with 'line 10: IP address expected'



2) passing variables from protocols

I'm thinking how to tell which neighbour is backup which is primary. My thoughts

a) 'import (backup, bgp_in)
=> no way to define >1 filter?

b) 'bool backup = true'
=> no way to set variables in protocols

c) 'define backup = true'
=> no way to set constants in protocols

d) ''import bgp_in(true)'
=> no way to pass variables to filters

I resorted to matching to protocol name, and call the backup group
backup. But I'd really prefer way to give neighbour or protocol some
information I can use in filter to discriminate.





Are constants considered strings? If so, should the strings have some
methods, like split, sub, []? I bit needlessly need to define
129.250.0.0 and 129.250.0.0/16 as one is used as static route next-hop
another is used as filter to permit prefix. I could just maybe say
'default_candidate_net.split('/')[0]'.



-- 
  ++ytti