Sure enough, that did the trick!
Now, the next question is, why do I need to do that on i40e when I don't on
e1000? I don't see the BPDU maddr present in the 'ip mroute' or 'bridge fdb'
output on the e1000 side of the link, which works by default.
e1000 side of the link - 00:21:28:f9:09:5d
[root@pilot1 ~]# ip maddr show dev eth23: eth2 link
33:33:00:00:00:01 link 01:00:5e:00:00:01 link 33:33:ff:f9:09:5d
inet 224.0.0.1 inet6 ff02::1:fff9:95d inet6 ff02::1
[root@pilot1 ~]# bridge fdb33:33:00:00:00:01 dev eth1 self
permanent01:00:5e:00:00:01 dev eth1 self permanent33:33:ff:f9:09:5c dev eth1
self permanent33:33:00:00:00:01 dev eth2 self permanent01:00:5e:00:00:01 dev
eth2 self permanent33:33:ff:f9:09:5d dev eth2 self permanent33:33:00:00:00:01
dev eth3 self permanent01:00:5e:00:00:01 dev eth3 self
permanent33:33:ff:f9:09:5e dev eth3 self permanent33:33:00:00:00:01 dev eth0
self permanent01:00:5e:00:00:01 dev eth0 self permanent33:33:ff:f9:09:5f dev
eth0 self permanent00:10:e0:65:2c:ae dev eth100:10:e0:65:2e:64 dev
eth200:21:28:f9:09:5c dev eth1 permanent00:10:e0:65:2e:65 dev
eth200:21:28:f9:09:5d dev eth2 permanent00:21:28:f9:09:2c dev eth1
i40e side of the link - 00:10:e0:65:2e:65 - after manually adding with ip maddr
WNFFFFFFFFFFFFFFEE # ip maddr show dev eth112: eth1 link
01:00:5e:00:00:01 link 33:33:00:00:02:02 link 33:33:00:00:00:01
link 33:33:ff:65:2e:65 link 00:00:00:00:00:00 static
link 01:80:c2:00:00:00 static inet 224.0.0.1 inet6
ff02::1:ff65:2e65 inet6 ff02::202 inet6 ff02::1
WNFFFFFFFFFFFFFFEE # bridge fdb00:10:e0:65:2e:64 dev eth0
permanent00:10:e0:65:2e:65 dev eth1 permanent00:21:28:f9:09:2c dev
eth100:10:e0:65:2c:ae dev eth100:21:28:f9:09:5c dev eth100:21:28:f9:09:5d dev
eth1
From: "Rose, Gregory V" <gregory.v.r...@intel.com>
To: Maule Mark <mark_ma...@yahoo.com>; "e1000-devel@lists.sourceforge.net"
<e1000-devel@lists.sourceforge.net>
Sent: Thursday, April 30, 2015 11:33 AM
Subject: RE: [E1000-devel] i40e and RSTP
#yiv0823098310 #yiv0823098310 -- _filtered #yiv0823098310
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv0823098310
{font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv0823098310
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0823098310
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv0823098310
#yiv0823098310 p.yiv0823098310MsoNormal, #yiv0823098310
li.yiv0823098310MsoNormal, #yiv0823098310 div.yiv0823098310MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0823098310 a:link,
#yiv0823098310 span.yiv0823098310MsoHyperlink
{color:blue;text-decoration:underline;}#yiv0823098310 a:visited, #yiv0823098310
span.yiv0823098310MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv0823098310
p.yiv0823098310MsoListParagraph, #yiv0823098310
li.yiv0823098310MsoListParagraph, #yiv0823098310
div.yiv0823098310MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0823098310
span.yiv0823098310EmailStyle17
{color:#1F497D;font-weight:normal;font-style:normal;text-decoration:none
none;}#yiv0823098310 .yiv0823098310MsoChpDefault {font-size:10.0pt;} _filtered
#yiv0823098310 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0823098310
div.yiv0823098310WordSection1 {}#yiv0823098310 _filtered #yiv0823098310 {}
_filtered #yiv0823098310 {} _filtered #yiv0823098310 {} _filtered
#yiv0823098310 {font-family:Wingdings;} _filtered #yiv0823098310
{font-family:Symbol;} _filtered #yiv0823098310 {} _filtered #yiv0823098310
{font-family:Wingdings;} _filtered #yiv0823098310 {font-family:Symbol;}
_filtered #yiv0823098310 {} _filtered #yiv0823098310
{font-family:Wingdings;}#yiv0823098310 ol {margin-bottom:0in;}#yiv0823098310 ul
{margin-bottom:0in;}#yiv0823098310 I don’t see the multicast address for the
BPDU in the bridge. Can you explicitly add the BPDU multicast address to the
Fortville HW filters using the ‘ip maddr’ command? Normally a service will
register the associated multicast addresses with the network interface but that
doesn’t seem to be happening. Try that and let’s see if it helps. Thanks,
- Greg
From: Maule Mark [mailto:mark_ma...@yahoo.com]
Sent: Thursday, April 30, 2015 9:04 AM
To: Rose, Gregory V; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] i40e and RSTP eth1 is the e40i port attached to
the bridge. Currently I have only one port bridged in order to prevent the
loop. eth1 Link encap:Ethernet HWaddr 00:10:E0:65:2E:65
WNFFFFFFFFFFFFFFEE # bridge fdb 00:10:e0:65:2e:65 dev eth1 permanent
00:21:28:f9:09:2c dev eth1 00:21:28:f9:09:5c dev eth1 00:10:e0:65:2c:af dev
eth1 If it matters, I'm using this version of i40e (shipped with the
kernel): #define DRV_VERSION_MAJOR 1 #define DRV_VERSION_MINOR 2 #define
DRV_VERSION_BUILD 2 Could not find a i40e README under the kernel src or
Documentation directory.
From: "Rose, Gregory V" <gregory.v.r...@intel.com>
To: Maule Mark <mark_ma...@yahoo.com>; "e1000-devel@lists.sourceforge.net"
<e1000-devel@lists.sourceforge.net>
Sent: Thursday, April 30, 2015 10:42 AM
Subject: RE: [E1000-devel] i40e and RSTP
> -----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
