"Anyone who thinks they need to transmit untagged frames on a trunk port
should
discuss that with their switch admins -- you are putting your physical
switch at risk."

All kinds of things are transmitted untagged on a trunk port, such as
spanning tree frames, CDP/LLDP frames, among others. This of course is
referred to as "control plane traffic".

As an example, consider a VOIP phone. They usually have a 2 port switch
built into them. When you setup a port for a VOIP phone, you specify a data
vlan and a voice vlan. When the phone comes online, it negotiates with the
upstream switch via untagged frames (CDP and/or LLDP) to learn what VLAN to
tag the voice frames with.

Joe

On Mon, Jun 7, 2021 at 7:32 AM Alan Altmark <[email protected]> wrote:

> The guest is still connected to the VSWITCH and the virtual NIC has been
> initialized, but ithe guest is not transmitting anything on the interface.
>  The lack of any TX packets indicates that the guest doesn't know what IP
> address to assign.  On an ETHERNET mode vNIC, we would see gratuitous ARP
> packets on an "ifup".  Do you get errors when you manually bring the
> interface up?
>
> As an aside, I observe that you have the VSWITCH defined "VLAN 1 NATIVE
> 1".   I have said repeatedly, here and elsewhere, use NATIVE NONE.  Anyone
> who thinks they need to transmit untagged frames on a trunk port should
> discuss that with their switch admins -- you are putting your physical
> switch at risk.  I suspect you're not plugged into a trunk port, and by
> coding VLAN 1 NATIVE 1, you are forcing all NICs on VLAN 1 to be
> transmitted without tags.  That works because the switch port is actually
> an access port.
>
> Regards,
> Alan
> Alan Altmark
> Senior Managing z/VM Consultant
> IBM Lab Services
> Phone: 607-429-3323 | Mobile: 607-321-7556
> E-mail: [email protected]
>           Endicott, NY  USA
>
> Linux on 390 Port <[email protected]> wrote on 06/03/2021 01:22:09
> PM:
>
> > From: Victor Echavarry <[email protected]>
> > To: [email protected]
> > Date: 06/03/2021 08:08 PM
> > Subject: [EXTERNAL] [LINUX-390] Guest disconnection
> > Sent by: Linux on 390 Port <[email protected]>
> >
> > I receive a call from some server are disconnecting from the LAN.
> >
> > Checking with q vswitch shows no connection
> >
> > q vswitch vsw4 user l244p
> > VSWITCH SYSTEM VSW4       Type: QDIO    Connected: 42   Maxconn:
> INFINITE
> >   PERSISTENT  RESTRICTED    ETHERNET                  Accounting: OFF
> >   USERBASED LOCAL
> >   VLAN Aware  Default VLAN: 0001    Default Porttype: Access
> >               Native  VLAN: 0001    VLAN Counters: OFF
> >   MAC address: 02-8C-06-00-00-04    MAC Protection: Unspecified
> >   IPTimeout: 5         QueueStorage: 8
> >   Isolation Status: OFF        VEPA Status: OFF
> >  Uplink Port:
> >   State: Ready                         PriQueuing: OFF
> >   PMTUD setting: EXTERNAL   PMTUD value: 9000     Trace Pages: 8
> >   RDEV: B0E0.P00 VDEV: 0612 Controller: DTCVSW2  ACTIVE
> >         Adapter ID: 39060001FCD8.0144
> >         EQID: CORPVLAN
> >   RDEV: B0C0.P00 VDEV: 060F Controller: DTCVSW1  BACKUP
> >         Adapter ID: 39060001FCD8.01B8
> >         EQID: CORPVLAN
> >   RDEV: B1F0.P01 VDEV: 060F Controller: DTCVSW2  BACKUP
> >         Adapter ID: 39060001FCD8.0148
> >         EQID: CORPVLAN
> >  Adapter Connections:                            Connected: 42
> >     Adapter Owner: L244P    NIC: 0360.P00 Name: UNASSIGNED  Type: QDIO
> >       PQUplinkTX: Normal
> >       Porttype: Access
> >       RX Packets: 0          Discarded: 0          Errors: 0
> >       TX Packets: 0          Discarded: 0          Errors: 0
> >       RX Bytes: 0                    TX Bytes: 0
> >       Device: 0362  Unit: 002   Role: DATA       Port: 2202
> > Ready; T=0.01/0.01 13:11:16
> >
> >
> > Executing an UNCOUPLE and a COUPLE although said connected, the card
> > do nothing.
> >
> > 00:
> > 00: CP UNCOUPLE 0360
> > 00: NIC 0360 is disconnected from VSWITCH SYSTEM VSW4
> > 00:
> > 00: CP COUPLE 0360 TO SYSTEM VSW4
> > 00: NIC 0360 is connected to VSWITCH SYSTEM VSW4
> >
> > Doing a portnum remove, not successful.
> >
> > set vswitch vsw4 portnum remove 2202
> > HCPSWS2858I L244P connection to SYSTEM VSW4 has been revoked by
> MAINT720.
> > Command complete
> > Ready; T=0.01/0.01 13:14:47
> >
> > IFCONFIG shows no ETH0
> >
> > ifconfig
> > eth1      Link encap:Ethernet  HWaddr 02:78:C1:02:44:01
> >           inet addr:10.101.33.48  Bcast:10.101.39.255 Mask:255.255.248.0
> >           inet6 addr: fe80::278:c100:202:4401/64 Scope:Link
> >           UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
> >           RX packets:87836 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:605 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:1000
> >           RX bytes:7277974 (6.9 Mb)  TX bytes:133146 (130.0 Kb)
> >
> > lo        Link encap:Local Loopback
> >           inet addr:127.0.0.1  Mask:255.0.0.0
> >           inet6 addr: ::1/128 Scope:Host
> >           UP LOOPBACK RUNNING  MTU:65536  Metric:1
> >           RX packets:325 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:325 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:1000
> >           RX bytes:35386 (34.5 Kb)  TX bytes:35386 (34.5 Kb)
> >
> > If I IPL the guest the issue is solve. Does anyone has this issue
> > before, is not all servers under the same LPAR. We are running z/VM
> > 7.2 and SLES 12.
> >
> > Regards,
> >
> > Victor Echavarry Díaz
> > System Programmer
> > Operating Systems
> > t. 787.759.9999  Ext. 3401
> > [email protected]<mailto:[email protected]>
> > [cid:[email protected]]
> >
> >
> > WARNING: This email and any files transmitted with it are
> > confidential and intended solely for the use of the individual or
> > entity to whom they are addressed. If you have received this email
> > in error please delete it immediately. Please note that any views or
> > opinions presented in this email are solely those of the author and
> > do not necessarily represent those of EVERTEC, Inc. or its
> > affiliates. Finally, the integrity and security of this message
> > cannot be guaranteed on the Internet, and as such EVERTEC, Inc. and
> > its affiliates accept no liability for any damage caused by any
> > virus transmitted by this email.
> >
> > ----------------------------------------------------------------------
> > For LINUX-390 subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: INFO LINUX-390
> or
> visit
> > INVALID URI REMOVED
> >
>
> u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390&d=DwIFAw&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=XX3LPhXj6Fv4hkzdpbonTd1gcy88ea-
> > vqLQGEWWoD4M&m=hS6Vgpg2AUvIDlrK9frB3foZ_c1p5cgj0UzbR4c14Ic&s=CpVqVybb-
> > Paklxrt2MqpfHLZLNZcZZmo9VO6gK4DZgE&e=
> > [attachment "image001.png" deleted by Alan Altmark/Endicott/IBM]
>
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to