And thank you for the thorough review and valuable feedback :) Martin.
> On 13 Aug 2024, at 17:49, Vladislav Odintsov <[email protected]> wrote: > > Thank you Martin and Dumitru for your work on this! > > On 13.08.2024 22:46, Dumitru Ceara wrote: >> On 8/12/24 19:30, Vladislav Odintsov wrote: >>> On 13.08.2024 00:14, Dumitru Ceara wrote: >>>> On 8/12/24 18:21, Martin Kalcok wrote: >>>>> This change adds two new LRP options: >>>>> * routing-protocol-redirect >>>>> * routing-protocols >>>>> >>>>> These allow redirection of a routing protocol traffic to >>>>> an Logical Switch Port. This enables external routing daemons >>>>> to listen on an interface bound to an LSP and effectively act >>>>> as if they were listening on (and speaking from) LRP's IP address. >>>>> >>>>> Option 'routing-protocols' takes a comma-separated list of routing >>>>> protocols whose traffic should be redirected. Currently supported >>>>> are BGP (tcp 179) and BFD (udp 3784). >>>>> >>>>> Option 'routing-protocol-redirect' expects a string with an LSP >>>>> name. >>>>> >>>>> When both of these options are set, any traffic entering LS >>>>> that's destined for LRP's IP addresses (including IPv6 LLA) and >>>>> routing protocol's port number, is redirected to the LSP specified >>>>> in the 'routing-protocol-redirect' value. >>>>> >>>>> NOTE: this feature is experimental and may be subject to >>>>> removal/change in the future. >>>>> >>>>> Signed-off-by: Martin Kalcok<[email protected]> >>>>> <mailto:[email protected]> >>>>> --- >>>>> >>>>> v9 contains small changes based on the review of v8: >>>>> * Simplified search for the port specified in >>>>> 'routing-protocol-redirect', >>>>> using 'ovn_port_find' >>>>> * As a result this change a new possible warning was added when LRP >>>>> is not connected to the same LS as LSP specified in >>>>> 'routing-protocol-redirect'. >>>>> * Datapath test for this feature now includes verification of BFD's >>>>> UDP traffic. >>>>> * These tests required some more care as Ncat produced false >>>>> positive >>>>> results even when sending to a port where nothing was >>>>> listening. My >>>>> assumption is that Ncat tries to assert succes of a UDP connection >>>>> based on lack of ICMP Port Unreachable message, and LR probably >>>>> does not generate these? >>>>> * nit: null pointer checks changed from 'if (p == NULL)' to 'if (!p)' >>>>> for consistency. >>>>> >>>> This version looks good to me! >>>> >>>> Acked-by: Dumitru Ceara<[email protected]> <mailto:[email protected]> >>>> >>>> Vladislav, do you happen to have some time to try this version out on >>>> your end too? >>> Yes, just now finished testing. >>> >>> With centralized routing the BGP and BFD works well (in my setup there >>> are two VRFs with BGP and BFD peerings configured as a haipnit inside >>> one node to each other): >>> >>> # sh run >>> <...snip...> >>> router bgp 64512 vrf dxvif-62C25580 >>> bgp router-id 169.254.252.1 >>> no bgp ebgp-requires-policy >>> no bgp network import-check >>> neighbor 169.254.252.2 remote-as 64513 >>> neighbor 169.254.252.2 bfd >>> exit >>> ! >>> router bgp 64513 vrf dxvif-9ED34880 >>> bgp router-id 169.254.252.2 >>> no bgp ebgp-requires-policy >>> no bgp network import-check >>> neighbor 169.254.252.1 remote-as 64512 >>> neighbor 169.254.252.1 bfd >>> ! >>> address-family ipv4 unicast >>> network 10.0.0.0/24 >>> exit-address-family >>> exit >>> >>> # sh ip bgp vrf all >>> >>> Instance dxvif-62C25580: >>> BGP table version is 1, local router ID is 169.254.252.1, vrf id 760 >>> Default local pref 100, local AS 64512 >>> Status codes: s suppressed, d damped, h history, * valid, > best, = >>> multipath, >>> i internal, r RIB-failure, S Stale, R Removed >>> Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self >>> Origin codes: i - IGP, e - EGP, ? - incomplete >>> RPKI validation codes: V valid, I invalid, N Not found >>> >>> Network Next Hop Metric LocPrf Weight Path >>> *> 10.0.0.0/24 169.254.252.2 0 0 64513 i >>> >>> Displayed 1 routes and 1 total paths >>> >>> Instance dxvif-9ED34880: >>> BGP table version is 1, local router ID is 169.254.252.2, vrf id 763 >>> Default local pref 100, local AS 64513 >>> Status codes: s suppressed, d damped, h history, * valid, > best, = >>> multipath, >>> i internal, r RIB-failure, S Stale, R Removed >>> Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self >>> Origin codes: i - IGP, e - EGP, ? - incomplete >>> RPKI validation codes: V valid, I invalid, N Not found >>> >>> Network Next Hop Metric LocPrf Weight Path >>> *> 10.0.0.0/24 0.0.0.0 0 32768 i >>> >>> Displayed 1 routes and 1 total paths >>> >>> # sh bfd peers >>> BFD Peers: >>> peer 169.254.252.1 local-address 169.254.252.2 vrf dxvif-9ED34880 >>> interface dx-9ED34880-v >>> ID: 3199966869 >>> Remote ID: 2401437121 >>> Active mode >>> Status: up >>> Uptime: 26 second(s) >>> Diagnostics: ok >>> Remote diagnostics: ok >>> Peer Type: dynamic >>> RTT min/avg/max: 0/0/0 usec >>> Local timers: >>> Detect-multiplier: 3 >>> Receive interval: 300ms >>> Transmission interval: 300ms >>> Echo receive interval: 50ms >>> Echo transmission interval: disabled >>> Remote timers: >>> Detect-multiplier: 3 >>> Receive interval: 300ms >>> Transmission interval: 300ms >>> Echo receive interval: 50ms >>> >>> peer 169.254.252.2 local-address 169.254.252.1 vrf dxvif-62C25580 >>> interface dx-62C25580-v >>> ID: 2401437121 >>> Remote ID: 3199966869 >>> Active mode >>> Status: up >>> Uptime: 26 second(s) >>> Diagnostics: ok >>> Remote diagnostics: ok >>> Peer Type: dynamic >>> RTT min/avg/max: 0/0/0 usec >>> Local timers: >>> Detect-multiplier: 3 >>> Receive interval: 300ms >>> Transmission interval: 300ms >>> Echo receive interval: 50ms >>> Echo transmission interval: disabled >>> Remote timers: >>> Detect-multiplier: 3 >>> Receive interval: 300ms >>> Transmission interval: 300ms >>> Echo receive interval: 50ms >>> >>> At this point this looks good with a note, that for LB VIPs and NAT >>> addresses we do use ha-chassis-group with primary/secondary chassis, >>> which is currently not supported by the redirect feature. >>> >>> This probably should be somehow addressed in a future development. >>> >> Ack. >> >>> Tested-by: Vladislav Odintsov <[email protected]> <mailto:[email protected]> >>> >> Thanks, Vladislav! >> >>>> Mark, Numan, Han, as discussed before branching, I think it's fine to >>>> include this experimental feature on branch 24.09 (and in v24.09.0) too. >>>> >>>> Do you guys agree? >>>> >> I synced up with Mark offline about this and he was OK with pushing the >> patch to 24.09 too. So I went ahead and pushed the patch to main (I >> added a NEWS entry as we were missing one) and then backported it to >> branch-24.09. >> >> Thanks again for the work on this, Martin and Vladislav! >> >> Regards, >> Dumitru >> >> _______________________________________________ >> dev mailing list >> [email protected] <mailto:[email protected]> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
