[Bug 1541544] Comment bridged from LTC Bugzilla

[bugproxy]

------- Comment From brueckner at de.ibm.com 2016-02-08 07:33 EDT-------
Hi,

thanks for this important information.  It would advice to list these
also in the Device Drivers Book. I have seen that information not before
and it could help to improve the implementation of the s390-netdevice.

(In reply to comment #10)
> Virt.NIC QDIO - depends on the z/VM layer configured, more details below
> Virt.NIC Hiper - always layer3
> Virt.NIC OSM - that's dead code, does not occur, I will add the removal on
> my to do list, any default is ok
> Virt.NIC OSX - that's dead code, does not occur, I will add the removal on
> my to do list, any default is ok
> unknown - should hopefully not occur, thus any default is ok
> OSD_100 - both layers possible, use layer2 as default
> HSTR - token ring no longer supported, does not occur, has been layer3 only
> OSD_1000 - both layers possible, use layer2 as default
> OSD_10GIG - both layers possible, use layer2 as default
> OSD_FE_LANE - outdated type, does no longer occur, has been layer3 only
> OSD_TR_LANE - token ring no longer supported, does not occur, has been
> layer3 only
> OSD_GbE_LANE - outdated type, does no longer occur, has been layer3 only
> OSD_ATM_LANE - outdated type, does no longer occur, has been layer3 only
> OSD_Express - both layers possible, use layer2 as default
> HiperSockets - both layers possible, use layer3 as default
> OSN - special case, needed for an IBM product already approaching end of
> life time (end of service effective 2016-03-31), does not have a layer2
> attribute at all, ignore?
> OSM_1000 - always layer2
> OSX_10GIG - both layers possible, use layer2 as default
>
> As you see, there are still some outdated OSA-types listed, which we have
> not yet removed to still enable running on old hardware. They are not
> critical, and you can configure them as you like.

Is there a sysfs attribute to get a numeric type for these or does an
implementation needs to parse the strings?

>
> A problematic type is "Virt.NIC QDIO". Here qeth does not yet determine the
> layer of the z/VM VSWITCH automatically. zVM commands allow to determine the
> layer. You could first determine the name of the VSWITCH, a virtual NIC is
> connected to - with "vmcp q virtual nic <vdev>" .
> Sample:
>    > vmcp QUERY VIRTUAL NIC f5f0
>    Adapter F5F0.P00 Type: QDIO      Name: HYD1G1      Devices: 3
>    MAC: 02-12-34-56-78-90         VSWITCH: SYSTEM VSW444
> Here "VSW444" is the name of the VSWITCH. Then you can determine the layer
> of the VSWITCH with "vmcp q vswitch <vswitch name>".
> Sample:
>     > vmcp QUERY VSWITCH VSW444
>    VSWITCH SYSTEM VSW444  Type: QDIO    Connected: 9    Maxconn: INFINITE
>   PERSISTENT  RESTRICTED    ETHERNET                  Accounting: OFF
>   ...
> The keyword here is "ETHERNET". In this case layer2 must be configured for
> the virtual NIC, otherwise layer3.

AFAIK, the CP QUERY VSWITCH is a privileged command and, thus, an
implementation should not rely on getting this information.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to debian-installer in Ubuntu.
https://bugs.launchpad.net/bugs/1541544

Title:
  ubuntu-installer makes a contradictional statement regarding
  layer2/layer3

Status in debian-installer package in Ubuntu:
  Triaged

Bug description:
  == Comment: #0 - Thorsten Diehl <thorsten.diehl at de.ibm.com> - 2016-02-03 12:05:19 ==
  When I configure a qeth OSA device, the installer asks for device type, device and protocol layer:

  Please choose the type of your primary network interface that you will need for 
   
  installing the Debian system (via NFS or HTTP). Only the listed devices are   
  supported.  
  Network device type:  
    1: ctc: Channel to Channel (CTC) or ESCON connection,      
    2: qeth: OSA-Express in QDIO mode / HiperSockets,      
    3: iucv: Inter-User Communication Vehicle - available for VM guests only,     
   
    4: virtio: KVM VirtIO,      
  Prompt: '?' for help> 2
  2  
    
  Please select the OSA-Express QDIO / HiperSockets device.  
  Device:  
    1: 0.0.f5f0-0.0.f5f1-0.0.f5f2  [*],  
  Prompt: '?' for help, default=1> 1
  1  
    
  By default OSA-Express cards use layer3 mode. In that mode LLC headers are   
  removed from incoming IPv4 packets. Using the card in layer2 mode will make it
  keep the MAC addresses of IPv4 packets.  
  Use this device in layer2 mode?  
    1: Yes [*]  2: No  
  Prompt: '?' for help, default=1> 

  The last question experienced a change according to https://bugs.launchpad.net/ubuntu/+source/s390-netdevice/+bug/1526801
  Layer2 is the default, which is correct, since the qeth driver uses layer2 as default as well.

  However, the introductional text says: "By default OSA-Express cards
  use layer3 mode."

  And this is wrong and needs to be fixed. Correct wording is:

  "By default OSA-Express cards use layer2 mode. In layer3 mode LLC headers are   
  removed from incoming IPv4 packets. Using the card in layer2 mode will make it   
  keep the MAC addresses of IPv4 packets."

  == Comment: #2 - Thorsten Diehl <thorsten.diehl at de.ibm.com> - 2016-02-03 12:08:52 ==
  Although LP 1526801 deals with this subject, it is different.
  LP 1526801 is implemented and closed. Now the documentational part in the installer needs to follow that. Thus I recommend to treat this as a separate bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1541544/+subscriptions