Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Here is an example VPC deployment with three tiers, with VM's spanning 3 hypervisor hosts as depicted in below diagram. VPC VR still needed to be deployed for north-south traffic and for other network services. In this example VPC VR is deployed on host 3. A logical router which is nothing but a OVS bridge is provisioned on the rest of the hosts (excluding the host running VPC VR) in on which VPC spans. On the host on which VPC VR is running there is no need for a logical router (bridge). Irrespective of weather a host has VM's belonging to a tier or not, a bridge is setup on each host for each tier on the all of the hosts on which VPC spans. For e.g. host 1, does not have any tier 2 VM's still a bridge is created and is in full-mesh topology with the bridges created for tier 2 on host 2 and 3. Each of the logical router on the host is connected with patch ports [3] to the bridges corresponding to tiers. This setup of logical router is done to emulate a VPC VR with which has nics connected to bridges corresponding to each tier.

with With the understanding of how bridges , corresponding to the tiers in VPC are interconnected with a logical router are interconnected with using patch ports lets see the how flow rules are setup. Lets assume tier1, tier 2 and tier3 has subnets 10.1.1.0/24, 10.1.2.0/24 and 10.1.3.0/24 respectively. can be setup to achieve distributed routing and network ACL. There are three different flow configurations on different bridges.

  • bridge bridges connected to logical router with patch port
  • bridge bridges connected to VPC VR (hence no patch port)
  • bridge corresponding to logical router

...

Flows rules for bridge connected to VPC VR: no new additional flow rules are added to such bridges apart from what is added by OVS tunnel manager currently.  Bridge will just act as a mac learning L2 switch with rules to handle broadcast/multicast traffic. To recap from [4] below are the flow rules. there is single table 0 for all the rows.

  • priority:1200 :- allow all incoming broadcast (dl_dst=ff:ff:ff:ff:ff:ff) and multicast (nw_dst=224.0.0.0/24) traffic from the VIF's that are connected to the VM's
  • priority:1100 :-permit broadcast (dl_dst=ff:ff:ff:ff:ff:ff) and multicast (nw_dst=224.0.0.0/24) traffic to be sent out ONLY on the VIF's that are connect to VM's (i.e excluding the tunnel interfaces)
  • priority:1000 :- suppress all broadcast/multicast ingress traffic on GRE tunnels
  • priority:0 :- do NORMAL processing on the rest of the flows. this rule will ensure (due to NORMAL processing) new mac address seen from a interface is learned

...

Flows rules for bridge connected to logical router with patch port will need additional rules to deal with patch port and ensure:

  • explicitly do MAC learning only on VIF's connected to the VM's and on tunnel interfaces. So MAC learning on patch port (to avoid learning the gateway MAC address for the subnet corresponding to tier) is excluded
  • for unknown mac address flood packets only on VIF's connected to the VM's and on tunnel interfaces
  • on patch port only permit traffic destined to other subnets of VPC

Below are the diagram depicts the pipeline processing setup with flow rules:.

 

  • priority 1200:- allow all incoming broadcast (dl_dst=ff:ff:ff:ff:ff:ff) and multicast (nw_dst=224.0.0.0/24) traffic from the VIF's that are connected to the VM's
  • priority 1100 :-permit broadcast (dl_dst=ff:ff:ff:ff:ff:ff) and multicast (nw_dst=224.0.0.0/24) traffic to be sent out ONLY on the VIF's that are connect to VM's (i.e excluding the tunnel and patch interfaces)
  • priority 1000 :- suppress all broadcast/multicast ingress traffic on GRE tunnels
  • priority 1: all incoming packets on patch port, just flood
  • priority:0 :- do NORMAL processing on the rest of the flows. this rule will ensure (due to NORMAL processing) new mac address seen from a interface is learned

 

logical router:

 

Lets assume tier1, tier 2 and tier3 has subnets 10.1.1.0/24, 10.1.2.0/24 and 10.1.3.0/24 respectively. 

Fall back approach:

Achieving distributed routing and network ACL, would need distributed configuration. Given the scale of changes that would involve  

...