> -----Original Message----- > From: Maule Mark [mailto:mark_ma...@yahoo.com] > Sent: Thursday, April 30, 2015 8:08 AM > To: e1000-devel@lists.sourceforge.net > Subject: [E1000-devel] i40e and RSTP > > Hi: > I have a small 4 node private network where each node has 2 ports, with > each port directly connected to a port on another node in such a way that > a ring topology is formed. Two of the nodes have NIC's controlled by the > e1000 driver, two of the nodes have NIC's controlled by the i40e > driver. The OS is based on Linux 3.8.13. > I bridge the 2 portss on each node, and am using user space RSTP to manage > the loop. > What I am seeing is that the bridge ports on the nodes with i40e based > NIC's are not receiving BPDU's, and so all ports remain forwarding, > resulting in a loop. Using a packet capture program to monitor enet > frames, it seems that the interfaces for the i40e NIC's never see ethernet > frames from its direct connected peer destined to > the 01:80:C2:00:00:00 multicast address. They do see unicast and > broadcast frames from the peer. The direct connected peer (e1000 based > nic) does see BPDU frames being sent out the i40e based NIC's. > If I move to a config having all e1000 based NIC's, everything works fine. > I'm fairly new to networking hw, so I assume I need to turn some > configuration knobs on the i40e in order to receive the BPDU's. > I am currently not doing any configuration on the i40e interfaces - just > modprob'ing i40e to load it, and then standard commands to bring up the > interface, bridge it, and assign an ip address. > Any advice would be greatly appreciated.
When running in a bridged environment there is a work around required. The information is in the README that comes with the driver. Please review and make sure that your issue is not related to the one described in the README. I've pasted in the relevant section to save you some time. While you don't mention SR-IOV or NPAR modes of operation you may still be seeing a bug related to the root cause, which is incorrect source pruning. Make sure that all packets being sent by the i40e driver have a source MAC address in the bridge FDB. If this doesn't help then we'll have to explore other options. Regards, - Greg ------------------------------------------------------------------------------ In SR-IOV enabled or NPAR enabled adapters, Physical Function (PF) does not work in bridge mode. When a bridge is created on the PF device, an emulation device in the Virtual Machine (VM) connects to this bridge cannot receive any unicast packets. To avoid this from occurring, for each emulated device (software Virtual Station Interface [VSI]) added to the bridge the MAC address of the emulated device (software Virtual Ethernet Bridge [VEB] VSI) needs to be added manually to the forwarding database (FDB) filter table using the iproute2 package bridge tool. This can be done by executing the following command: # bridge fdb add <MAC ADDR> dev <PF device interface> self permanent The FDB entry when the emulated device is no longer in use or the guest to which it is assigned is moved to a different host must be deleted using this command: # bridge fdb del <MAC ADDR> dev <PF device interface> ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
