OK, here is what I have in one of my boxes (the other box has pretty much
the same, except for slightly different mac address for the port/bridge):
[sabyasse@sabyasg-lnx-99 sabyasse]$ sudo ovs-vsctl show
2677960f-42ff-42f0-b368-0bfbfa7b923d
Bridge "br0"
Port "br0"
Interface "br0"
type: internal
Bridge "br1"
Port "br1"
Interface "br1"
type: internal
Port "eth2.10"
Interface "eth2.10"
[sabyasse@sabyasg-lnx-99 sabyasse]$ sudo ovs-ofctl dump-ports-desc br1
OFPST_PORT_DESC reply (xid=0x2):
1(eth2.10): addr:08:00:27:9d:1e:1e <<<< BFD enabled port
config: 0
state: 0
current: 1GB-FD COPPER AUTO_NEG
advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
speed: 1000 Mbps now, 1000 Mbps max
LOCAL(br1): addr:aa:bb:cc:dd:ee:00
config: PORT_DOWN
state: LINK_DOWN
speed: 0 Mbps now, 0 Mbps max
Here is what I did on both nodes:
1. created the bridge
2. created vlan and ifconfig up'd it
3. created the port with BFD config
sudo ovs-vsctl add-port br1 eth2.10 -- set interface eth2.10 bfd:enable=true
bfd:min_tx=500 bfd:min_rx=500 bfd:bfd_remote_dst_mac=00:ee:dd:cc:bb:aa
But it seemed like the BFD packet never left the host as I got nothing
on the eth2.10 interface in tcpdump, but yet there were lots of BFD
send/receive messages in openvswitch.log (enabled vlog/set bfd:file:dbg).
Upon gdb'ing I found that it ofproto_dpif_send_packet --> xlate_send_packet
--> ofproto_dpif_execute_actions --> xlate_actions --> process_special
--> bfd_should_process_flow, which returned SLOW_BFD. The problem went away
after I added the last part of the #3 above (ie. the bfd_remote_dst_mac
construct). Am I missing something here?
On Tue, 3 Feb 2015, Alex Wang wrote:
Hey,
On Tue, Feb 3, 2015 at 2:19 PM, Sabyasachi Sengupta
<sabyasachi.sengu...@alcatel-lucent.com> wrote:
Hi,
I'm trying to set up BFD between two vlans created on
different bridges running on different hosts. I noticed that
unless bfd:bfd_remote_dst_mac is specified while setting up
the BFD, the packet never leaves the host switch due to
"skipping output to input port". Looking at RFC 5880/5881,
there is no specification about the encapsulating packet
itself, so I reckon this should be implementation dependent.
I'm wondering if it makes sense to have a dummy (default) mac
address as rmt_eth_dst so that bfd_should_process_flow does
not flag the outgoing as something to be processed as a
received packet? Thoughts? If so, I can send over a patch..
bfd_should_process_flow() has nothing to do with sending bfd control
packets.
If you do not specify 'bfd_local_src_mac' or 'bfd_local_dst_mac', the
inner
packet will use the OpenFlow port's mac as src mac and 00:23:20:00:00:01
as dest mac. And you should have no issue sending the bfd control
packets.
Could you show me you ovs configuration (ovs-vsctl show output, and on
which port you enable bfd)? I suspect there could be something wrong
with
the configuration...
Thanks,
Alex Wang,
Thanks,
Sabya
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
