docs/specs/setup-smac-for-routed-packets-to-virt-endpoints.rst

   1 .. contents:: Table of Contents
   2    :depth: 3
   3
   4 =========================================================================
   5 Setup Source-MAC-Address for routed packets destined to virtual endpoints
   6 =========================================================================
   7
   8 https://git.opendaylight.org/gerrit/#/q/topic:SMAC_virt_endpoints
   9
  10 All L3 Routed packets destined to virtual endpoints in the datacenter managed by ODL
  11 do not carry a proper source-mac address in such frames put out to virtual endpoints.
  12
  13 This spec makes sure a proper source-mac is updated in the packet at the point where the
  14 packet is delivered to the VM, regardless of the tenant network type. On the actual datapath,
  15 there will be no change in the source mac-addresses and packets continue to use the same
  16 mechanism that is used today.
  17
  18 Addressing the datapath requires unique MAC allocation per OVS Datapath, so that it can be
  19 used as the source MAC for all distributively routed packets of an ODL enabled cloud. It
  20 would be handled in some future spec.
  21
  22 Problem description
  23 ===================
  24 Today all L3 Routed packets destined to virtual endpoints in the datacenter either
  25
  26 * Incorrectly carry the source mac-address of the originator (regardless of which network the originator is in)
  27 * Incorrectly carry sometimes the reserved source mac address of 00:00:00:00:00:00
  28
  29 This spec is intended to setup a source-mac-address in the frame of L3 Routed packets just before
  30 such frames are directed into the virtual endpoints themselves.  This enables use-cases where certain
  31 virtual endpoints which are VNFs in the datacenter that are source-mac conscious (or mandate that src-mac
  32 in frames be valid) can become functional on their instantiation in an OpenDaylight enabled cloud.
  33
  34 Use Cases
  35 ---------
  36 * Intra-Datacenter L3 forwarded packets within a hypervisor.
  37 * Intra-Datacenter L3 forwarded packets over Internal VXLAN Tunnels between two hypervisors in the datacenter.
  38 * Inter-Datacenter L3 forwarded packets :
  39
  40   *  Destined to VMs associated floating IP over External VLAN Provider Networks.
  41   *  Destined to VMs associated floating IP over External MPLSOverGRE Tunnels.
  42   *  SNAT traffic from VMs over External MPLSOverGRE Tunnels.
  43   *  SNAT traffic from VMS over External VLAN Provider Networks.
  44
  45
  46 Proposed change
  47 ===============
  48 All the L3 Forwarded traffic today reaches the VM via a LocalNextHopGroup managed by
  49 the VPN Engine (including FIBManager).
  50
  51 Currently the LocalNextHopGroup sets-up the destination MAC Address of the VM and forwards the traffic
  52 to EGRESS_LPORT_DISPATCHER_TABLE (Table 220). In that LocalNextHopGroup we will additionally setup
  53 source-mac-address for the frame.  There are two cases to decide what source-mac-address should go
  54 into the frame:
  55
  56 * If the VM is on a subnet (on a network) for which a subnet gatewayip port exists, then the
  57   source-mac address of that subnet gateway port will be setup as the frame's source-mac
  58   inside the LocalNextHop group.This is typical of the case when a subnet is added to a router,
  59   as the router interface port created by neutron will be representing the subnet's gateway-ip address.
  60
  61 * If the VM is on a subnet (on a network), for which there is no subnet gatewayip port but that network
  62   is part of a BGPVPN , then the source-mac address would be that of the connected mac-address of the
  63   VM itself.  The connected mac-address is nothing but the mac-address on the ovs-datapath for the VMs
  64   tapxxx/vhuxxx port on that hypervisor itself.
  65
  66 The implementation also applies to Extra-Routes (on a router) and Discovered Routes as they both use the
  67 LocalNextHopGroup in their last mile to send packets into their Nexthop VM.
  68
  69 We need to note that when a network is already part of a BGPVPN, adding a subnet on such a network to
  70 a router is disallowed currently by NeutronVPN.  And so the need to swap the mac-addresses inside
  71 the LocalNextHopGroup to reflect the subnet gatewayip port here does not arise.
  72
  73 For all the use-cases listed in the USE-CASES section above, proper source mac address will be filled-up
  74 in the frame before it enters the virtual endpoint.
  75
  76 Pipeline changes
  77 ----------------
  78 There are no pipeline changes.
  79
  80 The only change is in the NextHopGroup created by VPN Engine (i.e., VRFEntryListener).  In the NextHopGroup we
  81 will additionally fill up the ethernet source mac address field with proper mac-address as outlined in the
  82 'Proposed change' section.
  83
  84 Currently the LocalNextHopGroup is used in the following tables of VPN Pipeline:
  85
  86 * L3_LFIB_TABLE (Table 20)  - Lands all routed packets from MPLSOverGRE tunnel into the virtual endpoint.
  87
  88 * INTERNAL_TUNNEL_TABLE (Table 36)  - Lands all routed packets on Internal VXLAN Tunnel within the DC into the
  89   virtual end point.
  90
  91 * L3_FIB_TABLE (Table 21) - Lands all routed packets within a specific hypervisor into the virtual endpoint.
  92
  93 .. code-block:: bash
  94
  95    cookie=0x8000002, duration=50.676s, table=20, n_packets=0, n_bytes=0, priority=10,mpls,mpls_label=70006 actions=write_actions(pop_mpls:0x0800,group:150000)
  96    cookie=0x8000003, duration=50.676s, table=21, n_packets=0, n_bytes=0, priority=42,ip,metadata=0x222f2/0xfffffffe,nw_dst=10.1.1.3 actions=write_actions(group:150000)
  97    cookie=0x9011176, duration=50.676s, table=36, n_packets=0, n_bytes=0, priority=5,tun_id=0x11176 actions=write_actions(group:150000)
  98
  99    NEXTHOP GROUP:
 100    group_id=150000,type=all,bucket=actions=set_field:fa:16:3e:01:1a:40->eth_src,set_field:fa:16:3e:8b:c5:51->eth_dst,load:0x300->NXM_NX_REG6[],resubmit(,220)
 101
 102 Yang changes
 103 ------------
 104 None.
 105
 106 Configuration impact
 107 ---------------------
 108 None.
 109
 110 Clustering considerations
 111 -------------------------
 112 None.
 113
 114 Other Infra considerations
 115 --------------------------
 116 None.
 117
 118 Security considerations
 119 -----------------------
 120 None.
 121
 122 Scale and Performance Impact
 123 ----------------------------
 124 None
 125
 126 Targeted Release
 127 -----------------
 128 Carbon/Boron
 129
 130 Alternatives
 131 ------------
 132 None.
 133
 134 Usage
 135 =====
 136 N/A.
 137
 138 Features to Install
 139 -------------------
 140 odl-netvirt-openstack
 141
 142 REST API
 143 --------
 144 N/A.
 145
 146 CLI
 147 ---
 148 N/A.
 149
 150 Implementation
 151 ==============
 152
 153 Assignee(s)
 154 -----------
 155 Primary assignee:
 156
 157 * Achuth Maniyedath (achuth.m@altencalsoftlabs.com)
 158
 159 Other contributors:
 160
 161 * Karthik Prasad (karthik.p@altencalsoftlabs.com)
 162 * Vivekanandan Narasimhan (n.vivekanandan@ericsson.com)
 163
 164 Work Items
 165 ----------
 166 https://trello.com/c/IfAmnFFr/110-add-source-macs-in-frames-for-l3-routed-packets-before-such-frames-get-to-the-virtual-endpoint
 167
 168 * Determine the smac address to be used for L3 packets forwarded to VMs.
 169 * Update the LocalNextHopGroup table with proper ethernet source-mac parameter.
 170
 171 Dependencies
 172 ============
 173 No new dependencies.
 174
 175 Testing
 176 =======
 177 Verify the Source-MAC-Address setting on frames forwarded to Virtual endpoints in following cases.
 178
 179 Intra-Datacenter traffic to VMs (Intra/Inter subnet).
 180
 181 * VM to VM traffic within a hypervisor.
 182 * VM to VM traffic across hypervisor over Internal VXLAN tunnel.
 183
 184 Inter-Datacenter traffic to/from VMs.
 185
 186 * External access to VMs using Floating IPs on MPLSOverGRE tunnels.
 187 * External access to VMs using Floating IPs over VLAN provider networks.
 188 * External access from VMs using SNAT over VLAN provider networks.
 189 * External access from VMs using SNAT on MPLSOverGRE tunnels.
 190
 191 Unit Tests
 192 ----------
 193 N/A.
 194
 195 Integration Tests
 196 -----------------
 197 N/A.
 198
 199 CSIT
 200 ----
 201 * Validate that router-interface src-mac is available on received frames within the VM when that VM is on a router-arm.
 202 * Validate that connected-mac as src-mac available on received frames within the VM when that VM is on a network-driven L3 BGPVPN.
 203
 204 Documentation Impact
 205 ====================
 206 N/A
 207
 208 References
 209 ==========
 210 N/A