Rare project developers

[Alexander Gall <>]

On Tue, 30 Nov 2021 20:59:08 +0100, Frederic LOUI <> 
said:

> As you have the Nix distribution you'll have to wait Alex to add today's 
> version to RARE/freeRtr Nix based release manager.

Carmen, you should get the new version running with

# /nix/var/nix/profiles/RARE/bin/release-manager --install-git origin/master 
--auto-switch

-- 
Alex

> All the best,
> Frédéric

> Le 30 nov. 2021 15:43, mc36 <> a écrit :

>     hi,
>     it was a bit bigger one but a good pokemon to catch... :)
>     
> https://github.com/mc36/freeRouter/commit/f491e34217fed441a94cfa38dbefbb5c87313390
>     now some testing then it should be out by at tomorrow morning...
>     if your switch have internet access then issue "flash upgrade"...
>     if not, then you'll have to manually upgrade rtr.jar from 
> freertr.net/rtr.jar...
>     regards,
>     cs

>     On 11/30/21 14:07, mc36 wrote:
>> hi,
>> so exporting the masks was easy-peasy:
>> https://github.com/mc36/freeRouter/commit/b77d1d537da0500b93c7efb2a4a6df1d0b5440b9
>> now the more entries will follow...
>> regards,
>> cs
>> 
>> 
>> 
>> On 11/30/21 13:56, mc36 wrote:
>>> hi,
>>> so it's an issue how freerouter exports the acls...
>>> at the moment, only the first rule is exported...
>>> the dataplanes have no limitation at all, they could
>>> accommodate arbitrary combinations...
>>> when this was done, i was thinking on how it could be done
>>> with a single match-action table, and allowing any mix of permit/deny...
>>> then soon i figured out that if we would want to keep the single table
>>> approach then only one can work.. keeping permit/deny or allowing more
>>> entries to be exported... here is a sample showing the issue with both:
>>> 
>>> access-list acl1
>>> deny all any all any all flow 11-111
>>> permit all any all any all flow 0-1111
>>> 
>>> access-list acl2
>>> permit all any all any all flow 22
>>> 
>>> so if it would be exported sequentially, then packets with flow 22
>>> would match on the first acl, and as the action is already taken,
>>> the asic would not examine the table further... so for this to work
>>> correctly, two tables would be needed... but from this example, it's
>>> easy to any number of acls that needs more and more tables to work...
>>> 
>>> but imho, keeping these in mind, it would be much nicer if freerouter
>>> at least tries to export not just the first entry, and drop a warning
>>> when it encounters an invalid combination.... afterall it's not a big
>>> deal so imho i'll jump into this soon...
>>> 
>>> regards,
>>> cs
>>> 
>>> ps: the same could be observed with asr9k and policy-maps:
>>> 
>>> 
>>> 
>>> RP/0/RP0/CPU0:a7a(config)#show configuration
>>> Tue Nov 30 12:48:51.042 UTC
>>> Building configuration...
>>> !! IOS XR Configuration 7.3.2
>>> ipv4 access-list a1
>>> 10 deny icmp any any
>>> 20 permit ipv4 any any
>>> !
>>> !
>>> class-map match-any cm1
>>> match access-group ipv4 a1
>>> end-class-map
>>> !
>>> !
>>> policy-map pm1
>>> class cm1
>>> police rate 100000 bps
>>> !
>>> !
>>> class class-default
>>> !
>>> end-policy-map
>>> !
>>> interface GigabitEthernet0/0/0/1
>>> service-policy output pm1
>>> !
>>> end
>>> 
>>> RP/0/RP0/CPU0:a7a(config)#commit
>>> Tue Nov 30 12:48:54.422 UTC
>>> 
>>> % Failed to commit one or more configuration items during a pseudo-atomic 
>>> operation. All changes made have been reverted. Please
>     issue 'show configuration failed [inheritance]'
>>> from this session to view the errors
>>> RP/0/RP0/CPU0:a7a(config)#show configuration failed
>>> Tue Nov 30 12:48:57.524 UTC
>>> !! SEMANTIC ERRORS: This configuration was rejected by
>>> !! the system due to semantic errors. The individual
>>> !! errors with each failed configuration command can be
>>> !! found below.
>>> 
>>> 
>>> interface GigabitEthernet0/0/0/1
>>> service-policy output pm1
>>> !!% 'sunstone-km' detected the 'warning' condition 'Deny ace not 
>>> supported in access-list'
>>> !
>>> end
>>> 
>>> RP/0/RP0/CPU0:a7a(config)#
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 11/30/21 13:36, Carmen Misa Moreira wrote:
>>>> Hi Csaba,
>>>> 
>>>> Thanks, that was one of my first thoughts :)
>>>> 
>>>> Also, I noted that the PBR is executed on the first PBR declared, for 
>>>> example:
>>>> 
>>>> ipv6 pbr inet sequence 10 ipv6_flowlabel_10 inet nexthop fc01:10::2
>>>> 
>>>> ipv6 pbr inet sequence 20 ipv6_flowlabel_20 inet nexthop fc01:10::2
>>>> 
>>>> ipv6 pbr inet sequence 30 ipv6_flowlabel_30 inet nexthop fc01:10::2
>>>> 
>>>> Will works for the first one, it will route to fc01:10::2 all the 
>>>> traffic label with fl=10 but not for fl=20 and 30
>>>> 
>>>> BUT
>>>> 
>>>> If I change the order in the declaration, for example to this one:
>>>> 
>>>> ipv6 pbr inet sequence 10 ipv6_flowlabel_20 inet nexthop fc01:10::2
>>>> 
>>>> ipv6 pbr inet sequence 20 ipv6_flowlabel_10 inet nexthop fc01:10::2
>>>> 
>>>> ipv6 pbr inet sequence 30 ipv6_flowlabel_30 inet nexthop fc01:10::2
>>>> 
>>>> It will route to fc01:10::2 all the traffic label with fl=20 but not for 
>>>> fl=10 and 30
>>>> 
>>>> There is some priority in the declaration? Or maybe it can be only one 
>>>> PBR declaration per link?
>>>> 
>>>> Thanks for your time!
>>>> 
>>>> Best regards,
>>>> 
>>>> Carmen Misa
>>>> 
>>>> 
>>>> On 30.11.21 13:15, mc36 wrote:
>>>>> hi,
>>>>> at the moment of writing, the p4 dataplanes can only match against a 
>>>>> single flow label...
>>>>> adding ranges could be done but as far as i know should be avoided, at 
>>>>> least on tofino....
>>>>> but on the other hand, the p4 code currently matches against masks on 
>>>>> flowlabel, but
>>>>> as i've seen in freerouter it does not yet takes advantage of this when 
>>>>> exporting.... :)
>>>>> regards,
>>>>> cs
>>>>> 
>>>>> 
>>>>> On 11/30/21 13:07, Carmen Misa Moreira wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> I see something weird in my access-list declarations...
>>>>>> 
>>>>>> If I declare the access-list like this (just with a single value) it 
>>>>>> works:
>>>>>> 
>>>>>> access-list ipv6_flowlabel_10
>>>>>> sequence 10 permit all any all any all flow 10
>>>>>> exit
>>>>>> 
>>>>>> But if I declare it with a range of values, it doesn't work:
>>>>>> 
>>>>>> access-list ipv6_flowlabel_10
>>>>>> sequence 10 permit all any all any all flow 10-20
>>>>>> exit
>>>>>> 
>>>>>> There is one example on the FreeRtr self-test but is using 
>>>>>> access-group-in: http://sources.nop.hu/cfg/crypt-acl72.tst
>>>>>> 
>>>>>> I was wondering if there is a limitation to match just a single flow 
>>>>>> label value in the access-list.
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Carmen Misa
>>>>>>