Rare project developers

[mc36 <>]

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