Wed, 15 Jun 2011 09:15:52 -0400

 


----------------------------

Ladies and gentlemen A question has come up on VSE-L which is more about z/VM and "TCP/IP for z/VM" rather than z/VSE and "TCP/IP for VSE". The question is as follows: When using a VSWITCH defined with the following command: DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT must all guest virtual machines be using a means to use the VSWITCH function which is "level 2" rather than "level 3" such as QDIO? It has been suggested that only the z/Linux IP-based logic can support "level 2" and hence be used with a VSWITCH defined with "ETHERNET". Having been forced to find a form of words which describes this configuration, it comes across as being an unlikely problem! This is important since only with a VSWITCH defined with "ETHERNET" can support IEEE 802.3ad "link aggregation", a point about which there can be no argument: <quote> The Ethernet mode virtual switch supports the aggregating of up to eight OSA-Express cards with a switch that supports the IEEE 802.3ad Link Aggregation specification. </quote> a href=" ---Links-Are-Forbidden--- "TCP/IP for VSE" supports QDIO which is the requirement to be able to be use the "VM-style-virtual" LAN created by the VSWITCH function. Chris Mason ---------------



----------------------------

Ladies and gentlemen A question has come up on VSE-L which is more about z/VM and "TCP/IP for z/VM" rather than z/VSE and "TCP/IP for VSE". The question is as follows: When using a VSWITCH defined with the following command: DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT must all guest virtual machines be using a means to use the VSWITCH function which is "level 2" rather than "level 3" such as QDIO? It has been suggested that only the z/Linux IP-based logic can support "level 2" and hence be used with a VSWITCH defined with "ETHERNET". Having been forced to find a form of words which describes this configuration, it comes across as being an unlikely problem! This is important since only with a VSWITCH defined with "ETHERNET" can support IEEE 802.3ad "link aggregation", a point about which there can be no argument: <quote> The Ethernet mode virtual switch supports the aggregating of up to eight OSA-Express cards with a switch that supports the IEEE 802.3ad Link Aggregation specification. </quote> a href=" ---Links-Are-Forbidden--- "TCP/IP for VSE" supports QDIO which is the requirement to be able to be use the "VM-style-virtual" LAN created by the VSWITCH function. Chris Mason ---------------







----------------------------

On Monday, 06/13/2011 at 11:34 EDT, MASON Chris <christopher.john.mason@gmail.com> wrote: > When using a VSWITCH defined with the following command: > > DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT > > must all guest virtual machines be using a means to use the VSWITCH function > which is "level 2" rather than "level 3" such as QDIO? QDIO is a data transfer architecture. The data that is transferred to an OSA via QDIO to an OSA can be in one of two formats: 1. Layer 2: The host gives the OSA fully-formed ethernet frames to be transferred as-is by the OSA. All source and destination MAC addresses are provided by the host. 2. Layer 3: The host gives the OSA an IP packet. The OSA will discover and supply the source and target MACs and other ethernet frame data. When a VSWITCH is defined as "ETHERNET", then the virtual NIC must be defined that way as well, and all guests must use the layer 2 data format. When defined as "IP" (the default), then layer 3 applies. A real OSA allows both layer 2 and layer 3 connections to the same port. z/VM VSWITCHes do not. > It has been suggested that only the z/Linux IP-based logic can support > "level 2" and hence be used with a VSWITCH defined with "ETHERNET". Incorrect. In addition to Linux, z/VM TCP/IP can speak the "layer 2" protocol. (Added in z/VM 5.4.) Hence, they can both advantage themselves of the VSWITCH's support for Link Aggregation. > a href=" ---Links-Are-Forbidden--- > > "TCP/IP for VSE" supports QDIO which is the requirement to be able to be use > the "VM-style-virtual" LAN created by the VSWITCH function. As shown above, "supporting QDIO" isn't a particularly difficult feat (also being required to use FCP adapters). Supporting Layer 2 and Layer 3 is what you want to see w.r.t. OSAs. Obviously a left-over artifact from the premier of QDIO support in z/VSE that no longer accurately reflects the "bilingual" nature of the VSWITCH. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

On Monday, 06/13/2011 at 11:34 EDT, MASON Chris <christopher.john.mason@gmail.com> wrote: > When using a VSWITCH defined with the following command: > > DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT > > must all guest virtual machines be using a means to use the VSWITCH function > which is "level 2" rather than "level 3" such as QDIO? QDIO is a data transfer architecture. The data that is transferred to an OSA via QDIO to an OSA can be in one of two formats: 1. Layer 2: The host gives the OSA fully-formed ethernet frames to be transferred as-is by the OSA. All source and destination MAC addresses are provided by the host. 2. Layer 3: The host gives the OSA an IP packet. The OSA will discover and supply the source and target MACs and other ethernet frame data. When a VSWITCH is defined as "ETHERNET", then the virtual NIC must be defined that way as well, and all guests must use the layer 2 data format. When defined as "IP" (the default), then layer 3 applies. A real OSA allows both layer 2 and layer 3 connections to the same port. z/VM VSWITCHes do not. > It has been suggested that only the z/Linux IP-based logic can support > "level 2" and hence be used with a VSWITCH defined with "ETHERNET". Incorrect. In addition to Linux, z/VM TCP/IP can speak the "layer 2" protocol. (Added in z/VM 5.4.) Hence, they can both advantage themselves of the VSWITCH's support for Link Aggregation. > a href=" ---Links-Are-Forbidden--- > > "TCP/IP for VSE" supports QDIO which is the requirement to be able to be use > the "VM-style-virtual" LAN created by the VSWITCH function. As shown above, "supporting QDIO" isn't a particularly difficult feat (also being required to use FCP adapters). Supporting Layer 2 and Layer 3 is what you want to see w.r.t. OSAs. Obviously a left-over artifact from the premier of QDIO support in z/VSE that no longer accurately reflects the "bilingual" nature of the VSWITCH. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

Alan Thank you. I was hoping you'd pick this up. Although initially being keen on using "Link Aggregation", it turns out that the customer represented by Mike Horlick, the original poster on VSE-L whom I am trying to assist, would be happy just to use the famous "gratuitous ARP" support since it is essentially non-disruptive "failover" for which they are most looking - which, apparently, their z/OS systems use. So the next question is to ask whether the up to 3 OSA feature ports which VSWITCH supports for redundancy documented as providing "failover" use the "gratuitous ARP" trick. In checking for the documentation to be sure I asked the right questions, I found I had downloaded a document other than the redpaper to which I normally refer mainly because of the excellent VLAN tutorial. This one is "z/VM VSWITCH with failover" and so is even more relevant than "VSWITCH and VLAN Features of z/VM 4.4". a href=" ---Links-Are-Forbidden--- a href=" ---Links-Are-Forbidden--- The problem is that both documents appear to claim essentially non-disruptive "failover" but without the assurance of a description of how - preferably including the word "ARP" wickedly qualified with the adjective "gratuitous"! Another encouragement is that IP is the default "mode" - rather than ETHERNET - for the DEFINE VSWITCH command and, since neither is mentioned in the sample DEFINE VSWITCH commands shown in these documents, it must be that the VSWITCH is operating in "level 3" and so the guest system operating system can be VSE using "TCP/IP for VSE" QDIO - necessarily the "level 3" flavour. I'd be grateful if you could clarify that the VSWITCH "failover" uses the "gratuitous ARP" trick - or, if not, how it works its magic - which, incidentally, I guess corresponds to the following: 21.1.3.4 Interface Takeover for Local Area Networks a href=" ---Links-Are-Forbidden--- Thank you very much. Chris Mason On Tue, Jun 14, 2011 at 12:49 AM, Alan Altmark <Alan_Altmark@us.ibm.com>wrote: > On Monday, 06/13/2011 at 11:34 EDT, MASON Chris > <christopher.john.mason@gmail.com> wrote: > > > When using a VSWITCH defined with the following command: > > > > DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT > > > > must all guest virtual machines be using a means to use the VSWITCH > function > > which is "level 2" rather than "level 3" such as QDIO? > > QDIO is a data transfer architecture. The data that is transferred to an > OSA via QDIO to an OSA can be in one of two formats: > 1. Layer 2: The host gives the OSA fully-formed ethernet frames to be > transferred as-is by the OSA. All source and destination MAC addresses > are provided by the host. > 2. Layer 3: The host gives the OSA an IP packet. The OSA will discover > and supply the source and target MACs and other ethernet frame data. > > When a VSWITCH is defined as "ETHERNET", then the virtual NIC must be > defined that way as well, and all guests must use the layer 2 data format. > When defined as "IP" (the default), then layer 3 applies. > > A real OSA allows both layer 2 and layer 3 connections to the same port. > z/VM VSWITCHes do not. > > > It has been suggested that only the z/Linux IP-based logic can support > > "level 2" and hence be used with a VSWITCH defined with "ETHERNET". > > Incorrect. In addition to Linux, z/VM TCP/IP can speak the "layer 2" > protocol. (Added in z/VM 5.4.) Hence, they can both advantage themselves > of the VSWITCH's support for Link Aggregation. > > > > a href=" ---Links-Are-Forbidden--- > > > > > "TCP/IP for VSE" supports QDIO which is the requirement to be able to be > use > > the "VM-style-virtual" LAN created by the VSWITCH function. > > As shown above, "supporting QDIO" isn't a particularly difficult feat > (also being required to use FCP adapters). Supporting Layer 2 and Layer 3 > is what you want to see w.r.t. OSAs. Obviously a left-over artifact from > the premier of QDIO support in z/VSE that no longer accurately reflects > the "bilingual" nature of the VSWITCH. > > Alan Altmark ---------------







----------------------------

Alan Thank you. I was hoping you'd pick this up. Although initially being keen on using "Link Aggregation", it turns out that the customer represented by Mike Horlick, the original poster on VSE-L whom I am trying to assist, would be happy just to use the famous "gratuitous ARP" support since it is essentially non-disruptive "failover" for which they are most looking - which, apparently, their z/OS systems use. So the next question is to ask whether the up to 3 OSA feature ports which VSWITCH supports for redundancy documented as providing "failover" use the "gratuitous ARP" trick. In checking for the documentation to be sure I asked the right questions, I found I had downloaded a document other than the redpaper to which I normally refer mainly because of the excellent VLAN tutorial. This one is "z/VM VSWITCH with failover" and so is even more relevant than "VSWITCH and VLAN Features of z/VM 4.4". a href=" ---Links-Are-Forbidden--- a href=" ---Links-Are-Forbidden--- The problem is that both documents appear to claim essentially non-disruptive "failover" but without the assurance of a description of how - preferably including the word "ARP" wickedly qualified with the adjective "gratuitous"! Another encouragement is that IP is the default "mode" - rather than ETHERNET - for the DEFINE VSWITCH command and, since neither is mentioned in the sample DEFINE VSWITCH commands shown in these documents, it must be that the VSWITCH is operating in "level 3" and so the guest system operating system can be VSE using "TCP/IP for VSE" QDIO - necessarily the "level 3" flavour. I'd be grateful if you could clarify that the VSWITCH "failover" uses the "gratuitous ARP" trick - or, if not, how it works its magic - which, incidentally, I guess corresponds to the following: 21.1.3.4 Interface Takeover for Local Area Networks a href=" ---Links-Are-Forbidden--- Thank you very much. Chris Mason On Tue, Jun 14, 2011 at 12:49 AM, Alan Altmark <Alan_Altmark@us.ibm.com>wrote: > On Monday, 06/13/2011 at 11:34 EDT, MASON Chris > <christopher.john.mason@gmail.com> wrote: > > > When using a VSWITCH defined with the following command: > > > > DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT > > > > must all guest virtual machines be using a means to use the VSWITCH > function > > which is "level 2" rather than "level 3" such as QDIO? > > QDIO is a data transfer architecture. The data that is transferred to an > OSA via QDIO to an OSA can be in one of two formats: > 1. Layer 2: The host gives the OSA fully-formed ethernet frames to be > transferred as-is by the OSA. All source and destination MAC addresses > are provided by the host. > 2. Layer 3: The host gives the OSA an IP packet. The OSA will discover > and supply the source and target MACs and other ethernet frame data. > > When a VSWITCH is defined as "ETHERNET", then the virtual NIC must be > defined that way as well, and all guests must use the layer 2 data format. > When defined as "IP" (the default), then layer 3 applies. > > A real OSA allows both layer 2 and layer 3 connections to the same port. > z/VM VSWITCHes do not. > > > It has been suggested that only the z/Linux IP-based logic can support > > "level 2" and hence be used with a VSWITCH defined with "ETHERNET". > > Incorrect. In addition to Linux, z/VM TCP/IP can speak the "layer 2" > protocol. (Added in z/VM 5.4.) Hence, they can both advantage themselves > of the VSWITCH's support for Link Aggregation. > > > > a href=" ---Links-Are-Forbidden--- > > > > > "TCP/IP for VSE" supports QDIO which is the requirement to be able to be > use > > the "VM-style-virtual" LAN created by the VSWITCH function. > > As shown above, "supporting QDIO" isn't a particularly difficult feat > (also being required to use FCP adapters). Supporting Layer 2 and Layer 3 > is what you want to see w.r.t. OSAs. Obviously a left-over artifact from > the premier of QDIO support in z/VSE that no longer accurately reflects > the "bilingual" nature of the VSWITCH. > > Alan Altmark ---------------







----------------------------

On Monday, 06/13/2011 at 08:50 EDT, MASON Chris <christopher.john.mason@gmail.com> wrote: > Although initially being keen on using "Link Aggregation", it turns out that > the customer represented by Mike Horlick, the original poster on VSE-L whom > I am trying to assist, would be happy just to use the famous "gratuitous > ARP" support since it is essentially non-disruptive "failover" for which > they are most looking - which, apparently, their z/OS systems use. z/OS is layer 3 only. The only difference between layer 2 and 3 is who does the grat ARP. The guest, when it activates its interface, or the OSA, when the host activates the interface. All hosts are required to send a grat ARP (unless specifically surpressed for a variety of Good Reasons) when an IP is activated. Not only does it update a the ARP cache in neighboring systems, it update the port filter database in the switch. > So the next question is to ask whether the up to 3 OSA feature ports which > VSWITCH supports for redundancy documented as providing "failover" use the > "gratuitous ARP" trick. In layer 3, yes, 100% of the time since the guest explicitly registers all IP addresses it wishes to receive data for and/or is the "primary router" (PRIROUTER). In layer 2, the VSWITCH will watch for and remember the grat ARP issued by a guest for "DEFINE VSWITCH ... IPTIMEOUT" minutes (default: 5). This value must be LARGER than the ARP CACHE TIMEOUT in the adjacent routers. If IPTIMEOUT is lower and a failover occurs in the interval between IPTIMEOUT and the ARP CACHE TIMEOUT, CP will not be able to re-issue the grat ARP and the switch will drop or misdirect packets until the ARP cache entry times out. (Or sometime tickles the guest - ping, ipconfig down/up - to cause outbound traffic that updates the port database.) When z/VM delivers on its Statement of Direction for an integrated clustering solution (Single System Image) and guest mobility (Live Guest Relocation), it will require the use of a layer 2 VSWITCH. > In checking for the documentation to be sure I asked the right questions, I > found I had downloaded a document other than the redpaper to which I > normally refer mainly because of the excellent VLAN tutorial. This one is > "z/VM VSWITCH with failover" and so is even more relevant than "VSWITCH and > VLAN Features of z/VM 4.4". > > a href=" ---Links-Are-Forbidden--- > > a href=" ---Links-Are-Forbidden--- > > The problem is that both documents appear to claim essentially > non-disruptive "failover" but without the assurance of a description of how > - preferably including the word "ARP" wickedly qualified with the adjective > "gratuitous"! Only Link Aggregation is actually non-disruptive in terms of not losing packets. On a "traditional" RDEV failover, packet loss is inevitable. Depending on what got lost, it may or may not make any difference to an app. > Another encouragement is that IP is the default "mode" - rather than > ETHERNET - for the DEFINE VSWITCH command and, since neither is mentioned in > the sample DEFINE VSWITCH commands shown in these documents, it must be that > the VSWITCH is operating in "level 3" and so the guest system operating > system can be VSE using "TCP/IP for VSE" QDIO - necessarily the "level 3" > flavour. IP is the default because it was developed and delivered first. (The IP keyword was added when ETHERNET was added.) It is not an endorsement of L3 vs. L2. Each has its advantages and disadvantages. > I'd be grateful if you could clarify that the VSWITCH "failover" uses the > "gratuitous ARP" trick - or, if not, how it works its magic Hopefully I've done that above. The physical switches don't really care about IP addresses; they care about which MAC addresses are plugged into which ports. They do that so that they don't have to broadcast each unicast packet to all ports, mimicking a "hub" where all ports are spliced to the same lines. A grat ARP is just a convenient way to wave your arms at the switch, saying "Here I am!" even if no one else on the LAN cares. And even the switches will forget the relationship after a while. > - which, > incidentally, I guess corresponds to the following: > > 21.1.3.4 Interface Takeover for Local Area Networks > > a href=" ---Links-Are-Forbidden--- Well, I suppose you could say that. > > Thank you very much. > > Chris Mason > On Tue, Jun 14, 2011 at 12:49 AM, Alan Altmark <Alan_Altmark@us.ibm.com>wrote: > > > On Monday, 06/13/2011 at 11:34 EDT, MASON Chris > > <christopher.john.mason@gmail.com> wrote: > > > > > When using a VSWITCH defined with the following command: > > > > > > DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT > > > > > > must all guest virtual machines be using a means to use the VSWITCH > > function > > > which is "level 2" rather than "level 3" such as QDIO? > > > > QDIO is a data transfer architecture. The data that is transferred to an > > OSA via QDIO to an OSA can be in one of two formats: > > 1. Layer 2: The host gives the OSA fully-formed ethernet frames to be > > transferred as-is by the OSA. All source and destination MAC addresses > > are provided by the host. > > 2. Layer 3: The host gives the OSA an IP packet. The OSA will discover > > and supply the source and target MACs and other ethernet frame data. > > > > When a VSWITCH is defined as "ETHERNET", then the virtual NIC must be > > defined that way as well, and all guests must use the layer 2 data format. > > When defined as "IP" (the default), then layer 3 applies. > > > > A real OSA allows both layer 2 and layer 3 connections to the same port. > > z/VM VSWITCHes do not. > > > > > It has been suggested that only the z/Linux IP-based logic can support > > > "level 2" and hence be used with a VSWITCH defined with "ETHERNET". > > > > Incorrect. In addition to Linux, z/VM TCP/IP can speak the "layer 2" > > protocol. (Added in z/VM 5.4.) Hence, they can both advantage themselves > > of the VSWITCH's support for Link Aggregation. > > > > > > > a href=" ---Links-Are-Forbidden--- > > > > > > > > "TCP/IP for VSE" supports QDIO which is the requirement to be able to be > > use > > > the "VM-style-virtual" LAN created by the VSWITCH function. > > > > As shown above, "supporting QDIO" isn't a particularly difficult feat > > (also being required to use FCP adapters). Supporting Layer 2 and Layer 3 > > is what you want to see w.r.t. OSAs. Obviously a left-over artifact from > > the premier of QDIO support in z/VSE that no longer accurately reflects > > the "bilingual" nature of the VSWITCH. > > > > Alan Altmark > ---------------







----------------------------

On Monday, 06/13/2011 at 08:50 EDT, MASON Chris <christopher.john.mason@gmail.com> wrote: > Although initially being keen on using "Link Aggregation", it turns out that > the customer represented by Mike Horlick, the original poster on VSE-L whom > I am trying to assist, would be happy just to use the famous "gratuitous > ARP" support since it is essentially non-disruptive "failover" for which > they are most looking - which, apparently, their z/OS systems use. z/OS is layer 3 only. The only difference between layer 2 and 3 is who does the grat ARP. The guest, when it activates its interface, or the OSA, when the host activates the interface. All hosts are required to send a grat ARP (unless specifically surpressed for a variety of Good Reasons) when an IP is activated. Not only does it update a the ARP cache in neighboring systems, it update the port filter database in the switch. > So the next question is to ask whether the up to 3 OSA feature ports which > VSWITCH supports for redundancy documented as providing "failover" use the > "gratuitous ARP" trick. In layer 3, yes, 100% of the time since the guest explicitly registers all IP addresses it wishes to receive data for and/or is the "primary router" (PRIROUTER). In layer 2, the VSWITCH will watch for and remember the grat ARP issued by a guest for "DEFINE VSWITCH ... IPTIMEOUT" minutes (default: 5). This value must be LARGER than the ARP CACHE TIMEOUT in the adjacent routers. If IPTIMEOUT is lower and a failover occurs in the interval between IPTIMEOUT and the ARP CACHE TIMEOUT, CP will not be able to re-issue the grat ARP and the switch will drop or misdirect packets until the ARP cache entry times out. (Or sometime tickles the guest - ping, ipconfig down/up - to cause outbound traffic that updates the port database.) When z/VM delivers on its Statement of Direction for an integrated clustering solution (Single System Image) and guest mobility (Live Guest Relocation), it will require the use of a layer 2 VSWITCH. > In checking for the documentation to be sure I asked the right questions, I > found I had downloaded a document other than the redpaper to which I > normally refer mainly because of the excellent VLAN tutorial. This one is > "z/VM VSWITCH with failover" and so is even more relevant than "VSWITCH and > VLAN Features of z/VM 4.4". > > a href=" ---Links-Are-Forbidden--- > > a href=" ---Links-Are-Forbidden--- > > The problem is that both documents appear to claim essentially > non-disruptive "failover" but without the assurance of a description of how > - preferably including the word "ARP" wickedly qualified with the adjective > "gratuitous"! Only Link Aggregation is actually non-disruptive in terms of not losing packets. On a "traditional" RDEV failover, packet loss is inevitable. Depending on what got lost, it may or may not make any difference to an app. > Another encouragement is that IP is the default "mode" - rather than > ETHERNET - for the DEFINE VSWITCH command and, since neither is mentioned in > the sample DEFINE VSWITCH commands shown in these documents, it must be that > the VSWITCH is operating in "level 3" and so the guest system operating > system can be VSE using "TCP/IP for VSE" QDIO - necessarily the "level 3" > flavour. IP is the default because it was developed and delivered first. (The IP keyword was added when ETHERNET was added.) It is not an endorsement of L3 vs. L2. Each has its advantages and disadvantages. > I'd be grateful if you could clarify that the VSWITCH "failover" uses the > "gratuitous ARP" trick - or, if not, how it works its magic Hopefully I've done that above. The physical switches don't really care about IP addresses; they care about which MAC addresses are plugged into which ports. They do that so that they don't have to broadcast each unicast packet to all ports, mimicking a "hub" where all ports are spliced to the same lines. A grat ARP is just a convenient way to wave your arms at the switch, saying "Here I am!" even if no one else on the LAN cares. And even the switches will forget the relationship after a while. > - which, > incidentally, I guess corresponds to the following: > > 21.1.3.4 Interface Takeover for Local Area Networks > > a href=" ---Links-Are-Forbidden--- Well, I suppose you could say that. > > Thank you very much. > > Chris Mason > On Tue, Jun 14, 2011 at 12:49 AM, Alan Altmark <Alan_Altmark@us.ibm.com>wrote: > > > On Monday, 06/13/2011 at 11:34 EDT, MASON Chris > > <christopher.john.mason@gmail.com> wrote: > > > > > When using a VSWITCH defined with the following command: > > > > > > DEFINE VSWITCH name RDEV rdev ETHERNET CONNECT > > > > > > must all guest virtual machines be using a means to use the VSWITCH > > function > > > which is "level 2" rather than "level 3" such as QDIO? > > > > QDIO is a data transfer architecture. The data that is transferred to an > > OSA via QDIO to an OSA can be in one of two formats: > > 1. Layer 2: The host gives the OSA fully-formed ethernet frames to be > > transferred as-is by the OSA. All source and destination MAC addresses > > are provided by the host. > > 2. Layer 3: The host gives the OSA an IP packet. The OSA will discover > > and supply the source and target MACs and other ethernet frame data. > > > > When a VSWITCH is defined as "ETHERNET", then the virtual NIC must be > > defined that way as well, and all guests must use the layer 2 data format. > > When defined as "IP" (the default), then layer 3 applies. > > > > A real OSA allows both layer 2 and layer 3 connections to the same port. > > z/VM VSWITCHes do not. > > > > > It has been suggested that only the z/Linux IP-based logic can support > > > "level 2" and hence be used with a VSWITCH defined with "ETHERNET". > > > > Incorrect. In addition to Linux, z/VM TCP/IP can speak the "layer 2" > > protocol. (Added in z/VM 5.4.) Hence, they can both advantage themselves > > of the VSWITCH's support for Link Aggregation. > > > > > > > a href=" ---Links-Are-Forbidden--- > > > > > > > > "TCP/IP for VSE" supports QDIO which is the requirement to be able to be > > use > > > the "VM-style-virtual" LAN created by the VSWITCH function. > > > > As shown above, "supporting QDIO" isn't a particularly difficult feat > > (also being required to use FCP adapters). Supporting Layer 2 and Layer 3 > > is what you want to see w.r.t. OSAs. Obviously a left-over artifact from > > the premier of QDIO support in z/VSE that no longer accurately reflects > > the "bilingual" nature of the VSWITCH. > > > > Alan Altmark > ---------------







----------------------------

On Tuesday, 06/14/2011 at 10:58 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Anyways, our network guy/specialist/architect wants us to move off of > MPROUTE/OSPF (to be 100% honest, I'm not exactly sure). I'm also in contact > with our z/OS TCP/IP expert who advised me that our z/OS clients use "ARP > Takeover" as described in Appendix H of the "OSA-Express Implementation Guide". > He asked me if we have the same under VM/VSE. This always gets confusing. There is technically no such thing as "ARP takeover". There is MAC takeover and IP takeover. z/OS issues an unsolicited ARP response broadcast (aka "gratuitous (grat) ARP") to perform IP takeover. This happens when z/OS registers its IP addresses in the OSA. z/VM TCP/IP does that, too, but it has to issue its own ARP when using layer 2. The VSWITCH uses IP takeover for a layer 3 VSWITCH and MAC takeover for layer 2. Both use grat ARP as the mechanism to notify neighboring entities. (This doesn't work when NETBIOS or SNA traffic is used on layer 2 since no ARPs are issued.) The industry is working on "port profiles" as a way to more reliably move context from one port to another, on the same switch or a different one. > I think that changing to using a VSWITCH (and before that changing from > non-QDIO mode to QDIO mode for our OSA cards) will do the trick. One of the > resources I have been looking is from the IBM z/VM website, a presentation > called "Virtual Networking with z/VM Guest LANs and the Virtual Switch by Tracy > Adams" which discusses OSA failover. > > I would like your opinion/suggestion on whether this change provides equal or > better "value" (in terms of redundancy/failover). I keep on promising to > becoming more knowledgable in TCP/IP technology. Moving from a virtual router configuration to a VSWITCH is the topic of my "Migrating to the z/VM Virtual Switch" presentation. But the more relevant concern in this case is about *why* you have MPROUTE there. When VM fails over to a DR site (say), then MPROUTE tells the routers about all the interior (to VM) subnets. With a VSWITCH, that must be handled by the exterior router(s). This has actually stopped some people from using connected VSWITCHes. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

On Tuesday, 06/14/2011 at 10:58 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Anyways, our network guy/specialist/architect wants us to move off of > MPROUTE/OSPF (to be 100% honest, I'm not exactly sure). I'm also in contact > with our z/OS TCP/IP expert who advised me that our z/OS clients use "ARP > Takeover" as described in Appendix H of the "OSA-Express Implementation Guide". > He asked me if we have the same under VM/VSE. This always gets confusing. There is technically no such thing as "ARP takeover". There is MAC takeover and IP takeover. z/OS issues an unsolicited ARP response broadcast (aka "gratuitous (grat) ARP") to perform IP takeover. This happens when z/OS registers its IP addresses in the OSA. z/VM TCP/IP does that, too, but it has to issue its own ARP when using layer 2. The VSWITCH uses IP takeover for a layer 3 VSWITCH and MAC takeover for layer 2. Both use grat ARP as the mechanism to notify neighboring entities. (This doesn't work when NETBIOS or SNA traffic is used on layer 2 since no ARPs are issued.) The industry is working on "port profiles" as a way to more reliably move context from one port to another, on the same switch or a different one. > I think that changing to using a VSWITCH (and before that changing from > non-QDIO mode to QDIO mode for our OSA cards) will do the trick. One of the > resources I have been looking is from the IBM z/VM website, a presentation > called "Virtual Networking with z/VM Guest LANs and the Virtual Switch by Tracy > Adams" which discusses OSA failover. > > I would like your opinion/suggestion on whether this change provides equal or > better "value" (in terms of redundancy/failover). I keep on promising to > becoming more knowledgable in TCP/IP technology. Moving from a virtual router configuration to a VSWITCH is the topic of my "Migrating to the z/VM Virtual Switch" presentation. But the more relevant concern in this case is about *why* you have MPROUTE there. When VM fails over to a DR site (say), then MPROUTE tells the routers about all the interior (to VM) subnets. With a VSWITCH, that must be handled by the exterior router(s). This has actually stopped some people from using connected VSWITCHes. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

Thank you, Alan.=20 BTW I have been having problems downloading your presentations at=20 a href=" ---Links-Are-Forbidden--- Connecting.... (forever) Maybe I have a wrong URL? Mike Horlick Conseiller CGI Gestion Int=E9gr=E9e des Technologies 1350 Boul. Ren=E9-L=E9vesque Ouest Montr=E9al, Qc, H3G 1T4 -----Original Message----- From: a href="mailto:IBM TCP/IP List [mailto:IBMTCP-L@VM.MARIST.EDU] On Behalf Of Alan =">IBM TCP/IP List [mailto:IBMTCP-L@VM.MARIST.EDU] On Behalf Of Alan =/a> Altmark Sent: June 14, 2011 1:14 PM To: IBMTCP-L@VM.MARIST.EDU Subject: Re: [IBMTCP-L] "Link Aggregation" support in z/VM for QDIO = Guests On Tuesday, 06/14/2011 at 10:58 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Anyways, our network guy/specialist/architect wants us to move off of > MPROUTE/OSPF (to be 100% honest, I'm not exactly sure). I'm also in contact > with our z/OS TCP/IP expert who advised me that our z/OS clients use "ARP > Takeover" as described in Appendix H of the "OSA-Express = Implementation Guide". > He asked me if we have the same under VM/VSE. This always gets confusing. There is technically no such thing as "ARP takeover". There is MAC takeover and IP takeover. z/OS issues an unsolicited ARP response broadcast (aka "gratuitous (grat) ARP") to perform IP takeover. This happens when z/OS registers its IP addresses = in the OSA. z/VM TCP/IP does that, too, but it has to issue its own ARP = when using layer 2. The VSWITCH uses IP takeover for a layer 3 VSWITCH and MAC takeover for layer 2. Both use grat ARP as the mechanism to notify neighboring entities. (This doesn't work when NETBIOS or SNA traffic is used on = layer 2 since no ARPs are issued.) The industry is working on "port profiles" as a way to more reliably move context from one port to another, on the same switch or a different one. > I think that changing to using a VSWITCH (and before that changing = from > non-QDIO mode to QDIO mode for our OSA cards) will do the trick. One = of the > resources I have been looking is from the IBM z/VM website, a presentation > called "Virtual Networking with z/VM Guest LANs and the Virtual Switch by Tracy > Adams" which discusses OSA failover. > > I would like your opinion/suggestion on whether this change provides equal or > better "value" (in terms of redundancy/failover). I keep on promising = to > becoming more knowledgable in TCP/IP technology. Moving from a virtual router configuration to a VSWITCH is the topic of = my "Migrating to the z/VM Virtual Switch" presentation. But the more relevant concern in this case is about *why* you have MPROUTE there. = When VM fails over to a DR site (say), then MPROUTE tells the routers about = all the interior (to VM) subnets. With a VSWITCH, that must be handled by = the exterior router(s). This has actually stopped some people from using connected VSWITCHes. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

Thank you, Alan.=20 BTW I have been having problems downloading your presentations at=20 a href=" ---Links-Are-Forbidden--- Connecting.... (forever) Maybe I have a wrong URL? Mike Horlick Conseiller CGI Gestion Int=E9gr=E9e des Technologies 1350 Boul. Ren=E9-L=E9vesque Ouest Montr=E9al, Qc, H3G 1T4 -----Original Message----- From: a href="mailto:IBM TCP/IP List [mailto:IBMTCP-L@VM.MARIST.EDU] On Behalf Of Alan =">IBM TCP/IP List [mailto:IBMTCP-L@VM.MARIST.EDU] On Behalf Of Alan =/a> Altmark Sent: June 14, 2011 1:14 PM To: IBMTCP-L@VM.MARIST.EDU Subject: Re: [IBMTCP-L] "Link Aggregation" support in z/VM for QDIO = Guests On Tuesday, 06/14/2011 at 10:58 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Anyways, our network guy/specialist/architect wants us to move off of > MPROUTE/OSPF (to be 100% honest, I'm not exactly sure). I'm also in contact > with our z/OS TCP/IP expert who advised me that our z/OS clients use "ARP > Takeover" as described in Appendix H of the "OSA-Express = Implementation Guide". > He asked me if we have the same under VM/VSE. This always gets confusing. There is technically no such thing as "ARP takeover". There is MAC takeover and IP takeover. z/OS issues an unsolicited ARP response broadcast (aka "gratuitous (grat) ARP") to perform IP takeover. This happens when z/OS registers its IP addresses = in the OSA. z/VM TCP/IP does that, too, but it has to issue its own ARP = when using layer 2. The VSWITCH uses IP takeover for a layer 3 VSWITCH and MAC takeover for layer 2. Both use grat ARP as the mechanism to notify neighboring entities. (This doesn't work when NETBIOS or SNA traffic is used on = layer 2 since no ARPs are issued.) The industry is working on "port profiles" as a way to more reliably move context from one port to another, on the same switch or a different one. > I think that changing to using a VSWITCH (and before that changing = from > non-QDIO mode to QDIO mode for our OSA cards) will do the trick. One = of the > resources I have been looking is from the IBM z/VM website, a presentation > called "Virtual Networking with z/VM Guest LANs and the Virtual Switch by Tracy > Adams" which discusses OSA failover. > > I would like your opinion/suggestion on whether this change provides equal or > better "value" (in terms of redundancy/failover). I keep on promising = to > becoming more knowledgable in TCP/IP technology. Moving from a virtual router configuration to a VSWITCH is the topic of = my "Migrating to the z/VM Virtual Switch" presentation. But the more relevant concern in this case is about *why* you have MPROUTE there. = When VM fails over to a DR site (say), then MPROUTE tells the routers about = all the interior (to VM) subnets. With a VSWITCH, that must be handled by = the exterior router(s). This has actually stopped some people from using connected VSWITCHes. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

On Tuesday, 06/14/2011 at 03:09 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Thank you, Alan. > > BTW I have been having problems downloading your presentations at > > a href=" ---Links-Are-Forbidden--- > > Connecting.... (forever) > > Maybe I have a wrong URL? That's the correct URL, but there have been some unexpected power outages on the raised floor where the web server lives, so that may be causing some problems. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------



----------------------------

On Tuesday, 06/14/2011 at 03:09 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Thank you, Alan. > > BTW I have been having problems downloading your presentations at > > a href=" ---Links-Are-Forbidden--- > > Connecting.... (forever) > > Maybe I have a wrong URL? That's the correct URL, but there have been some unexpected power outages on the raised floor where the web server lives, so that may be causing some problems. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------



----------------------------

Hello Alan, =20 I believe the reason why we have MPROUTE here is because at the time we = implemented TCP/IP for VM many moons ago this was the only option = available here that offered redundancy/fail-over. This decision was = taken by someone in our telecom team.=20 =20 With 2 OSA cards connected to seperate switches this seemed to be the = only choice. Am I correct in this assumption?=20 =20 As to our data recovery site, the last DRP test we did we did not use = MPROUTE and only 1 OSA card to test so I don't think that is a concern. =20 Thanks, =20 =20 Michael Horlick CGI Montreal --------------- From: a href="mailto:IBM TCP/IP List on behalf of Alan Altmark">IBM TCP/IP List on behalf of Alan Altmark/a> Sent: Tue 14/06/2011 1:13 PM To: IBMTCP-L@VM.MARIST.EDU Subject: Re: [IBMTCP-L] "Link Aggregation" support in z/VM for QDIO = Guests On Tuesday, 06/14/2011 at 10:58 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Anyways, our network guy/specialist/architect wants us to move off of > MPROUTE/OSPF (to be 100% honest, I'm not exactly sure). I'm also in contact > with our z/OS TCP/IP expert who advised me that our z/OS clients use "ARP > Takeover" as described in Appendix H of the "OSA-Express = Implementation Guide". > He asked me if we have the same under VM/VSE. This always gets confusing. There is technically no such thing as "ARP takeover". There is MAC takeover and IP takeover. z/OS issues an unsolicited ARP response broadcast (aka "gratuitous (grat) ARP") to perform IP takeover. This happens when z/OS registers its IP addresses = in the OSA. z/VM TCP/IP does that, too, but it has to issue its own ARP = when using layer 2. The VSWITCH uses IP takeover for a layer 3 VSWITCH and MAC takeover for layer 2. Both use grat ARP as the mechanism to notify neighboring entities. (This doesn't work when NETBIOS or SNA traffic is used on = layer 2 since no ARPs are issued.) The industry is working on "port profiles" as a way to more reliably move context from one port to another, on the same switch or a different one. > I think that changing to using a VSWITCH (and before that changing = from > non-QDIO mode to QDIO mode for our OSA cards) will do the trick. One = of the > resources I have been looking is from the IBM z/VM website, a presentation > called "Virtual Networking with z/VM Guest LANs and the Virtual Switch by Tracy > Adams" which discusses OSA failover. > > I would like your opinion/suggestion on whether this change provides equal or > better "value" (in terms of redundancy/failover). I keep on promising = to > becoming more knowledgable in TCP/IP technology. Moving from a virtual router configuration to a VSWITCH is the topic of = my "Migrating to the z/VM Virtual Switch" presentation. But the more relevant concern in this case is about *why* you have MPROUTE there. = When VM fails over to a DR site (say), then MPROUTE tells the routers about = all the interior (to VM) subnets. With a VSWITCH, that must be handled by = the exterior router(s). This has actually stopped some people from using connected VSWITCHes. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

Hello Alan, =20 I believe the reason why we have MPROUTE here is because at the time we = implemented TCP/IP for VM many moons ago this was the only option = available here that offered redundancy/fail-over. This decision was = taken by someone in our telecom team.=20 =20 With 2 OSA cards connected to seperate switches this seemed to be the = only choice. Am I correct in this assumption?=20 =20 As to our data recovery site, the last DRP test we did we did not use = MPROUTE and only 1 OSA card to test so I don't think that is a concern. =20 Thanks, =20 =20 Michael Horlick CGI Montreal --------------- From: a href="mailto:IBM TCP/IP List on behalf of Alan Altmark">IBM TCP/IP List on behalf of Alan Altmark/a> Sent: Tue 14/06/2011 1:13 PM To: IBMTCP-L@VM.MARIST.EDU Subject: Re: [IBMTCP-L] "Link Aggregation" support in z/VM for QDIO = Guests On Tuesday, 06/14/2011 at 10:58 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > Anyways, our network guy/specialist/architect wants us to move off of > MPROUTE/OSPF (to be 100% honest, I'm not exactly sure). I'm also in contact > with our z/OS TCP/IP expert who advised me that our z/OS clients use "ARP > Takeover" as described in Appendix H of the "OSA-Express = Implementation Guide". > He asked me if we have the same under VM/VSE. This always gets confusing. There is technically no such thing as "ARP takeover". There is MAC takeover and IP takeover. z/OS issues an unsolicited ARP response broadcast (aka "gratuitous (grat) ARP") to perform IP takeover. This happens when z/OS registers its IP addresses = in the OSA. z/VM TCP/IP does that, too, but it has to issue its own ARP = when using layer 2. The VSWITCH uses IP takeover for a layer 3 VSWITCH and MAC takeover for layer 2. Both use grat ARP as the mechanism to notify neighboring entities. (This doesn't work when NETBIOS or SNA traffic is used on = layer 2 since no ARPs are issued.) The industry is working on "port profiles" as a way to more reliably move context from one port to another, on the same switch or a different one. > I think that changing to using a VSWITCH (and before that changing = from > non-QDIO mode to QDIO mode for our OSA cards) will do the trick. One = of the > resources I have been looking is from the IBM z/VM website, a presentation > called "Virtual Networking with z/VM Guest LANs and the Virtual Switch by Tracy > Adams" which discusses OSA failover. > > I would like your opinion/suggestion on whether this change provides equal or > better "value" (in terms of redundancy/failover). I keep on promising = to > becoming more knowledgable in TCP/IP technology. Moving from a virtual router configuration to a VSWITCH is the topic of = my "Migrating to the z/VM Virtual Switch" presentation. But the more relevant concern in this case is about *why* you have MPROUTE there. = When VM fails over to a DR site (say), then MPROUTE tells the routers about = all the interior (to VM) subnets. With a VSWITCH, that must be handled by = the exterior router(s). This has actually stopped some people from using connected VSWITCHes. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------







----------------------------

On Wednesday, 06/15/2011 at 09:05 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > I believe the reason why we have MPROUTE here is because at the time we > implemented TCP/IP for VM many moons ago this was the only option available > here that offered redundancy/fail-over. This decision was taken by someone in > our telecom team. > > With 2 OSA cards connected to seperate switches this seemed to be the only > choice. Am I correct in this assumption? Separate subnets? Yes. Separate switches? Only if each switch connection goes to a separate subnet. (Switches are *trunked* together to create the appearance of a larger switch with more ports.) Within the same subnet, IP takeover can be used instead. If you don't rely on VM TCP/IP (or any other guest) as a router, then the conversion to a VSWITCH is as easy as can be. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------



----------------------------

On Wednesday, 06/15/2011 at 09:05 EDT, "Horlick, Michael" <michael.horlick@cgi.com> wrote: > I believe the reason why we have MPROUTE here is because at the time we > implemented TCP/IP for VM many moons ago this was the only option available > here that offered redundancy/fail-over. This decision was taken by someone in > our telecom team. > > With 2 OSA cards connected to seperate switches this seemed to be the only > choice. Am I correct in this assumption? Separate subnets? Yes. Separate switches? Only if each switch connection goes to a separate subnet. (Switches are *trunked* together to create the appearance of a larger switch with more ports.) Within the same subnet, IP takeover can be used instead. If you don't rely on VM TCP/IP (or any other guest) as a router, then the conversion to a VSWITCH is as easy as can be. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 Alan_Altmark@us.ibm.com IBM Endicott ---------------






S
e
n
i
o
r
T
u
b
e
.
o
r
g