This group is locked. No changes can be made to the group while it is locked.
Re: bfd implementation in OVS
toggle quoted message Show quoted text
thanks ravi and alex! ravi, alex has also confirmed that the pkts are vxlan encapsulated, outer IP would have to be the TEP IP, and inner IP is immaterial since the slow path at the receiver would essentially ignore it.
From: "Ravi_Sabapathy@..." <Ravi_Sabapathy@...>
To: daya_k@...; discuss@...
Cc: ovsdb-dev@...; C_Venkataraghavan@...
Sent: Wednesday, August 26, 2015 2:28 PM
Subject: RE: [ovsdb-dev] bfd implementation in OVS
BFD operates on top of any data protocol (network layer, link layer, tunnels(vxlan tunnel), etc.) being forwarded between two systems. BFD provides failure detection on direct physical links, virtual circuits, tunnels(vxlan tunnel) etc. If BFD is run over a VXLAN tunnel, the BFD packets will be encapsulated inside the VXLAN header.
Inner IPv4 Header:
|Version| IHL |Type of Service| Total Length |
| Identification |Flags| Fragment Offset |
| TTL = 1 |Protocol=17(UDP)| Header Checksum |
| Inner Source IPv4 Address |
| Inner Destination Ipv4 Address = 127/8 address |
The above picture shows a sample Inner IPv4 Header for BFD. The TTL =1 that was mentioned in the link (http://openvswitch.org/pipermail/discuss/2015-February/016515.html) should corresponds to the inner IPv4 TTL.
As per BFD specification, the protocol should be run between 2 systems.
1. On a physical network it will be between 2 links.
2. On a tunnel/overlay network, it will be between 2 end points.
So, ideally the TTL value should be 1 or single hop.
Consider your scenario where VXLAN is formed between 2 OVS switches over a WAN network. How will the VM's connected to these switches communicate?
The OVS should not bother about the underlay network and worry only about the VXLAN tunnel. In the same way, BFD will be transmitted to the tunnel end point (TEP) over the VXLAN tunnel and consider it as a single hop.
For example consider the tunnel end points
22.214.171.124 and 126.96.36.199
From the TEP 188.8.131.52, VXLAN encapsulated BFD packet is sent. The intermediate routers or switches should not consume the BFD packet. Only TEP (184.108.40.206) switch should de-encapsulate the BFD packet and send it to the BFD protocol. The BFD protocol control messages will be exchanged in this manner. If the BFD control message are not properly exchanged between TEP’s as per agreement, then the BFD protocol should intimate the link down to the OVS. OVS can update it in the Physical locator table.
The above said statements may not be true for OVS implementation of BFD. I have said in the context of a hardware switch using proprietary BFD protocol.
I think the BFD IP should be the tunnel IP, since we run BFD protocol between the VXLAN TEP.
From: ovsdb-dev-bounces@... [mailto:ovsdb-dev-bounces@...] On Behalf Of daya kamath
Sent: Tuesday, August 25, 2015 5:27 PM
Cc: Ovsdb-dev <ovsdb-dev@...>
Subject: [ovsdb-dev] bfd implementation in OVS
i would like some clarification on the BFD implementation in OVS.
http://openvswitch.org/pipermail/discuss/2015-February/016515.html indicates the BFD is not multi-hop but sent through the tunnel.
can someone please clarify, if i create a VXLAN tunnel between 2 OVS switches over a WAN,
1. will the BFD work, i.e will BFD packets be VXLAN encapsulated, and delivered as if it were a single hop?
2. if yes, how does the OVS detect BFD payload after stripping off the VXLAN header on an incoming packet?
3. what does the VTEP put in the inner source and dest IP fields for BFD pkts? does it put the same values as the outer header?