Thanks for your comments. I used a linux bridge before -> TAP (as in
network tap) simulates a link layer device and it operates with layer 2
packets such as Ethernet frames...shouldnt it also forward lldp frames
(layer 2)?
What about the following setup...I just replaced the virtual NIC (tap 0)
with another physical NIC (eth3):
fcoe initiator (external)
|
|
-------
| |
|
eth2.569 (ixgbe) eth3.569(ixgbe)
| |
|
--------- OVS bridge--------------- ------------- Fcoe
target
I want to replace the OVS bridge with a Soft Switch later on...that's why
I make this effort...would that work?
There are 2 physical NICs in the Linux machine, eth3 is back to back
connected, DCB and lldp is enabled on both NICs...
OVS bridge set to:
sudo ovs-vsctl add-br vir-br
sudo ovs-vsctl add-port vir-br eth2
sudo ovs-vsctl add-port vir-br eth3
Thanks,
Gerald
-----Original Message-----
From: John Fastabend [mailto:[email protected]]
Sent: Tuesday, August 27, 2013 5:19 PM
To: Neil Horman; Gerald Stanje
Cc: [email protected]
Subject: Re: [Open-FCoE] DCBTool fails on tap0
On 8/27/2013 4:47 PM, Neil Horman wrote:
> On Tue, Aug 27, 2013 at 11:17:20AM -0700, Gerald Stanje wrote:
>> So the missing priority flow control is the only limitation?
>
> I think so, yes. At least its the only direct limitation.
FCoE expects something close to a lossless fabric so if you have
congestion on the network and start dropping FCoE this will hurt
performance/usability.
Although if you run PFC or just flow control on the real physical devices
"ethx" then there should be no limitation. With PFC you will need to
ensure the FCoE traffic is en-queued on the correct traffic class. This is
done by setting the skb->priority.
>
>>
>> Is the LUID Exchange not necessary in FCoE VN2VN mode?
> That I'm not sure about.
>
>> - Probe Request (#1) (Multicast: All_VN2VN_Enode_MACs)
>> - Claim Notification (Multicast: All_VN2VN_Enode_MACs, inc. FC-4
>> attributes)
>> - Beacon (Multicast: Send every Beacon_Period)
>>
>> On the target side (open fcoe) I just need to start the following
>> services without any lldpad and further dcbtool settings?
>>
> Well, you still want to run lldpad because there might be other
> exchanges that other elements of the stack need, like the vlan id's
> that fcoe runs over. If you're auto creating vlans. Although I'm not
> quite sure how lldpad works with tap devices. It should work, I just
don't know what it looks like to the peer.
Well typically your tap device will be behind a linux bridge or ovs
instance right? In this case the linux bridge will drop the LLDP packets
because they use the nearest bridge or nearest customer bridge MAC
address. An OVS bridge would likely depend on the flow configuration but
if it is acting as a standards based L2 bridge it should also drop the
LLDP packets.
I think the best way to go about this is to run lldpad with DCBX over the
real interface attached to the switch. Then lldp will talk to the peer and
any of the link attributes it negotiates DCBX or otherwise need to be
pushed up the stack. In this case you could configure PFC on the real
device and then its just a matter of classifying the FCoE packets so they
get put in the right traffic class as noted above.
.John
> Neil
>
>
>> lldpad -k # terminate curreny running lldpad service lldpad stop #
>> just in case if it's started service fcoe restart echo eth2.569 >
>> /sys/module/libfcoe/parameters/create_vn2vn
>> echo eth2.569 > /sys/module/libfcoe/parameters/enable
>> dcbtool sc eth2 dcb off # switch dcb off
>>
>> Thanks,
>> Gerald
>>
>> -----Original Message-----
>> From: Neil Horman [mailto:[email protected]]
>> Sent: Monday, August 26, 2013 12:50 PM
>> To: Gerald Stanje
>> Cc: [email protected]
>> Subject: Re: [Open-FCoE] DCBTool fails on tap0
>>
>> On Mon, Aug 26, 2013 at 12:04:28PM -0700, Gerald Stanje wrote:
>>> Hello Neil,
>>>
>>> What's the workaround?
>>>
>>> Thanks,
>>> Gerald
>>>
>> To the best of my knoweldge, just don't set dcb settings on the
adapter.
>> IIRC if your adapter doesn't support dcb, then you just send vlan
>> encapsulated fcoe frames on the same output queue as any other traffic.
>> You loose the ability to do hardware priority classification of
>> course, but theres no way around that Neil
>>
>>> -----Original Message-----
>>> From: Neil Horman [mailto:[email protected]]
>>> Sent: Monday, August 26, 2013 11:28 AM
>>> To: Gerald Stanje
>>> Cc: [email protected]
>>> Subject: Re: [Open-FCoE] DCBTool fails on tap0
>>>
>>> On Mon, Aug 26, 2013 at 10:50:55AM -0700, Gerald Stanje wrote:
>>>> Hello,
>>>>
>>>>
>>>>
>>>> I use VN2VN mode and tried to create the following topology:
>>>>
>>>>
>>>>
>>>> eth2.569 (ixgbe) tap0.569------ fcoe
>> target
>>>>
>>>> |
|
>>>>
>>>> --------------- virbr1---------------
>>>>
>>>>
>>>>
>>>> I attached my script including output and the syslog at the end.
>>>>
>>>> Why does the call dcbtool fail with this message: Device not found,
>>>> link down or DCB not enabled???
>>>>
>>> Because the tap0 interface, being a software defined virtual
>>> interface has no hardware to enable DCB on.
>>>
>>> Neil
>>>
>> _______________________________________________
>> fcoe-devel mailing list
>> [email protected]
>> http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
>>
> _______________________________________________
> fcoe-devel mailing list
> [email protected]
> http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
>
_______________________________________________
fcoe-devel mailing list
[email protected]
http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
