RARE user and assistance email list

[Tim Chown <>]

A brief article explaining the test environment could be both interesting and 
useful, if such a thing doesn’t exist already.

Tim

> On 7 Mar 2021, at 06:52, mc36 <> wrote:
> 
> just a small note, no copy-paste will be needed, i fallen in love with the 
> idea so much that i'll make it happen it soon...:)
> https://github.com/mc36/freeRouter/commit/d79358d026960a54ceb93cd6ff84a0d42763cf44
> 
> 
> On 3/7/21 7:18 AM, mc36 wrote:
>> anyway thinking about it further, once one populates the test case of his 
>> whole network, that test case can
>> be used to validate config changes before applying them to prod.... again, 
>> the whole 100 node net on a 25gb vm! :)
>> On 3/7/21 7:14 AM, mc36 wrote:
>>> 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
>>>>