docs/specs/oxygen/discovery_of_directly_connected_pnfs.rst

   1 .. contents:: Table of Contents
   2    :depth: 3
   3
   4 ===================================================================
   5 Discovery of directly connected PNFs in Flat/VLAN provider networks
   6 ===================================================================
   7 https://git.opendaylight.org/gerrit/#/q/topic:directly_connected_pnf_discovery
   8
   9 This features enables discovering and directing traffic to Physical Network Functions (PNFs)
  10 in Flat/VLAN provider and tenant networks, by leveraging Subnet-Route feature.
  11
  12 Problem description
  13 ===================
  14 PNF is a device which has not been created by Openstack but connected to the hypervisors
  15 L2 broadcast domain and configured with ip from one of the neutron subnets.
  16
  17 Ideally, L2/L3 communication between VM instances and PNFs on flat/VLAN networks
  18 would be routed similarly to inter-VM communication. However, there are two main issues
  19 preventing direct communication to PNFs.
  20
  21 * L3 connectivity of tenant network and VLAN provider network, between VMs and PNFs.
  22   A VM is located in a tenant network, A PNF is located in a provider network (external network).
  23   Both networks are connected via a router.
  24   The only way for VMs to communicate with a PNF is via additional hop which is the external gateway,
  25   instead of directly.
  26
  27 * L3 connectivity between VMs and PNFs in a two diffrent tenant networks,
  28   connected by a router, which is not supported and have two problems.
  29   First, traffic initiated from a VMs towards a PNF is dropped because there isn't
  30   an appropriate rule in FIB table (table 21) to route that traffic.
  31   Second, in the other direction, PNFs are not able to resolve their default gateway.
  32
  33 We want to leverage the Subnet-Route and Aliveness-Monitor features in order to address
  34 the above issues.
  35
  36 Subnet-Route
  37 ------------
  38 Today, Subnet-Route feature enables ODL to route traffic to a destination IP address,
  39 even for ip addresses that have not been statically configured by OpenStack,
  40 in the FIB table.
  41 To achieve that, the FIB table contains a flow that match all IP packets in a given subnet range.
  42 How that works?
  43
  44 * A flow is installed in the FIB table, matching on subnet prefix and vpn-id of the network,
  45   with a goto-instruction directing packets to table 22. There, packets are punted to the controller.
  46
  47 * ODL hold the packets, and initiate an ARP request towards the destination IP.
  48 * Upon receiving ARP reply, ODL installs exact IP match flow in FIB table to direct
  49   all further traffic towards the newly learnt MAC of the destination IP
  50
  51 Current limitations of Subnet-Route feature:
  52
  53 * Works for BGPVPN only
  54 * May cause traffic lost due to "swallowing" the packets punted from table 22.
  55 * Uses the source MAC and source IP from the punted packet.
  56
  57 Aliveness monitor
  58 -----------------
  59 After ODL learns a mac that is associated with an ip address,
  60 ODL schedule an arp monitor task, with the purpose of verifying that the device is still alive
  61 and responding. This is done by periodically sending arp requests to the device.
  62
  63 Current limitation:
  64 Aliveness monitor was not designed for monitoring devices behind flat/VLAN provider network ports.
  65
  66 Use Cases
  67 ---------
  68 * L3 connectivity of tenant network and VLAN provider network, between VMs and PNFs.
  69     * VMs in a private network, PNFs in external network
  70 * L3 connectivity between VMs and PNFs in a two diffrent tenant networks.
  71
  72 Proposed change
  73 ===============
  74
  75 Subnet-route
  76 ------------
  77 * Upon OpenStack configuration of a Subnet in a provider network,
  78   a new vrf entry with subnet-route augmentation will be created.
  79 * Upon associataion of neutron router with a subnet in a tenant network,
  80   a new vrf entry with subnet-route augmentation will be created.
  81 * Upon receiving ARP reply, install exact IP match flow in FIB table to direct all
  82   further traffic towards the newly resolved PNF, on all relevant computes nodes,
  83   which will be discussed later
  84 * Packets that had been punted to controller will be resubmitted to the openflow pipeline
  85   after installation of exact match flow.
  86
  87 Communication between VMs in tenant networks and PNFs in provider networks.
  88 ---------------------------------------------------------------------------
  89
  90 In this scenario a VM in a private tenant network wants to communicate with a PNF in the
  91 (external) provider network
  92
  93 * The controller will hold the packets, and initiate an ARP request towards the PNF IP.
  94   an ARP request will have source MAC and IP the router gateway
  95   and will be sent from the NAPT switch.
  96 * ARP packets will be punted from the NAPT switch only.
  97 * Upon receiving ARP reply, install exact IP match flow in FIB table to direct all further
  98   traffic towards the newly resolved PNF, on all compute nodes that are associated
  99   with the external network.
 100 * leveraging Aliveness monitor feature to monitor PNFs.
 101   The controller will send ARP requests from the NAPT switch.
 102
 103
 104 Communication between VMs and PNFs in different tenant networks.
 105 ----------------------------------------------------------------
 106
 107 In this scenario a VM and a PNF, in different private networks of the same tenant, wants to communicate.
 108 For each subnet prefix, a designated switch will be chosen to communicate directly with the PNFs
 109 in that subnet prefix. That means sending ARP requests to the PNFs and receiving their traffic.
 110
 111 **Note: IP traffic from VM instances will retain the src MAC of the VM instance,
 112 instead of replacing it with the router-interface-mac, in order to prevent MAC momvements
 113 in the underlay switches.
 114 This is a limitation until NetVirt supports a MAC per hypervisor implementation.**
 115
 116
 117 * A subnet flow will be installed in the FIB table,
 118   matching the subnet prefix and vpn-id of the router.
 119 * ARP request will have a source MAC and IP of the router interface, and will be sent via the provider port
 120   in the designated switch.
 121 * ARP packets will be punted from the designated switch only.
 122 * Upon receiving an ARP reply, install exact IP match flow in FIB table to direct all
 123   further traffic towards the newly resolved PNF, on all computes related to the router
 124 * ARP responder flow: a new ARP responder flow will be installed in the designated switch
 125   This flow will response for ARP requests from a PNF and the response MAC
 126   will be the router interface MAC. This flow will use the LPort-tag of the provider port.
 127 * Split Horizon protection disabling: traffic from PNFs,
 128   arrives to the primary switch(via a provider port) due to the ARP responder rule described above,
 129   and will need to be directed to the proper compute of the designated VM (via a provider port).
 130   This require disabling the split horizon protection.
 131   In order to protects against infinite loops, the packet TTL will be decreased.
 132 * leveraging Aliveness monitor, the controller will send ARP requests from the designated switch.
 133
 134 ARP messages
 135 --------------
 136 ARP messages in the Flat/Vlan provider and tenant networks will be punted from
 137 a designated switch, in order to avoid a performance issue in the controller,
 138 of dealing with broadcast packets that may be received in multiple provider ports.
 139 In external networks this switch is the NAPT switch.
 140
 141
 142 Pipeline changes
 143 ----------------
 144 First use-case depends on hairpinning spec [2], the flows presented here reflects that dependency.
 145
 146 Egress traffic from VM with floating IP to an unresolved PNF in external network
 147 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 148 - Packets in FIB table after translation to FIP, will match on subnet flow
 149   and will be punted to controller from Subnet Route table.
 150   Then, ARP request will be generated and be sent to the PNF.
 151   No flow changes are required in this part.
 152
 153   | Classifier table (0) =>
 154   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 155   | GW Mac table (19) ``match: vpn-id=router-id,dst-mac=router-interface-mac`` =>
 156   | FIB table (21) ``match: vpn-id=router-id`` =>
 157   | Pre SNAT table (26) ``match: vpn-id=router-id,src-ip=vm-ip
 158     set vpn-id=ext-subnet-id,src-ip=fip`` =>
 159   | SNAT table (28) ``match: vpn-id=ext-subnet-id,src-ip=fip set src-mac=fip-mac`` =>
 160   | FIB table (21) ``match: vpn-id=ext-subnet-id, dst-ip=ext-subnet-ip`` =>
 161   | Subnet Route table (22):  => Output to Controller
 162   |
 163
 164 - After receiving  ARP response from the PNF a new exact IP flow will be installed in table 21.
 165   No other flow changes are required.
 166
 167   | Classifier table (0) =>
 168   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 169   | GW Mac table (19) ``match: vpn-id=router-id,dst-mac=router-interface-mac`` =>
 170   | FIB table (21) ``match: vpn-id=router-id`` =>
 171   | Pre SNAT table (26) ``match: vpn-id=router-id,src-ip=vm-ip
 172     set vpn-id=ext-subnet-id,src-ip=fip`` =>
 173   | SNAT table (28) ``match: vpn-id=ext-subnet-id,src-ip=fip set src-mac=fip-mac`` =>
 174   | FIB table (21) ``match: vpn-id=ext-subnet-id, dst-ip=pnf-ip,
 175     set dst-mac=pnf-mac, reg6=provider-lport-tag`` =>
 176   | Egress table (220) output to provider port
 177   |
 178
 179 Egress traffic from VM using NAPT to an unresolved PNF in external network
 180 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 181 - Ingress-DPN is not the NAPT switch, no changes required.
 182   Traffic will be directed to NAPT switch and directed to the outbound NAPT table straight
 183   from the internal tunnel table
 184
 185   | Classifier table (0) =>
 186   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 187   | GW Mac table (19) ``match: vpn-id=router-id,dst-mac=router-interface-mac`` =>
 188   | FIB table (21) ``match: vpn-id=router-id`` =>
 189   | Pre SNAT table (26) ``match: vpn-id=router-id`` =>
 190   | NAPT Group ``output to tunnel port of NAPT switch``
 191   |
 192
 193 - Ingress-DPN is the NAPT switch. Packets in FIB table after translation to NAPT,
 194   will match on subnet flow and will be punted to controller from Subnet Route table.
 195   Then, ARP request will be generated and be sent to the PNF. No flow changes are required.
 196
 197   | Classifier table (0) =>
 198   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 199   | GW Mac table (19) ``match: vpn-id=router-id,dst-mac=router-interface-mac`` =>
 200   | FIB table (21) ``match: vpn-id=router-id`` =>
 201   | Pre SNAT table (26) ``match: vpn-id=router-id`` =>
 202   | Outbound NAPT table (46) ``match: src-ip=vm-ip,port=int-port
 203     set src-ip=router-gw-ip,vpn-id=router-gw-subnet-id,port=ext-port`` =>
 204   | NAPT PFIB tabl (47) ``match: vpn-id=router-gw-subnet-id`` =>
 205   | FIB table (21) ``match: vpn-id=ext-subnet-id, dst-ip=ext-subnet-ip`` =>
 206   | Subnet Route table (22)  => Output to Controller
 207   |
 208
 209 - After receiving  ARP response from the PNF a new exact IP flow will be installed in table 21.
 210   No other changes required.
 211
 212   | Classifier table (0) =>
 213   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 214   | GW Mac table (19) ``match: vpn-id=router-id,dst-mac=router-interface-mac`` =>
 215   | FIB table (21) ``match: vpn-id=router-id`` =>
 216   | Pre SNAT table (26) ``match: vpn-id=router-id`` =>
 217   | Outbound NAPT table (46) ``match: vpn-id=router-id TBD set vpn-id=external-net-id`` =>
 218   | NAPT PFIB table (47) ``match: vpn-id=external-net-id`` =>
 219   | FIB table (21) ``match: vpn-id=ext-network-id, dst-ip=pnf-ip
 220     set dst-mac=pnf-mac, reg6=provider-lport-tag`` =>
 221   | Egress table (220) output to provider port
 222   |
 223
 224 Egress traffic from VM in private network to an unresolved PNF in another private network
 225 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 226 - Packet from a VM is punted to the controller, no flow changes are required.
 227
 228   | Classifier table (0) =>
 229   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 230   | GW Mac table (19) ``match: vpn-id=router-id,dst-mac=router-interface-mac`` =>
 231   | FIB table (21) ``match: vpn-id=router-id dst-ip=subnet-ip`` =>
 232   | Subnet Route table (22):  => Output to Controller
 233   |
 234
 235 - After receiving  ARP response from the PNF a new exact IP flow will be installed in table 21.
 236
 237   | Classifier table (0) =>
 238   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 239   | GW Mac table (19) ``match: vpn-id=router-id,dst-mac=router-interface-mac`` =>
 240   | FIB table (21) ``match: vpn-id=router-id dst-ip=pnf-ip
 241     set dst-mac=pnf-mac, reg6=provider-lport-tag`` =>
 242   | Egress table (220) output to provider port
 243   |
 244
 245 Ingress traffic to VM in private network from a PNF in another private network
 246 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 247 - New flow in table 19, to distinguish our new use-case,
 248   in which we want to decrease the TTL of the packet
 249
 250   | Classifier table (0) =>
 251   | Dispatcher table (17) ``l3vpn service: set vpn-id=router-id`` =>
 252   | GW Mac table (19) ``match: lport-tag=provider-port, vpn-id=router-id, dst-mac=router-interface-mac,
 253     set split-horizon-bit = 0, decrease-ttl`` =>
 254   | FIB table (21) ``match: vpn-id=router-id dst-ip=vm-ip
 255     set dst-mac=vm-mac reg6=provider-lport-tag`` =>
 256   | Egress table (220) output to provider port
 257   |
 258
 259
 260 Yang changes
 261 ------------
 262 In odl-l3vpn module,  adjacency-list grouping will be enhanced with the following field
 263 ::
 264
 265    grouping adjacency-list {
 266     list adjacency {
 267       key "ip_address";
 268       ...
 269       leaf phys-network-func {
 270            type boolean;
 271            default false;
 272            description "Value of True indicates this is an adjacency of a device in a provider network";
 273       }
 274     }
 275   }
 276
 277 An adjacency that is added as a result of a PNF discovery, is a primary adjacency with
 278 an empty next-hop-ip list. This is not enough to distinguish PNF at all times.
 279 This new field will help us identify this use-case in a more robust way.
 280
 281 Configuration impact
 282 ---------------------
 283 A configuration mode will be available to turn this feature ON/OFF.
 284
 285 Clustering considerations
 286 -------------------------
 287 None
 288
 289 Other Infra considerations
 290 --------------------------
 291 None
 292
 293 Security considerations
 294 ------------------------------
 295 None
 296
 297 Scale and Performance Impact
 298 ----------------------------
 299 All traffic of PNFs in each subnet-prefix sends their traffic to a designated switch.
 300
 301
 302 Targeted Release
 303 -----------------
 304 Carbon
 305
 306 Alternatives
 307 ------------
 308 None
 309
 310 Usage
 311 =====
 312 Create external network with a subnet
 313 -------------------------------------
 314 ::
 315
 316  neutron net-create public-net -- --router:external --is-default --provider:network_type=flat
 317  --provider:physical_network=physnet1
 318  neutron subnet-create --ip_version 4 --gateway 10.64.0.1 --name public-subnet1 <public-net-uuid> 10.64.0.0/16
 319  -- --enable_dhcp=False
 320
 321 Create internal networks with subnets
 322 -------------------------------------
 323
 324 ::
 325
 326  neutron net-create private-net1
 327  neutron subnet-create --ip_version 4 --gateway 10.0.123.1 --name private-subnet1 <private-net1-uuid>
 328  10.0.123.0/24
 329  neutron net-create private-net2
 330  neutron subnet-create --ip_version 4 --gateway 10.0.124.1 --name private-subnet2 <private-net2-uuid>
 331  10.0.124.0/24
 332
 333 Create a router instance and connect it to an internal subnet and an external subnet
 334 ------------------------------------------------------------------------------------
 335 This will allow communication with PNFs in provider network
 336 ::
 337
 338  neutron router-create router1
 339  neutron router-interface-add <router1-uuid> <private-subnet1-uuid>
 340  neutron router-gateway-set --fixed-ip subnet_id=<public-subnet1-uuid> <router1-uuid> <public-net-uuid>
 341
 342 Create a router instance and connect to it to two internal subnets
 343 ------------------------------------------------------------------
 344 This will allow East/West communication between VMs and PNFs
 345 ::
 346
 347  neutron router-create router1
 348  neutron router-interface-add <router1-uuid> <private-subnet1-uuid>
 349  neutron router-interface-add <router1-uuid> <private-subnet2-uuid>
 350
 351 Features to Install
 352 -------------------
 353 odl-netvirt-openstack
 354
 355 REST API
 356 --------
 357 CLI
 358 ---
 359
 360 Implementation
 361 ==============
 362
 363 Assignee(s)
 364 -----------
 365 Primary assignee:
 366   Tomer Pearl <tomer.pearl@hpe.com>
 367
 368 Other contributors:
 369   Yakir Dorani <yakir.dorani@hpe.com>
 370
 371 Work Items
 372 ----------
 373 * Configure subnet-route flows upon ext-net configuration / router association
 374 * Solve traffic lost issues of punted packets from table 22
 375 * Enable aliveness monitoring on external interfaces.
 376 * Add ARP responder flow for L3-PNF
 377 * Add ARP packet-in from primary switch only
 378 * Disable split-horizon and enable TTL decrease for L3-PNF
 379
 380 Dependencies
 381 ============
 382 This feature depends on hairpinning feature [2]
 383
 384 Testing
 385 =======
 386
 387 Unit Tests
 388 ----------
 389 Unit tests will be added for the new functionality
 390
 391 Integration Tests
 392 -----------------
 393
 394 CSIT
 395 ----
 396 Will need to see if a PNF could be simulated in CSIT
 397
 398 Documentation Impact
 399 ====================
 400 References
 401 ==========
 402 [1] https://docs.google.com/presentation/d/1ByvEQXUtIyH-H7Bin6OBJNrHjOv-3hpHYzU6Sf6hDbA/edit#slide=id.g11657174d1_0_31
 403 [2] http://docs.opendaylight.org/en/latest/submodules/netvirt/docs/specs/hairpinning-flat-vlan.html
 404
 405