Rare project developers

[mc36 <>]

+ 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: http://www.freertr.org/
>
> license: http://creativecommons.org/licenses/by-sa/4.0/
>
> 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