I have been thinking about this and I'm sure my terminology is incorrect but my
intent is to isolate groups of hosts. Why would I use guest lan and need a
routing host whether it is zVM TCPIP or a Linux guest when with the
capabilities of VLAN and trunking I get the same result? Anyway I have once
again tried changing a SLES9 guest lan host to a SLES9 VLAN host. I am able to
get the VLAN host up and communicating thru the VLAN interface. The problem I
am encountering is every time I recucle the SLES9 zVM guest I lose the vconfig.
During start-up I receive the messages:
Initializing random number generator..done
coldplug scanning ccw: ***NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
qdio: loading QDIO base support version 2 ($Revision: 1.79.2.7 $/$Revision: 1.57
$/$Revision: 1.23.2.2 $)
qeth: loading qeth S/390 OSA-Express driver ($Revision: 1.77.2.32 $/$Revision: 1
.98.2.15 $/$Revision: 1.27.2.6 $/$Revision: 1.8.2.2 $/$Revision: 1.7.2.1 $/$Revi
sion: 1.5.2.4 $/$Revision: 1.19.2.8 $ :IPv6 :VLAN)
*..done
scanning input: ..done
. . . . . . . . . . . . . . . . . . . . . . . ..
.done
qeth: Device 0.0.0700/0.0.0701/0.0.0702 is a Guest LAN QDIO card (level: V44G)
with link type GuestLAN QDIO (portname: LNXITG2)
qeth: IP fragmentation not supported on eth0
qeth: VLAN enabled
qeth: Multicast enabled
qeth: IPV6 enabled
qeth: Broadcast enabled
qeth: Could not set up broadcast echo filtering on eth0: 0x2
qeth: Using SW checksumming on eth0.
Setting up network interfaces:
lo
lo IP address: 127.0.0.1/8
[1A..done eth0
eth0 configuration: qeth-bus-ccw-0.0.0700
[1A..doneWaiting for mandatory devices: eth0.20
14 13 12 11 10 9 8 7 6 4 3 2 1 0
eth0.20 interface could not be set up
[1A..failedSetting up service network . . . . . . . . . . . . . .
. ...failed
Starting syslog services..done
Once logged on ifconfig shows:
ifconfig
eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:2A
inet6 addr: fe80::200:0:100:2a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:652 (652.0 b)
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:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)
I then rerun vconfig add eth0 20 and receivce:
vconfig add eth0 20
WARNING: Could not open /proc/net/vlan/config. Maybe you need to load the 802
q module, or maybe you are not using PROCFS??
802.1Q VLAN Support v1.8 Ben Greear <[EMAIL PROTECTED]>
All bugs added by David S. Miller <[email protected]>
Jul 15 12:58:18 itgdbd1 kernel: 802.1Q VLAN Support v1.8 Ben Greear <[EMAIL
PROTECTED]
delatech.com>
Added VLAN with VID == 20 to IF -:eth0:-
Jul 15 12:58:18 itgdbd1 kernel: All bugs added by David S. Miller <[EMAIL
PROTECTED]
com>
Jul 15 12:58:18 itgdbd1 kernel: eth0.20: add 33:33:00:00:00:01 mcast address to
master interface
Jul 15 12:58:18 itgdbd1 kernel: eth0.20: add 33:33:ff:00:00:2a mcast address to
master interface
Jul 15 12:58:18 itgdbd1 kernel: eth0.20: add 01:00:5e:00:00:01 mcast address to
master interface
Jul 15 12:58:31 itgdbd1 kernel: eth0.20: no IPv6 routers present
I then redo the ifconfig and my vlan interface is active:
ifconfig
eth0 Link encap:Ethernet HWaddr 02:00:00:00:00:2A
inet6 addr: fe80::200:0:100:2a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:1328 (1.2 Kb)
eth0.20 Link encap:Ethernet HWaddr 02:00:00:00:00:2A
inet addr:10.1.1.171 Bcast:10.1.1.191 Mask:255.255.255.224
inet6 addr: fe80::200:0:100:2a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:460 (460.0 b)
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:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)
I do not understand why I should need to re-add the VLAN every time the system
cycles. Does anyone have any thoughts what I may be missing or what is
misconfigured? If I need to do this every time I recycle, what script is best
for automating the procedure?
Thanks,
Al Schilla
State of Minnesota
-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Alan Altmark
Sent: Wednesday, July 06, 2005 2:36 PM
To: [email protected]
Subject: Re: Converting guest lan to VLAN under SLES9
On Wednesday, 07/06/2005 at 12:56 EST, Alan Schilla
<[EMAIL PROTECTED]> wrote:
> No I think I have the terminology correct. I run multiple virtual VLANs
> accessed via redundant zVM VSWITCHs connected to redundant Cisco 3550
trunk
> ports using HSRP. Each host within a VLAN has its own VLAN interface
associated
> via eth0 with the VSWITCH virtual devices and the Cisco 3550 contains
multiple
> vlan interfaces for default gateways. This allows me to separate
production,
> test, development, whatever servers and services into their own
broadcast
> domains. At least that works with SLES8. I have had some trouble cloning
SLES9
> from a guest lan master. I hope to get back to working with the SLES9
and I
> thought I would get the list thoughts.
Your terminology *is* a bit ambiguous. IEEE VLAN technology works on both
Guest LANs and Virtual Switches. It sounds as if you are converting from
a Guest LAN to a VSWITCH. On the VSWITCH you also want to bring multiple
VLANs on board using a single physical interface (I won't talk about
using VLANs on a Guest LAN - it's not interesting and there isn't any
enforcement mechanism.)
Most hosts on a VLAN are not aware that they are on a VLAN and their
configurations do not include any notion of VLANs. These kinds of hosts
connect to ACCESS ports on the switch.
The rare host on a VLAN that *is* aware of the VLAN is acting as a VLAN
router (just like the router inside the switch) or wants to provide
services to multiple VLANs using a single physical interface. These kinds
of hosts connect to TRUNK ports on the switch and their IP configurations
include VLAN ID specifications. (BTW, this is also how switches talk to
one another.) Where possible, let the physical switch do all the routing.
If you need access to a single VLAN, then the VSWITCH can be
"VLAN-unaware" and MUST be plugged into an ACCESS port on the switch. No
VLAN specification is used; allow DEFINE VSWITCH to use its defaults -
don't specify the VLAN keyword. All guests that connect to such a VSWITCH
are also VLAN-unaware and all are in the same LAN segment. The VSWITCH
acts as a "hub" and does not enforce any VLAN associations.
If you need access to multiple VLANs, then the VSWITCH must operate
"VLAN-aware" and MUST be plugged into a TRUNK port on the switch. The
VSWITCH becomes VLAN-aware when it is configured with a default VLAN ID
(Alan's suggestion: VLAN 1). In this mode, guests can either remain
VLAN-unaware on virtual access ports, or be VLAN-aware using virtual trunk
ports and an IP configuration that includes VLAN ID specifications. CP
will enforce the VLAN authorizations.
When converting from Guest LAN to VSWITCH, the suggested configuration is
to leave the guests VLAN-unaware and simply make the router's IP address
in the switch the same as the IP address of your [former] virtual router.
No fuss, no muss.
Alan Altmark
z/VM Development
IBM Endicott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.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://www.marist.edu/htbin/wlvindex?LINUX-390
