yahoo-eng-team team mailing list archive

[David Shaughnessy <david.shaughnessy@xxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1705536

Title:
  [RFE] L3-agent agent-mode dvr bridge.

Status in neutron:
  New

Bug 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1705536/+subscriptions