hi Sir
sorry to disturb you once again
As it implies from the previous discussions that configurations in virtual
environment(Sun Virtual Box) seems clumsy and unreal ,
I tried to switch to real hardware
wanted to get some issues answered
- I do not have a server architecture nor a scsi disk ; *so will normal
SATA disk work as target disk?*
- Also i have set up FCoE target on Fedora 8 and then added the target
disk, but *fcconf returns* error as pause settings are not enabled
- linux-ihct:/home/pxe123 # ethtool -A eth0 tx on rx on
Cannot get device pause settings: *Operation not supported*
- *linux-g557:/ # ethtool -a eth0*
Pause parameters for eth0:
Cannot get device pause settings: Operation not supported
Please help me with this.
Thank you,
-vinvishwa
On Thu, Feb 11, 2010 at 1:23 AM, Joe Eykholt <jeykh...@cisco.com> wrote:
> vinvishwa wrote:
>
>> Have you tried putting both sides in promiscuous mode?
>>
>>
>> No I didn't (as i didn't know how to)
>> But I will surely do this
>>
>> I looked at the traces. showed FLOGIs
>> from both sides but no accepts from either. I can't explain that.
>> The other trace showed FLOGIs only from the initiator, nothing
>> received from the target. Why the difference? Was the wireshark
>> done on the target side? Wireshark will go promiscuous, so maybe
>> that's the difference.
>>
>>
>> The trace
>> fcoe_pcap_100110.pcap is from Wireshark running on host m/c(windows XP.)
>>
>> (the target and initiator are VMs in Sun Virtual box and both are using
>> bridged network)
>>
>> and the 2nd trace named file was taken at the *initiator side
>> *with the tcpdump cmd
>> tcpdump -p -i ethX -w /tmp/file -s 0
>> *Does that mean that the inititor did not receive any of the FLOGIs sent
>> by the target?*
>> (but both the initiator and target m/cs can ping each other)
>>
>
> One problem is that the unicast address used by the FLOGI doesn't
> work on switches, it's really meant to be point-to point (no switch).
> The FLOGI is sent to MAC 0e:fc:00:ff:ff:fe, a unicast address.
> The switch should flood that to all ports since it doesn't know
> the address. The virtual switch may not do that since it "thinks"
> it knows all the MAC addresses on the guests. That would explain
> why none of the ports receive the FLOGI.
>
> If there was a way to directly connect the NICs of the two guests,
> that would be nice, but there probably isn't since this is such
> a special case.
>
> I will do the steps suggested by you and will send it to you
>>
>> Thank you really very much
>> -vinvishwa
>>
>>
>> On Wed, Feb 10, 2010 at 11:31 PM, Joe Eykholt <jeykh...@cisco.com<mailto:
>> jeykh...@cisco.com>> wrote:
>>
>> Joe Eykholt wrote:
>>
>> vinvishwa wrote:
>>
>> hello Sir,
>>
>>
>> On Mon, Feb 8, 2010 at 5:25 PM, Joe Eykholt
>> <jeykh...@cisco.com <mailto:jeykh...@cisco.com>
>> <mailto:jeykh...@cisco.com <mailto:jeykh...@cisco.com>>>
>> wrote:
>>
>> vinvishwa wrote:
>>
>> Thank you sir for replying
>> It made many things clear and also the problem with my
>> configuration.
>>
>> but the issue with my configuration still remains
>> unsolved.
>>
>> and you said its currently broken
>> so is there any workaround to get my point to point
>> setup working?
>>
>>
>>
>> * (*my setup in Sun Virtual Box
>> *initiator*: 2.6.33-rc4 on Fedora Core
>> 12 with
>> fcoeadm tool
>> *target*: 2.6.23 on Suse Linux
>> Enterprise Server
>> initiator-target connected
>> over lossless
>> connection in Sun Virtual Box(intel e1000 :bridged
>> *pause frames
>> enabled*)
>> *)*
>>
>>
>> Actually, I may have mis-spoken earlier. I just tried it
>> and a similar
>> setup just worked for me. I'm running the same release
>> on the
>> initiator,
>> and the target is 2.6.23-1. I'm running on real servers,
>> though,
>> not under a virtual machine. It really shouldn't matter,
>> however,
>> as long as the virtual NIC works correctly. I'm running
>> Fedora 8
>> on my target, and Fedora 10 on the initiator.
>>
>> I tried it with the initiator having the larger WWPN and
>> also with
>> the target having the larger WWPN, in case there was a bug
>> related to that.
>>
>> It will take a few retries for FLOGI to go through because
>> it waits to see if FIP will work first.
>> If it doesn't work for you, then I don't know what it is.
>> You could send me binary tcpdump capture and I might be able
>> to point out the problem. Use
>>
>> tcpdump -p -i ethX -w /tmp/file -s 0
>>
>> before you do 'fcoeadm -c ethX' on the initiator side.
>>
>> i am attaching the tcp dump file
>> also the wireshark tcpdump
>> please have a look and help me solve the issue.
>>
>> You could also try putting the interface on both sides into
>> promiscuous mode, in case its a MAC filter problem.
>>
>> The reason I gave the -p parameter on tcpdump is so that
>> it *doesn't* go promiscuous, since it might hide the
>> problem.
>>
>> Good luck,
>> Joe
>>
>> thank you.
>>
>>
>>
>>
>> On Mon, Feb 8, 2010 at 11:39 PM, Joe Eykholt
>> <jeykh...@cisco.com <mailto:jeykh...@cisco.com>
>> <mailto:jeykh...@cisco.com
>> <mailto:jeykh...@cisco.com>> <mailto:jeykh...@cisco.com
>>
>> <mailto:jeykh...@cisco.com>
>> <mailto:jeykh...@cisco.com
>> <mailto:jeykh...@cisco.com>>>> wrote:
>>
>> vinvishwa wrote:
>>
>> hi,
>> i am trying to figure out the fcoe login
>> process in a
>> point to point
>> architecture
>>
>> In my setup the *target sends out FLOGIs*
>> (this is right
>> as per the
>> quickstart guide at open-fcoe)
>>
>> when the initiator is started it sends an *FIP
>> solicitation*
>> and then starts sending FLOGIs but is *not
>> able to login*
>>
>> Can someone please elaborate the *point to
>> point fcoe
>> login* process
>>
>>
>> It is currently broken. The old target expects a
>> non-standard interface
>> in which the other end accepts the FLOGI with the
>> fabric flag off
>> indicating
>> point to point, and with the assigned FC_IDs in
>> the FLOGI accept.
>> I'm not sure why that's been broken in the
>> initiator, but
>> point-to-point
>> mode hasn't been enough of a priority.
>>
>> The correct, standard FC way of doing it is for
>> both sides to
>> send a
>> LS_ACC for FLOGI from fffffe to 0 and then for the
>> one with the
>> higher WWPN
>> to decide the FC_IDs and do a PLOGI.
>>
>> There's a FIP proposal (at least one) to do VN to
>> VN port
>> without a
>> fabric,
>> and I hope we'll implement that at some point.
>>
>> The current initiator sends out both a FIP
>> solicitation and
>> non-FIP
>> FLOGIs
>> until it receives either a FIP frame, at which
>> point it
>> enters FIP mode,
>> or an LS_ACC for the FLOGI, at which point it
>> continues in
>> non-FIP mode.
>>
>>
>> Also i tried to figure out the fcoe initiator
>> code but
>> couldn't
>> get the
>> starting point
>> Plz help me with the entry point of
>> the code
>>
>>
>> The module_init fcoe_init() is one entry point.
>> Another is
>> the code
>> that handles
>> the creation of an new initiator thru /sys write:
>> fcoe_create().
>>
>> Joe
>>
>>
>>
>>
>> -- -vinvishwa
>>
>>
>> I don't know what the problem is.
>>
>> Have you tried putting both sides in promiscuous mode?
>>
>> ifconfig ethX promisc
>>
>> I don't really think that will fix it, but it is worth a try.
>>
>> I looked at the traces. fcoe_pcap_100110.pcap showed FLOGIs
>> from both sides but no accepts from either. I can't explain that.
>> The other trace showed FLOGIs only from the initiator, nothing
>> received from the target. Why the difference? Was the wireshark
>> done on the target side? Wireshark will go promiscuous, so maybe
>> that's the difference.
>>
>> On the initiator side, you could enable debug logging and that
>> might help us figure it out. Do this as root after the
>> initiator is started:
>>
>> echo 15 > /sys/module/libfc/parameters/debug_logging
>> echo 3 > /sys/module/fcoe/parameters/debug_logging
>>
>>
>> Also add:
>>
>> echo 3 > /sys/module/libfcoe/parameters/debug_logging
>>
>> We might as well get everything we can get!
>>
>>
>> dmesg -n 8
>> # wait at least 10 seconds with the initiator running then:
>> dmesg | tail
>>
>>
>> Make that
>> dmesg | tail -100
>>
>> so we get a good hunk of log. If you could send that, it may help.
>>
>>
>> Good luck.
>>
>> Joe
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel@open-fcoe.org <mailto:devel@open-fcoe.org>
>>
>> http://www.open-fcoe.org/mailman/listinfo/devel
>>
>>
>>
>>
>
_______________________________________________
devel mailing list
devel@open-fcoe.org
http://www.open-fcoe.org/mailman/listinfo/devel
