Uploaded image for project: 'Fast Datapath Product'
  1. Fast Datapath Product
  2. FDP-2734

[BGP] L3 route advertisements with explicit next hop.

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • OVN
    • None
    • [BGP] L3 route advertisements with explicit next hop.
    • False
    • False
    • Hide

      Please mark each item below with ( / ) if completed or ( x ) if incomplete:

      ( ) The acceptance criteria defined below are met.

      IPv4 route advertisement with explicit next-hop
      Given LR1 with options:dynamic-routing=true, options:dynamic-routing-vrf-id=100, and options:dynamic-routing-advertise-v4-prefix-next-hop=192.168.1.1 configured in ovn-nb database,

      When ovn-controller processes an advertised IPv4 route prefix 10.0.0.0/24 for LR1,

      Then VRF table 100 contains route 10.0.0.0/24 with type RTN_UNICAST and gateway 192.168.1.1.
      –
      Given LR2 with options:dynamic-routing=true, options:dynamic-routing-vrf-id=200, and options:dynamic-routing-advertise-v6-prefix-next-hop=fd00::1 configured,

      When ovn-controller processes an advertised IPv6 route prefix 2001:db8::/64 for LR2,

      Then VRF table 200 contains route 2001:db8::/64 with type RTN_UNICAST and gateway fd00::1.
      –
      Given LR3 with options:dynamic-routing-advertise-v4-prefix-next-hop=fd00::abcd configured,

      When ovn-controller attempts to advertise IPv4 route 172.16.0.0/16,

      Then, VRF table contains a RTN_UNICAST route 172.16.0.0/16 via fd00::abcd and the route is installed successfully.

      ( ) The epics work is available in a downstream build (nightly/async or other)

      ( ) Test coverage is available in downstream CI if applicable

      ( ) All cards under the epic have been moved to Done

      ( ) Failed Test Plans have bugs added as children to the epic/feature.

      Show
      Please mark each item below with ( / ) if completed or ( x ) if incomplete: ( ) The acceptance criteria defined below are met. IPv4 route advertisement with explicit next-hop Given LR1 with options:dynamic-routing=true, options:dynamic-routing-vrf-id=100, and options:dynamic-routing-advertise-v4-prefix-next-hop=192.168.1.1 configured in ovn-nb database, When ovn-controller processes an advertised IPv4 route prefix 10.0.0.0/24 for LR1, Then VRF table 100 contains route 10.0.0.0/24 with type RTN_UNICAST and gateway 192.168.1.1. – Given LR2 with options:dynamic-routing=true, options:dynamic-routing-vrf-id=200, and options:dynamic-routing-advertise-v6-prefix-next-hop=fd00::1 configured, When ovn-controller processes an advertised IPv6 route prefix 2001:db8::/64 for LR2, Then VRF table 200 contains route 2001:db8::/64 with type RTN_UNICAST and gateway fd00::1. – Given LR3 with options:dynamic-routing-advertise-v4-prefix-next-hop=fd00::abcd configured, When ovn-controller attempts to advertise IPv4 route 172.16.0.0/16, Then, VRF table contains a RTN_UNICAST route 172.16.0.0/16 via fd00::abcd and the route is installed successfully. ( ) The epics work is available in a downstream build (nightly/async or other) ( ) Test coverage is available in downstream CI if applicable ( ) All cards under the epic have been moved to Done ( ) Failed Test Plans have bugs added as children to the epic/feature.
    • FDP-2753 - OVN-Kubernetes native BGP convergence
    • rhel-9
    • FDP-2753OVN-Kubernetes native BGP convergence
    • rhel-net-ovn
    • 100% To Do, 0% In Progress, 0% Done
    • ssg_networking

      This epic tracks all the effort needed to deliver the solution related to the feature request described below.

      What's the feature?

      OVN(-controller) currently advertises OVN routes (dynamic-routing-redistribute=connected/connected-as-host/nat/lb/static) as "blackhole" routes in the VRF table associated to the logical router that's configured with dynamic-routing=true.

      There are use cases when the same VRF would be shared with the host for actual traffic forwarding.  In that case, the goal is to automatically use OVN advertised routes on the host too.

      In order for that to work they need to be installed with an explicit next-hop IP.  To avoid having to guess that value of that IP, the CMS (e.g., ovn-kubernetes/neutron) will have to explicitly provide it to OVN via a NB router configuration.

      The new config options should be along the lines of:

      LR.options:dynamic-routing-advertise-v4-prefix-next-hop=<IP>
      LR.options:dynamic-routing-advertise-v6-prefix-next-hop=<IP>

      The reason why we need two configurations (one for IPv4 prefixes and one for IPv6 prefixes) is that OVN (and the kernel) supports mixing address families in routes, i.e., the prefix can be a v4 prefix and the next-hop an IPv6 address (and the other way around).

      Why is it needed?

      To enable the CMS (ovn-kubernetes) to share the VRF OVN monitors and updates when dynamic routing is configured.

      Who will benefit? 

      ovn-kubernetes transitioning to use OVN's native BGP support.  Potentially neutron-ovn too.

              ovnteam@redhat.com OVN Team
              dceara@redhat.com Dumitru Ceara
              Patryk Diak, Surya Seetharaman
              OVN QE OVN QE
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: