RARE user and assistance email list

[mc36 <>]

hi,
and this is not all.... so this testing framework is very extensible and 
anybody can write it's own test cases.
and a single software forwarding freertr instance can live on as low as 256mb 
of ram and 0.1% cpu. that is, one
can write his own test case modeling his _whole_ network. where it comes to 
the freertr instances, it's an 1-1
copy-paste from the real node's config, when it comes to foreign nodes, they 
can be substituted by freertr instances
also.. assuming the peering edge use case frederic working on, the foreign 
nodes, the network core, can be 1 freertr
instance modeling the network, so it'll be a small, 3-4 node topology... but 
if one is brave enough and goes freetr
only network, he have nothing to do buy copy-paste the live network's config 
to that test case and run the test
before upgrading... assuming a 100node network, it's as low as 26gb of ram 
and not too much cpu cores.... this
25gb could seem high but a single virtual asr9k cannot be started below 16gb 
and eats 200% of cpu because that
can use dpdk dataplane only...
and a bonus, that test case framework can support remote nodes, so one can 
xconnect a real wedge's ports to the
test cases and check if the cooked tofino.bin behaves as expected.... 
moreover, that remote node can be a foreign
node so one can automate black-box testing their cisco/juniper hardware 
before upgrading those nodes...
so yeahhh, testing is important... but does anybody in the industry offer 
anything similar to this? :)
thanks,
cs


On 2/26/21 9:25 AM, Xavier JEANNIN wrote:
> Hello Csaba,
>
> This is great that all these tests are made.
> As our ex-Cisco referee during the EC review said, it is crucial to have a 
> strong and exhaustive validation process.
> It is also important to advertise how the validation process is done to 
> reassure potential new users.
>
> Thank you
> Xavier Jeannin
>
> Le 26/02/2021 à 08:51, mc36 a écrit :
> > On 2/26/21 8:42 AM, mc36 wrote:
> > > On 2/25/21 4:28 PM, mc36 wrote:
> > > > hi,
> >
> >
> > ohhh and forgot to finish the story: so once we ensured that the
> > lib and the rib is populated correctly to the dataplane, there is
> > no reason why the unified/seamless mpls feature would not apply to
> > all the dataplanes, simply because the p4 export tested to be able
> > to export vpns and mpls switching, and no other forwarding techniques
> > are in use...
> >
> > regards,
> > cs