Skip to Content.

rare-dev - Re: [rare-dev] BGP CT interop - Colorful Resolution

Subject: Rare project developers

List archive


Re: [rare-dev] BGP CT interop - Colorful Resolution


Chronological Thread 
    < Chronological >      < Thread >
  • From: mc36 <>
  • To: Kaliraj Vairavakkalai <>, Natrajan Venkataraman <>
  • Cc: Reshma Das <>, "" <>, Krzysztof Szarkowicz <>
  • Subject: Re: [rare-dev] BGP CT interop - Colorful Resolution
  • Date: Tue, 28 Feb 2023 10:31:56 +0100
hi,

i did some real quick tests and this is really just what i said initially,

so the original bgp behavior with the next-hop-unchanged toward route
reflectors...

now i'll play a bit with my original idea about the two ebgp between pe1 and
pe2 in the eantc topology...

that one is im pretty sure will work for the interop event, and as we'll be
onsite, after we configured up everything real quick,

we could hack together on something that lifts this 2 ebgp requirement in
freerouter... :)

thanks,

cs


On 2/27/23 22:37, Kaliraj Vairavakkalai wrote:
Those are kind words Csaba . I m glad we are in the right direction.

i'll try that asap !

Cool!. Will wait for your experiment. Fingers crossed.

Thanks

Kaliraj

*From: *mc36 <>
*Date: *Monday, February 27, 2023 at 11:37 AM
*To: *Kaliraj Vairavakkalai <>, Natrajan Venkataraman
<>
*Cc: *Reshma Das <>,
<>, Krzysztof Szarkowicz <>
*Subject: *Re: BGP CT interop - Colorful Resolution

[External Email. Be cautious of content]


+ krzysztof && rare-dev as it's a core rare-dev question, thanks you!!!

hi,

you're crazy good, seemingly you know my shit better than me.... :)))))))

so that nexthop recursive was added when i given support for the original bgp
behavior of nexthop processing:

that is, when you no-next-hop-self toward the route reflectors on your
peering node...

freerouter by default assumes next-hop-self without that knob configured...

but you're right, basically that recursive knob could be reused for the
bgp-ct then i wont need two ebgp at eantc tests....

i'll try that asap !

ps: i <3 your private build XDDD

thanks,
cs





On 2/27/23 19:56, Kaliraj Vairavakkalai wrote:
Also, Csaba

Just some random observations:

This config looks interesting:



r4(cfg-rtr)#neighbor 2.2.2.3 address-family vpnuni
r4(cfg-rtr)#ne?
neighbor - specify
neighbor parameters
* nexthop - specify next
hop tracking parameter*

r4(cfg-rtr)#nexthop ?
prefix-list - filter next hops
*recursion - specify recursion depth*
route-map - filter next hops
route-policy - filter next hops

r4(cfg-rtr)#nexthop recursion ?
<num> - maximum rounds

r4(cfg-rtr)#nexthop recursion 4

and, from the code, this function arguments:

/**

* fix nexthops on a route entry

*

* @param <T> class of address

* @param imp route entry to update

* * @param recurs where to look up nexthops recursively*

* * @param nexthops table where look up resolved nexthops*

* @param recurn maximum recursion depth

* @return true if failed, false if ready

*/

public static <T extends addrType> boolean doNexthopFix(tabRouteEntry<T>
imp, tabRoute<T> recurs, tabRoute<T> nexthops, int recurn) {

(in tabRoute.java)

if we pass in the color vrf table v2 as recurs argument, will
that result in doing bgp nexthop resolution based on entries in that v2 table
only?

Basically,

* from CLI, configure a community -> color-vrf/table mapping.
* When route is received, based on community, pick the color-table, and
pass it as recurs in the above function.
* That should result in resolving bgp nexthop over rsvp/ldp routes in
that color-table?

Then we wouldn t need the import policy to match on RD and set vrf
nexthop. And this method may work for all bgp families.

I have a dev setup with freeRtr code ready, where I wanted to experiment
doing the above. Just wanted to update you.

You can tell if I am understanding the code right, or if I am going in wrong
direction. Also, if you agree with the concept,

You will be able to code it faster.

bash-3.2$ dk rtr0

root@edc770cfeb8a:/opt/freertr# telnet localhost 2323

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

welcome

line ready

freertr#show ver

freeRouter v23.2.25-cur, done by cs@nop.

*private build - kaliraj -*****

place on the web: https://urldefense.com/v3/__http://www.freertr.org/__;!!NEt6yMaO-gk!H3SnIGYzFbrhxrhXtZ2diMvam2kBs7WeQgDvTqgTCewafLQi7u86cFptGheS5qQy_NBOxPhg$
<https://urldefense.com/v3/__http:/www.freertr.org/__;!!NEt6yMaO-gk!H3SnIGYzFbrhxrhXtZ2diMvam2kBs7WeQgDvTqgTCewafLQi7u86cFptGheS5qQy_NBOxPhg$>

license: https://urldefense.com/v3/__http://creativecommons.org/licenses/by-sa/4.0/__;!!NEt6yMaO-gk!H3SnIGYzFbrhxrhXtZ2diMvam2kBs7WeQgDvTqgTCewafLQi7u86cFptGheS5qQy_M31zlre$
<https://urldefense.com/v3/__http:/creativecommons.org/licenses/by-sa/4.0/__;!!NEt6yMaO-gk!H3SnIGYzFbrhxrhXtZ2diMvam2kBs7WeQgDvTqgTCewafLQi7u86cFptGheS5qQy_M31zlre$>

quote1: make the world better

I just got started, able to modify the version string and see the result.

Thanks

Kaliraj

*From: *Natrajan Venkataraman <>
*Date: *Saturday, February 25, 2023 at 11:52 AM
*To: *mc36 <>
*Cc: *Kaliraj Vairavakkalai <>, Reshma Das
<>
*Subject: *BGP CT interop - Colorful Resolution

Hi Csaba,

We tried experimenting the new free-rtr code for colorful resolution with the
configuration that you had shared. However we are hitting a few roadblocks
that needs to be addressed
in free-rtr code.

The topology is as same as the demo that was performed in IETF 115 where
resolution was happening via LDP best effort for BGP CT route in ASBR21
received from ASBR22 (10.22.22.22).
However, we modified the demo based on the configs shared by you for colorful
resolution.

We have attached the Old and New configs for your reference for ASBR21. Rest
of the configs (P2, ASR22) are more or less the same. You can refer to the
topology from the demo video.

Thanks,

-Nats-

DETAILS:

````````````

THIS IS THE NON-WORKING CASE WITH RSVP:

=======================================

The following is the summary list of what we are trying to achieve

@ ASBR 21,

- Configure VRF V2 and V3 to import based on BGP-CT RD/RT


freertr-asbr21#show
running-config vrf v2


vrf definition v2


rd 68106:168427528


rt4import 68106:168427528


rt6import 68106:168427528


exit


freertr-asbr21#show
running-config vrf v3


vrf definition v3


rd 68106:168427529


rt4import 68106:168427529


rt6import 68106:168427529


exit

- We created RSVP tunnels tunnel1 and tunnel2 in VRF v2 and v3 respectively
(However we keep tunnel VRF same as forwarding VRF)


freertr-asbr21#show
running-config interface tunnel1


interface tunnel1


description
lsp_asbr21_asbr22


tunnel vrf v2


tunnel source loopback2


tunnel destination
10.22.22.22


tunnel mode p2pte


vrf forwarding v2


ipv4 address 10.121.121.121
255.255.255.0


mpls enable


no shutdown


no log-link-change


exit


freertr-asbr21#show
running-config interface tunnel2


interface tunnel2


description
lsp_asbr21_asbr22


tunnel vrf v3


tunnel source loopback3


tunnel destination
10.22.22.22


tunnel mode p2pte


vrf forwarding v3


ipv4 address 10.221.221.221
255.255.255.0


mpls enable


no shutdown


no log-link-change


exit


!


freertr-asbr21#show ipv4
rsvp v2 summary


source
id subgroup id target id
description


10.121.21.21 8906
:: 0 10.22.22.22 902663016
freertr-asbr21:tunnel1


freertr-asbr21#show ipv4
rsvp v3 summary


source
id subgroup id target
id description


10.221.21.21 12715
:: 0 10.22.22.22 793731422
freertr-asbr21:tunnel2

- Then we added static routes for 10.22.22.22 in V2 and V3 to point to
tunnel1 and tunnel2.

(This we assume, prevents the need for rewriting the nexthop in
policy ibpg-in)


freertr-asbr21#show ipv4 route v2

typ
prefix metric iface
hop time

S
10.22.22.22/32 1/0 tunnel1
10.121.121.122 02:19:56


freertr-asbr21#show ipv4 route v3

typ
prefix metric iface
hop time

S
10.22.22.22/32 1/0 tunnel2
10.221.221.222 02:20:18

- Then we added policy ibgp-in to filter BGP CT routes to resolve on VRFs V2
and V3 based on RD

(However we found that the following policy is not applying on the
BGP CT routes, therefore BGP CT routes do not have a way to set their
respective resolving VRFs V2 and V3)

freertr-asbr21(cfg)#show running-config route-policy ibgp-in



route-policy ibgp-in



sequence 10 if rd 68106:168427528



sequence 20 set vrf v2 ipv4



sequence 30 pass



sequence 40 enif



sequence 50 if rd 68106:168427529



sequence 60 set vrf v3 ipv4



sequence 70 pass



sequence 80 enif



sequence 90 drop



exit



!

router bgp4 1


neighbor 10.20.20.20
route-policy-in ibgp-in


neighbor 10.20.20.20 vpn-route-policy-in
ibgp-in <<<

What we are looking for is an installation of SWAP + PUSH for BGP-CT (SWAP)
over RSVP (PUSH) similar to the working scenario (Option B) instead of what
is being tried above which
we assume is (Option A + B). The following section depicts the working case
and expected behavior.

THIS IS THE WORKING CASE WITH LDP:

==================================

freertr-asbr21#show ipv4 bgp 1 ctp database

prefix
hop metric
aspath

10.2.2.2/32 68098:33685512 10.11.121.1 20/100/0/0
64511

10.2.2.2/32 68098:33685513 10.11.121.1 20/100/0/0
64511

10.10.10.10/32 68106:168427528 10.22.22.22 200/100/0/0 64513

10.10.10.10/32 68106:168427529 10.22.22.22 200/100/0/0 64513 <<<<<

freertr-asbr21#show ipv4 bgp 1 ctp database 10.10.10.10/32 68106:168427529

id category value

vrf
v1:4

ipver
4

rd
68106:168427529

alt0 nexthop 10.22.22.22

alt0 extended community 2562:0:200

alt0 remote label 833274 <<<<<

Here, the local labels are seen as part of the LDP database.

freertr-asbr21#show ipv4 ldp v1 database

prefix local remote
hop

10.10.10.10/32 898649 451252 785360 10.21.12.1

10.10.10.10/32 37034<< 451252 833274 10.21.12.1

freertr-asbr21#show mpls forwarding

label vrf iface hop
label targets bytes

37034<< v1:4 ethernet3 10.21.12.1 451252 833274
0

freertr-asbr21#show mpls forwarding 37034

category value

label 37034

key vrfUni-vrf unicast
<<<

working true

forwarder v1:4

interface ethernet3

nexthop 10.21.12.1

remote label 451252 833274 // SWAP 833274 THEN PUSH 451252

Juniper Business Use Only


Juniper Business Use Only



Juniper Business Use Only


Archive powered by MHonArc 2.6.24.

Top of Page