| 2019-04-09 14:20:17 |
David Shaughnessy |
description |
The use of linux network namespaces in the l3 agent routers causes a choke point for bandwidth on east/west and north/south traffic.
In the case of east/west traffic, the source and destination interfaces are known to Neutron and could be routed using Open vSwitch if it is selected as the mechanism_driver for the L2-agent.
This should allow the l3-agent to be compatible with DPDK and Windows.
When using network namespaces with Open vSwitch to route an l3 ping packet:
- arp from source vm -> tap1 (vlan tagging skipped) + broadcast to other ports
- tap1-> kernel network stack
- kernel sends arp reply tap1
- tap1-> source vm (vlan tagging skipped)
- icmp from source vm -> tap1(vlan tagging skipped)
- kernel receives icmp on tap1 and send arp request to dest vm via tap2(broadcast)
- arp via tap2 -> dest vm (vlan tagging skipped)
- dest vm replies -> tap2
- kernel updates dest mac and decrement ttl the forward icmp packet to tap2
- tap2 -> dest vm-> dest vm replies->tap2.(vlan tagging skipped)
- kernel updates dest mac and decrement ttl the forward icmp reply packet to tap1
- tap1-> source vm
When OpenFlow is used to route the same traffic:
- arp from source vm -> arp rewritten to reply -> sent to source vm ( single openflow action).
- icmp from source vm -> destination mac update, ttl decremented -> dest vm ( single openflow action)
- icmp from dest vm -> destination mac update, ttl decremented -> source vm ( single openflow action)
Introducing a new agent_mode would allow an operator to select which implementation is most suitable to their use case. |
The use of linux network namespaces in the l3 agent routers causes a choke point for bandwidth on east/west and north/south traffic.
In the case of east/west traffic, the source and destination interfaces are known to Neutron and could be routed using Open vSwitch if it is selected as the mechanism_driver for the L2-agent.
This should allow the l3-agent to be compatible with DPDK and Windows.
When using network namespaces with Open vSwitch to route an l3 ping packet:
- arp from source vm -> tap1 (vlan tagging skipped) + broadcast to other ports
- tap1-> kernel network stack
- kernel sends arp reply tap1
- tap1-> source vm (vlan tagging skipped)
- icmp from source vm -> tap1(vlan tagging skipped)
- kernel receives icmp on tap1 and send arp request to dest vm via tap2(broadcast)
- arp via tap2 -> dest vm (vlan tagging skipped)
- dest vm replies -> tap2
- kernel updates dest mac and decrement ttl the forward icmp packet to tap2
- tap2 -> dest vm-> dest vm replies->tap2.(vlan tagging skipped)
- kernel updates dest mac and decrement ttl the forward icmp reply packet to tap1
- tap1-> source vm
When OpenFlow is used to route the same traffic:
- arp from source vm -> arp rewritten to reply -> sent to source vm ( single openflow action).
- icmp from source vm -> destination mac update, ttl decremented -> dest vm ( single openflow action)
- icmp from dest vm -> destination mac update, ttl decremented -> source vm ( single openflow action)
Introducing a new agent_backend configuration would allow an operator to select which implementation is most suitable to their use case. |
|
