Skip to Content.
Sympa Menu

rare-dev - [rare-dev] Fwd: eantc interops --- was: Re: BGP CT interop - Colorful Resolution

Subject: Rare project developers

List archive

[rare-dev] Fwd: eantc interops --- was: Re: BGP CT interop - Colorful Resolution


Chronological Thread 
  • From: mc36 <>
  • To: Frédéric LOUI <>, Alexander Gall <>
  • Cc: Simon Leinen <>, "" <>
  • Subject: [rare-dev] Fwd: eantc interops --- was: Re: BGP CT interop - Colorful Resolution
  • Date: Wed, 15 Mar 2023 09:42:32 +0100

"


and well, that kernel already have 3 serious cve and we're seemingly unable
get rid of that... :(

and if the mgmt port was owned by freerouter then i would not given a shit as
we only need pcap and jvm and boths are acceptable level...



"


any opinion??


-------- Forwarded Message --------
Subject: eantc interops --- was: Re: [rare-dev] BGP CT interop - Colorful
Resolution
Date: Wed, 15 Mar 2023 07:22:52 +0100
From: mc36 <>
To: , Kaliraj Vairavakkalai <>, Natrajan
Venkataraman <>
CC: Krzysztof Szarkowicz <>, Anton Elita <>, Reshma Das <>, Carsten Rossenhoevel <>, Alexander Gall <>, Moh csi J nos <>, <>, Farkas Istv n <>, Visky Bal zs <>, Carmen Misa Moreira <>, Maxime Debrabander (mdebraba) <>, Swadesh Agrawal (swaagraw) <>, Dhananjaya Rao (dhrao) <>

thanks for the repeated question, tldr: no way i go back

every of my shitload randomzies everything you know already and i refuse to
change this....



and they just failed to open up their shitload somehow...

if it was me i simply created a clear unpassworded && unfiltered ssid in 5
seconds

and a clear && unfiltered mgmt vlan in another 5m and connect the two in just
another 5 seconds...



they simply were pretty unfriendly && unwelcoming all the way....

and i saw the signs from the beginning... they double-quoted "mc36" several
times

and i had to wait almost a month to get my mp.ls domain accredited to an mpls
world congress??? :)

and i obviously fully locked my mgmt port as we're on a 3 years old kernel as
frederic decided that it must be a linux hackable box... :)

well yess but we had way too much chinese hackers on-site and they
beep-booped a way too loud and frequent 4 me....



and well, that kernel already have 3 serious cve and we're seemingly unable
get rid of that... :(

and if the mgmt port was owned by freerouter then i would not given a shit as
we only need pcap and jvm and boths are acceptable level...



and in the meantime my very internal rr1.net.nop.hu got compromised
somehow.... frederic and tibi knew my hashes...

so for me, enough is enough now, i rebooked my plane to today 12:00
cet+0100...



first i'll rebuild my whole infra in 1-2 weeks and i'll introduce t-otp as
the primary auth method and just a fallback to hashes....



after that i'll rule out from the dd-s that it was tibi or frederic who kept
pulling my dick up&down without swallowing... :)

next i'll ask kifu && frederic to do a tacacs or radius federation... we'll
see who will play nicely, you know....



in the long run i'll close the rare builds' mgmt to freertr, if the team
agrees.... :)

if freerouter owned the mgmt-eth then i would not had to be stick to the
free-open-unrestrcited internet access... :)

obviously it still would be a way too annoying, but then i would be able to
participate remotely from my hotel...





back to your question: now as you see im given it up completely as ive a tons
of shitload to do, so you're alone...



you already have the patches, please bring up a the latest freertr.org's vmdk
in your juniper infra...

in software forwarding imho it should be line rate for the planned 1gbps
measurement...

it'll jitter a lot but not that much, please measure && report if you can...
:)



if it still not enough, you can proceed to the end of freertr.org to activate
the p4emu dataplane...

it should run on everything, and a way smoother on jitter... if thats still
not enough then you can revert to

the software forwarding (drop the vmdk and start from stract!) and then we
can have a small vc where i'll

help you bring up the dpdk dataplane in 5-10 minutes for your very specific
vm situation...



it's just a little bit different than the pcap dataplane but activating dpdk
is hard to automate....

my defaults will be still a way too "green" to have 0 jitter but there are
knobs that disable that, you know.... :)

alex && carmen started to script that properly a year ago and still not too
much success... :(




and in the meantime, there is an other thing that you should know about....
yesterday i had to cancel

my cisco bgp-car vc.... im curious if we can have anything with those guys
too.... :)

and also in the meantime, cisco is checking why my shitload srv6 does not
interop with them....

according to the lateest news from them, they spotted a config issue in my
test setup and checking

with their development team why they leak packet to the core interface
unencapsulated whereas

according to cef, it should not happen.... if they proceed a bit, then imho
you can also participate

freerouter in the srv6 room.... it was me personally who ticked that we're
interested a low prio....

srv6 is way too bloated for me, on small customer packets it halves the
bandwidth you know.....

if i succeed with my case then all the dataplane have already layer2 &&
layer3 vpns ready...



regarding my fully remote participation, when they first sent me the
microsoft url i saw that it wont work...

it's 2023 and microsoft's shitload still not works on a linux desktop with
firefox?

and i clearly refuse to use chrome as they store their passwords to the
gcloud....

and imho they're abusing some dirty google tricks but --ofkoz noone knows...
:)

and i also dont trust degooging by random hackers on the internet, every time
i activated

lineage without gapps, it kaboomed the battery in a week, even in a 6 months
old phone...













































On 3/15/23 05:15, Kaliraj Vairavakkalai wrote:
please let us know if you find anything else or need any other help to show
them the 2nd interop?

Csaba, we need the EANTC interop to succeed. Is it possible to make that
happen?

Will you be able to join remotely? Or can someone else available on site help?

Nats and Reshma have registered for EANTC and got access.

We were trying to work with other GEANT participants on site (Simon?) and try
to

save the event. But Anton could not reach Simon, I believe, to wire up the
topology.

If we can have someone from GEANT work with Anton, and us to save the
EANTC

interop event, that would be great. Nats can show the same IETF demo topology

at EANTC too. We just need some on the ground support from GEANT.

Thanks,

Kaliraj

*From: *Natrajan Venkataraman <>
*Date: *Tuesday, March 14, 2023 at 9:01 PM
*To: *mc36 <>, <>
*Cc: *Krzysztof Szarkowicz <>, Anton Elita <>,
Reshma Das <>, Kaliraj Vairavakkalai <>
*Subject: *Re: [rare-dev] BGP CT interop - Colorful Resolution

Hi Csaba,

Sure! Yes, we are very happy with the fixes you have committed for FreeRTR and we have a pretty solid demo. I am composing a list of observed behavior w.r.t CT colorful resolution vs the expected BGP-CT draft behavior. I will share the same with you by PDT morning tomorrow. It is with respect to advertisement behavior and VRF forwarding behavior based on what configuration exists in the VRF definition. This will help us stay ahead of the InterOp report that is expected from IETF which, we can prepare together as we progress further.

Thanks in advance and stay tuned!

-Nats-

*From: *mc36 <>
*Date: *Tuesday, March 14, 2023 at 8:47 PM
*To: *Natrajan Venkataraman <>,
<>
*Cc: *Krzysztof Szarkowicz <>, Anton Elita <>,
Reshma Das <>, Kaliraj Vairavakkalai <>
*Subject: *Re: [rare-dev] BGP CT interop - Colorful Resolution

[External Email. Be cautious of content]


thank you so much for the feedback...

happy to hear that now you can demo something?

please let us know if you find anything else or need any other help to show
them the 2nd interop?

thx,

cs

On 3/14/23 19:50, Natrajan Venkataraman wrote:
Hi Csaba,

ps: have you validates my sitload fix 4 the excessive bgp update?

I have verified the fix. The fix is working fine.

Thanks,

-Nats-

*From: *mc36 <>
*Date: *Monday, March 13, 2023 at 11:08 AM
*To: * <>
*Cc: *Natrajan Venkataraman <>, Krzysztof Szarkowicz
<>, Anton Elita <>, Reshma Das
<>
*Subject: *Re: [rare-dev] BGP CT interop - Colorful Resolution

*[External Email. Be cautious of content]*

we failed to upgrade the asic.... reason: no clearnet access on the venue....
;(

maybe in prage?

ps: have you validates my sitload fix 4 the excessive bgp update?

thx

cs

Get BlueMail for Android <https://urldefense.com/v3/__https:/bluemail.me__;!!NEt6yMaO-gk!Gx5_nVeLfwBMpUFVtAyF3EZXMGRlAWrcXqgTCnIg69vtpH8R-96HuDUlGJNB5Rmz8_LYJg$
<https://urldefense.com/v3/__https:/bluemail.me__;!!NEt6yMaO-gk!Gx5_nVeLfwBMpUFVtAyF3EZXMGRlAWrcXqgTCnIg69vtpH8R-96HuDUlGJNB5Rmz8_LYJg$>>

On Mar 11, 2023, at 03:22, Kaliraj Vairavakkalai <
< <>>> wrote:

Hi Csaba,

Sorry for the delay in response.

We are OK with what you and Anton are comfortable with for the EANTC
demo.

For the IETF demo, we plan to use resolving BGP-CT routes over
RSVP-TE tunnels,

using the virtual VM environment. Natz has that working.

It would have been good to use RSVP-TE tunnel for EANTC also. But if
that s not

possible because of hardware limitation...

wait, one question/thought:

>now it uses only 2 labels everywhere so the outer label is the
color, the inner is the service...
>because of dataplane limitations (only 2 labels in hw)

What if we do Internet(IPv4-Unicast) as the service instead of L3VPN?

Then with just two labels (CT label and RSVP-TE label), will it be
possible

to demonstrate IPv4-Unicast traffic resolving over BGP-CT interdomain
LSP?

It will be two labels intra-domain, and one label on inter-AS link.

Thanks,

Kaliraj

*From: *mc36 <>
*Date: *Tuesday, March 7, 2023 at 11:24 PM
*To: *Kaliraj Vairavakkalai <>, Natrajan Venkataraman
<>, <>, Krzysztof
Szarkowicz
<>, Anton Elita <>
*Cc: *Reshma Das <>
*Subject: *Re: [rare-dev] BGP CT interop - Colorful Resolution

[External Email. Be cautious of content]


hi,

please find attached the final topology we'll go on the demo...

r3-r4-r5 are the nodes to look at, now no ugly route-policy at all,

just pure rt-import/export magic everywhere plus the new afi-vrf xxx
set-vrf knob...

in the freerouter asn i keep a bgp-ctp session and no isis nor ldp...

now it uses only 2 labels everywhere so the outer label is the color,
the inner is the service...

because of dataplane limitations (only 2 labels in hw) we'll go with
this config at the plugfest!

thanks,
cs



On 3/3/23 12:01, mc36 wrote:
> hi, guys,
>
> imho from now, freerouter have cheat-less colorful resolution for
vpnv4/vpnv6 afis:
>
>
https://urldefense.com/v3/__https://github.com/rare-freertr/freeRtr/commit/335d83792d7123ca164691f124ceab71a98e21b9__;!!NEt6yMaO-gk!HEBLz8ryW8TQ-i7tWo_ne8DbLM3pL0_M3_g8ldQFRe73AjncdILqnDG-T-c-4U0CF8Izd-f7$

<https://urldefense.com/v3/__https:/github.com/rare-freertr/freeRtr/commit/335d83792d7123ca164691f124ceab71a98e21b9__;!!NEt6yMaO-gk!HEBLz8ryW8TQ-i7tWo_ne8DbLM3pL0_M3_g8ldQFRe73AjncdILqnDG-T-c-4U0CF8Izd-f7$>

<https://urldefense.com/v3/__https:/github.com/rare-freertr/freeRtr/commit/335d83792d7123ca164691f124ceab71a98e21b9__;!!NEt6yMaO-gk!HEBLz8ryW8TQ-i7tWo_ne8DbLM3pL0_M3_g8ldQFRe73AjncdILqnDG-T-c-4U0CF8Izd-f7$

<https://urldefense.com/v3/__https:/github.com/rare-freertr/freeRtr/commit/335d83792d7123ca164691f124ceab71a98e21b9__;!!NEt6yMaO-gk!HEBLz8ryW8TQ-i7tWo_ne8DbLM3pL0_M3_g8ldQFRe73AjncdILqnDG-T-c-4U0CF8Izd-f7$>>
>
> unfortunately this contains a smaller refactoring also, i just
forgot to commit that beforehand... :)
>
>
> the code is still not covered by a test case, that will be the next,
>
> then i'll get back to you with a new topology for the plugfest...
>
> happy weekend,
> thanks,
> cs
>
> sid#show config-differences
> router bgp4 65535 vrf v1
> afi-vrf niif set-vrf v2 ipv4
> exit
>
> sid#clear ipv4 bgp 65535 all in vpnuni
> sid#show ipv4 route niif | first 10
> typ prefix
metric
iface hop
time
> B 0.0.0.0/0
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.0.0.0/9
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.23.88.0/24
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.23.89.0/24
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.23.92.0/23
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.23.94.0/23
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.35.69.0/24
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.38.0.0/21
200/0
null@v2:4 10.10.10.25 00:00:02
> B 4.38.8.0/21
200/0
null@v2:4 10.10.10.25 00:00:02
>
> sid#configure revert
> 1: router bgp4 65535 vrf v1
> 2: no afi-vrf niif
set-vrf v2 ipv4
> 3: exit
>
> errors=0
>
> router bgp4 65535 vrf v1
> afi-vrf niif set-vrf v2 ipv4
> exit
>
> sid#clear ipv4 bgp 65535 all in vpnuni
> sid#show ipv4 route niif | first 10
> typ prefix
metric
iface hop
time
> B 0.0.0.0/0
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.0.0.0/9
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.23.88.0/24
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.23.89.0/24
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.23.92.0/23
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.23.94.0/23
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.35.69.0/24
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.38.0.0/21
200/0
null@v1:4 10.10.10.25 00:00:02
> B 4.38.8.0/21
200/0
null@v1:4 10.10.10.25 00:00:02
>
> sid#
>
>
>
> On 2/28/23 23:21, mc36 wrote:
>> hi,
>>
>> On 2/28/23 22:39, Kaliraj Vairavakkalai wrote:
>>> That s cool. So now we have two demo setups:
>>>
>>> 1/ Csaba s setup with FreeRTR as Ingress-PE doing
colorful resolution.
>>>
>>> 2/ Natz setup with FreeRTR as ASBR doing colorful resolution.
>>>
>>> We could have a combo of the two setups, to show FreeRTR in both
ASBR and ingress-PE roles. ;)
>>>
>>
>> well, for a really really proper color resolution imho i need to introduce
the "afi-vrf cust-blue resolve-in core-blue" knob...
>> it'll simply set the route's underlaying table like when we need
to send out a vrf packet in mpls in the core vrf, but here,
>> it'll a per vrf override that i'll set that paramter to a user
defined table... no fallback yet, just a static mechanism...
>> that'll be the first tomorrow what i'll start playing with... :)
>>
>>
>>> Just some comments -
>>>
>>> It s worth noting that:
>>>
>>> route-policy ibgp-in
>>>
>>> sequence 10
if extcomm 2562:0:100
>>>
>>> sequence 20
set vrf v2 ipv4
>>>
>>> sequence 30
pass
>>>
>>> sequence 40
enif
>>>
>>> sequence 50
if extcomm 2562:0:200
>>>
>>> sequence 60
set vrf v3 ipv4
>>>
>>> sequence 70
pass
>>>
>>> sequence 80
enif
>>>
>>> sequence 90
drop
>>>
>>> exit
>>>
>>> This policy config kind of implements the
resolution-scheme . :)
>>>
>>
>> yeahh, i knew that matching against the rd is not the color but
the path... :)
>>
>>
>>
>>> It works with LDP tunnels in VRFs v2, v3. BGP-CT routes are able
to resolve over LDP routes
>>>
>>> (in main VRF v1 or color VRFs v2,v3), and create SWAP routes
properly.
>>>
>>> We could not make BGP routes resolve over RSVP-TE Tunnel routes
in any VRF. That s why we used
>>>
>>> LDP-tunnels in previous IETF demo as-well. We may be missing
something there.
>>
>> so that was just another dirty hack that i put the rsvp to a dummy
vrf to have a color on it.... :)
>>
>>
>>>
>>> And, the code-change in rtrBgpNeigh.java was needed to make the
following config work:
>>>
>>
>> [..]
>>
>> let's discuss this on my previous mail, i did a lot of changes to
that part as i realized
>> that you were right and a lot were missing on that part of the
code.... :)
>> thanks again for spotting it... :)
>>
>> thanks,
>> cs

Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only




Archive powered by MHonArc 2.6.24.

Top of Page