Rare project developers

[Frederic LOUI <>]

Hi Carmen,

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

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