Changing OSA Mac Address
Fernando Ochoa
We have a z890 with Osa-Express 1000BaseT feature. Channel B4 is configured in OSE mode (SNA+TCPIP) and channel B5 as OSC (Console). We have a CIP router (7513) with 2 ESCON channels too. We have VIPA (OSA/CIP devices and OMPROUTE/RIP). For SNA we have a SNI connection between our CIP connection and corporative FEPs using DLSW.
Last weekend we tried to change the OSA MAC address, the objetive is to have the same MAC address than CIP and which is defined in the remote NCP line definition. We used the HMC OSA Support Facilities, we inactivated/activated OSA devices, paths and channels in all LPARs (2), after that we had the following scenario:
--> TCPIP commands “netstat dev” and “netstat arp all” show new MAC address
--> Borders routers (Cisco 7513 and Cisco 4500) have new ARP assignments for OSA physical and virtual devices.
--> RIP is working OK, default route is passed from routers to TCPIP stack and VIPA addresses are passed for host to routers.
--> But it is not possible to ping/connect to physical/virtual host interfaces from network (from border routers) and from host to network.
We accesed to OSA/SF facility using CIP connection and could see that Locally Administered Address was correct. But it didn't work and came back the change.
Is it necessary to do some more thing? Is it necessary IPL, Power On Reset, ..., update OAT entries, ...
Thanks a lot, fernando.
Fernando Ochoa de Zuazola
email: fernand...@t-systems.es
---------------------------------
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO IBMTCP-L
Fernando Ochoa
"What I can see is that you want to make your CIP Virtual TR LAN adapter MAC address redoundance with your OSA TR adapter MAC address. Are you talking TR adapters or you are runing the CIP with special microcode supporting transparent bridging and Virtual LANs supporting ethernet adapters?"
Fernando says:
"CIP MAC address is configured as Virtual TR adapter, so it's using SRB to connect to DLSW. And OSA adapter is ethernet, so I put the same MAC address but doing bitswapping and use bridging to connect to DLSW"
Sergio Paez said:
"Since, you change only your OSA MAC address, then your IP routing should not be affected at all. You should be able to ping your mainframe host VIPA or physical adpater IP address from your border routers and viceversa, Answering your question: IPL, POS or update OAT entries (by the way, OAT updates are automatically on OSA/E ) do not fix your routing issues.
nothing to do with that, Honestly, I don't understand your ping problem. it sound very serious issue"
Fernando says:
"Yes, it seams not easy issue. May be a problem with virtual IP (VIPA), I have SOURCEVIPA coded. Actually I could not check if physical IPs work OK, when you ping to physical IP the answer comes from VIPA address, so I should clean SOURCEVIPA and try again."
Sergio Paez said:
"Any special reason that keep you runing RIP on your host? you should look into get rid of it asap?"
Fernando says:
"Sorry, I don't understand what do you mean.
Regards, Fernando.
Chris Mason
This is all very confused. When I saw you blaming VIPA for a problem which
has nothing to do with VIPA I decided a bit of clarity was called for.
Let me see if I can shed light on what you have and what you are trying to
do. It's important when asking for help to limit your descriptions to what
is relevant.
I'll use something similar to Sergio's diagram to see if my understanding is
correct - as always, please ensure the diagrams are viewed with a
nonproportional font.
SNA configuration
Remote Local
VTAM-NCP-TR-CIP-VTAM
or
VTAM-NCP-TR-OSA-VTAM
Bridged TR configuration
Remote Local
NCP-segment1-DLSw router-segment2-DLSw router-segment3-CIP
or
NCP-segment1-DLSw router-segment2-DLSw router-segment4-OSA
IP enters these pictures only by providing, through the "magic" of DLSw,
token ring segment 2 in the diagrams above.
I'm afraid I'm not familiar with all the "tricks" of which the CIP is
capable but I suspect that it combines all of "DLSw router-segment3-CIP"
under its covers. Nevertheless, it is important to have a clear view of the
configurations upon which the different protocols work. If I'm wrong on how
the CIP fits into the two pictures, someone please jump in and correct me.
So as Sergio just about informed us, it would appear your objective is to
provide redundancy so that either the OSA or the CIP can respond to a TEST
frame which is used to set up the 802.2 connection over the logical SNI link
and which specifies your single MAC address.[1]
[1] I was going to say "it would appear your objective is to "load balance"
by having 802.2 connections be accepted by the CIP or the OSA according to
how quickly they can respond to the TEST frames used to initiate
connections" but then I realised this makes sense only when there are many
connections involved such as would be coming from a large number of end
users. This doesn't apply with a single SNA subarea connection.
What I have described is SNA and it should work fine. However, as far as I
know it just isn't supported for IP. You'll note that I mention the 802.2
protocol operating over the token ring configuration. Specifically it is the
connection-oriented flavour of 802.2 and it is happy to operate with
duplicate MAC addresses.
The ARP protocol of IP expects a node responding to an ARP to be unique on
the LAN so that it can happily route over the LAN based purely on the MAC
address and not rely also on the segment routing capability of the "routing
information field" (RIF) which is worked out during the establishment of the
SNA connection.
This may not be the whole story. I am not "trained" in Cisco "tricks" but I
believe I have heard of a Cisco "trick" which, in some way, permits this
sort of redundancy. The only problem is that I'm pretty sure it would
require that only Cisco boxes were involved and you have been rash enough
(<g>) to employ a true blue OSA feature.
I'm not clear whether or not your SNA subarea connection still works. Any IP
PINGing which involves use of the interface with the changed MAC address is
irrelevant.
If your SNA connection is not working, you should be using a tool my
colleagues used to work with the name of which I have forgotten - in any
case, the version I used ran from OS/2. This tool performed as a MAC PING in
that it used 802.2 TEST frames rather than ICMP Echo packets. It was very
useful for DLSw as I appreciated when trying to make IBM 6611s work - if
anyone remembers the boxes that IBM offered in order to take Cisco on! You
connected a PC on one LAN and made sure you could "see" adapters or whatever
on the LAN remote over the DLSw routers - and the DLSw routers themselves -
using the adapter's supposed MAC address.
Since you are having to worry about canonical and noncanonical MAC
addresses, it would be as well to have something which quickly verified that
the transformation was behaving as it should.
-
Incidentally, when Sergio suggested getting rid of RIP what he almost
certainly had in mind is that you should plan on converting to OSPF since it
is generally recognised that OSPF is a far superior dynamic routing
protocol. This is as much a "political" as a "technical" issue and, in any
case, is a matter for your "router people" rather than you I expect.
Chris Mason
----------------------------------------------------------------------
Fernando Ochoa
OK, I’ll try to explain the problem better.
1.- Actual state (TCPIP and SNA working OK).
TCPIP: VIPA with 2 devices, 1 CIP connection and 1 OSA-Express 1000BaseT feature configured as OSE (non-QDIO mode). OMPROUTE with RIP, OSA is configured as primary (input/output). The same for 2 LPARs, it’s necessary to define OAT entries for physical and virtual IPs.
SNA: only a production subarea connection using CIP device. DLC connections (802.2 protocol, DIAL=YES) not used, but successfully checked for CIP or OSA devices on 2 LPARs (OAT for SNA is necessary too).
SubArea connection diagram:
HOST1<–->CIP ESCON (virtual TR)<–->DLSW (SRB)<–->IP<–->DLSW (SRB)<–->FEP (TR)<–->HOST2
2.- Future State
Objetive: to pass all the traffic to OSA device. There are several SNA routers, but only a CIP connection.
Plan: change the OSA MAC address to CIP MAC Address. OSA is ethernet, and CIP is TR, so CIP MAC address is bitswapped following the scheme:
40 06 31 F4 81 69
0100 0000 0000 0110 0011 0001 1111 0100 1000 0001 0110 1001
0000 0010 0110 0000 1000 1100 0010 1111 1000 0001 1001 0110
02 60 8C 2F 81 96
New MAC address meets OSA Ethernet conditions in SYS1.SIOASAMP(IOAFENET)
Future SubArea connection scheme:
HOST1<–->OSA FE (Bridging)<–->DLSW (Bridging)<–->IP<–->DLSW (SRB)<–->FEP (TR)<–->HOST2
It’s necessary to bitswap the remote (NCP) MAC address in the local XCA node too.
3.- Test
CIP XCA node Inactivation.
Change OSA MAC address using HMC OSA Support Facilities.
OSA channel/paths/devices reactivation on 2 LPARs.
TCPIP restarted: OSA devices ready.
TCPIP doesn’t answer from network until CIP device is configured as primary.
ARP updating OK in routers and TCPIP stacks.
SNA connections is not checked because TCPIP doesn’t work for OSE device.
Change is backed.
4.- My problem
TCPIP doesn’t work fine using OSA (passthtu mode, non-QDIO) devices after changing MAC address. This wasn't the objetive of test, but it was caused by test. When we put the original MAC TCPIP worked OK.
Regards, fernando.
---------------------------------
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
----------------------------------------------------------------------
Chris Mason
Thanks for confirming that I understood what you are trying to do. I believe
your description of your current and future configurations is essentially
what I described in my previous post.
As I said in my previous post, IP will work when CIP operates with one MAC
address and OSA operates with another MAC address but IP will *not* work -
or may work erratically - if the same MAC address is used.
I suggest that you abandon using both types of adapter for IP and use the
duplicate MAC configuration only for SNA. It may be useful if you verify
that SNA works next time you run a test and ignore the IP failure in the
meantime.
It took me a while to appreciate that the problem you are reporting is that
you cannot get the OSA to work with the changed MAC address even when the
CIP is disabled - or is it? I'm afraid I don't know to what you are
referring when you use the word "primary". Please explain. Note that
configuration of an IP node can affect only "output" so I'm always a bit
worried when I see a reference to configuring which is supposed to affect
both "input" and "output" as in
> OSA is configured as primary (input/output)
and
> CIP device is configured as primary
As far as trying to operate with this duplicate MAC address is concerned,
please think about what happens to the "Address Resolution Protocol" (ARP)
when it is faced with 2 interfaces with 2 different IP addresses which
respond with the same MAC address. You'll be giving the ARP logic in the
router adjacent over the LAN "un ataque de nervios" - thanks to IMDB for the
translation from the title of Pedro Almodóvar's famous film. <g>
Incidentally, I believe the OSA FE will not be obliged to perform any
"bridging" since it is an end-point as far as the DLSw-simulated
concatenation of token ring segments is concerned.
Chris Mason
----- Original Message -----
From: "Fernando Ochoa" <yfzu...@yahoo.es>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Tuesday, 26 September, 2006 4:51 PM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
> Hello Chris, hello all,
> OK, I'll try to explain the problem better.
> 1.- Actual state (TCPIP and SNA working OK).
> TCPIP: VIPA with 2 devices, 1 CIP connection and 1 OSA-Express 1000BaseT
feature configured as OSE (non-QDIO mode). OMPROUTE with RIP, OSA is
configured as primary (input/output). The same for 2 LPARs, it's necessary
to define OAT entries for physical and virtual IPs.
> SNA: only a production subarea connection using CIP device. DLC
connections (802.2 protocol, DIAL=YES) not used, but successfully checked
for CIP or OSA devices on 2 LPARs (OAT for SNA is necessary too).
> SubArea connection diagram:
> HOST1<-->CIP ESCON (virtual TR)<-->DLSW (SRB)<-->IP<-->DLSW
(SRB)<-->FEP (TR)<-->HOST2
> 2.- Future State
> Objetive: to pass all the traffic to OSA device. There are several SNA
routers, but only a CIP connection.
> Plan: change the OSA MAC address to CIP MAC Address. OSA is ethernet, and
CIP is TR, so CIP MAC address is bitswapped following the scheme:
> 40 06 31 F4 81 69
> 0100 0000 0000 0110 0011 0001 1111 0100 1000 0001 0110 1001
> 0000 0010 0110 0000 1000 1100 0010 1111 1000 0001 1001 0110
> 02 60 8C 2F 81 96
> New MAC address meets OSA Ethernet conditions in
SYS1.SIOASAMP(IOAFENET)
> Future SubArea connection scheme:
> HOST1<-->OSA FE (Bridging)<-->DLSW (Bridging)<-->IP<-->DLSW
(SRB)<-->FEP (TR)<-->HOST2
> It's necessary to bitswap the remote (NCP) MAC address in the local
XCA node too.
> 3.- Test
> CIP XCA node Inactivation.
> Change OSA MAC address using HMC OSA Support Facilities.
> OSA channel/paths/devices reactivation on 2 LPARs.
> TCPIP restarted: OSA devices ready.
> TCPIP doesn't answer from network until CIP device is configured as
primary.
> ARP updating OK in routers and TCPIP stacks.
> SNA connections is not checked because TCPIP doesn't work for OSE device.
> Change is backed.
> 4.- My problem
> TCPIP doesn't work fine using OSA (passthtu mode, non-QDIO) devices after
changing MAC address. This wasn't the objetive of test, but it was caused by
test. When we put the original MAC TCPIP worked OK.
> Regards, fernando.
----------------------------------------------------------------------
Chris Mason
Fortunately many years ago when I last worked with OSA/SF (for use with an
OSA-2 feature), I created three documents explaining (1) how to install (2)
how to prepare a typical configuration and (3) how to manage the OSA using
OSA/SF. Now reading the documents through I note that there is an "Activate"
step at the end of document 2. I didn't note anything about configuring
through the HMC but I expect that affects the configuration stored in the
OSA feature immediately - or after appropriate "resets". On the other hand
if the MAC address is specified in a configuration you have to know you are
setting it - along with all the other specifications in the configuration -
because you have to go through this "Activate" step.
Here's the relevant "Note" from my document:
<quote>
Note: "Activate" involves (a) preparing MVS data sets for the loading
process and (b) transferring a configuration and any supporting programming
to the OSA. Step b is disruptive to any existing activity over unit
addresses associated with the OSA which are currently allocated. "Activate
(no install)" performs step a but avoids step b.
</quote>
Fortunately also I discovered I had documented the "appropriate 'resets'" at
the end of document 3 as follows:
<quote>
Enabling a New OSA Configuration
--------------------------------
Note: Enabling a configuration is necessary only for those OSA types which
require that a configuration is constructed, for example OSA-ENTR. Enabling
the configuration created in the separate document covering configuration of
an OSA-ENTR is assumed in these notes.
Once a configuration has been created, saved, prepared and loaded into the
OSA, the OSA must be configured offline on all LPARs to which it is defined.
Then the OSA must be configured online. When the OSA is configured online to
the first LPAR, the new configuration becomes the current configuration.
Configuring the OSA online on subsequent LPARs has no special significance.
The required MVS console commands, using the addresses from the example
configuration and an address of 200 has been assigned to the OSA (and also
assuming a similar configuration is already active), are as follows:
On the MVS in LPAR 3
VARY 200-201,OFFLINE
VARY 20A-20C,OFFLINE
VARY 2FE,OFFLINE
CF CHP(B4),OFF
On the MVS in LPAR 4
VARY 200-201,OFFLINE
VARY 20A-20B,OFFLINE
VARY 2FE,OFFLINE
CF CHP(B4),OFF
On the MVS in LPAR 3
CF CHP(B4),ON
At this time the OSA enables the new configuration. The process involves
some internal test procedures and may take a few minutes.
When the new configuration is enabled, the relevant addresses are brought
"online".
On the MVS in LPAR 4
CF CHP(B4),ON
Before the command sequence above can be followed, it may be necessary to
ensure that the addresses to be varied offline are no longer allocated.
If the addresses are allocated to a CS/390 IP interface, a command similar
to the following can be used to ensure that the address is no longer
allocated:
VARY TCPIP,,STOP,OSAT1P0
where OSAT1P0 is the name of the DEVICE statement which defines the IP
interface to CS/390 IP.
If the addresses are allocated to CS/390 SNA because of an active VTAM XCA
major node, a command similar to the following can be used to ensure that
the address is no longer allocated:
VARY NET,INACT,ID=OSAT1P0
where OSAT1P0 is the name of the VTAM XCA major node.
</quote>
Chris Mason
----- Original Message -----
From: "Alan Watthey" <awat...@mmm.com>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Tuesday, 26 September, 2006 5:10 PM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
> Fernando,
>
> After having changed the MAC address you did config the chpid off on ALL
> LPARs of the CPU and then config it back on again. I notice that you
> mention non-QDIO so this means using an OAT which contains the MAC
address.
>
> In fact, when I used non-QDIO (many years ago) I always used the OAT plus
> OSA/SF to set the MAC address. It's only now I have QDIO mode that I use
> the HMC to do it as it is completely dynamic with QDIO. One doesn't even
> need to stop the device in TCPIP.
>
> You may of course be using the default OAT so I'm not a hundred percent
> sure when it regenerates that but it might be worth trying the CF trick in
> any case.
>
> Regards,
> Alan
Fernando Ochoa
First, I would like to thank you very much your support.
About thread, some more comments:
1.- About VIPA primary/secondary interfaces.
In the OMPROUTE configuration file you can code the parameters In_Metric and Out_Metric that specify the weight used to publish the routes. That means that Out_metric defines which is the prefered input interface (it depends on the route that borders have with lowest weight) and In_Metric defines the output interface (it depends on default route that TCPIP stack has with lowest weight). So with these parameters you define the selected interfaces for input/output, you could do load balancing too.
The border router is selected in function of router RIP process configuration (offset-list 1 out 5, for example). That defines the weight added when routes are publised to host.
2.- OSA/SF
Yes, in the next test I will change MAC using OSA/SF, with following steps:
a) Change OMPROUTE weight to do that CIP is primary interface.
b) Inact OSA XCA nodes in 2 LPARs
c) Stop OSA TCPIP devices in 2 LPARs
d) Access to OSA/SF using IOAJAVA. Change MAC address to Localy Administered Address. Activate.
e) VARY OFFLINE SNA/TCPIP devices on 2 LPARs. VARY OFFLINE OSA Channel on 2 LPARs.
f) VARY ONLINE OSA Channel on 2 LPARs. VARY ONLINE SNA/TCPIP devices on 2 LPARs.
g) START OSA TCPIP devices and check TCPIP.
h) Activate XCA nodes and check Subarea connection.
3.- ARP
We have a CIP card with two ESCON interfaces, but only one of them is connected to z890. So int channel 4/0 is disabled. Physical interface 4/1 has TCPIP CLAW configuration and CSNA configuration. Something like that:
interface Channel4/1
ip address 53.254.21.34 255.255.255.248
claw 0111 0A 53.254.21.33 HOSTA C7500 TCPIP TCPIP BROADCAST
csna 0111 02
csna 0111 04
…
The physical interface is a point-to-point interface. I never have seen a MAC for this interface, the 7513 router has no ARP entry for this IP address. Actually, it’s not possible to ping from router to host CIP IP address, it’s a known documented (cisco) limitation.
The virtual 4/2 interface has the config:
interface Channel4/2
no ip address
max-llc2-sessions 2048
lan TokenRing 0
source-bridge 200 1 250
adapter 2 4006.31f4.81a9
lan TokenRing 7
source-bridge 300 14 350
adapter 10 4006.31f4.8169
…
So, I think the MACs defined in this interface are used only by SNA with XCA nodes. I never have seen ARP entries in the borders routers for theese MACs, nor in the TCPIP stack.
Now I have ARP entries in TCP stack for borders routers and for OSA interfaces (VIPA has the same MAC too). But I don’t have entries for CIP connection. In border routers I only can see the ARP for OSA interfaces, the same MAC for two LPARs Ips (no ARP for VIPA, it’s logic, it is not directly connected).
In the command “netstat dev” I can see the MAC address for OSA devices, not for CIP device.
So I think It should be possible to have the same MAC configured in CIP and OSA devices.
Regards, fernando.
Fernando Ochoa de Zuazola
mail: fernand...@t-systems.es
Vitoria-Gasteiz - Spain
---------------------------------
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
----------------------------------------------------------------------
Bill Hecox
I think you should be ok with a duplicate virtual mac address on the CIP.
It can only be accessed with Source Route Bridging and as long as it is not
visable to the IP network.
So that leaves the question as to why you are having a problem. A packet
trace will usually
lead to the cause of the problem.
You can run an IBM TCPIP packet trace with componet trace. You may also want
to
run a Sniffer type trace on the Network side of the OSA device. Ethereal is
available
for download from the internet and produces comprehensive ip trace
formatting.
There are examples of creating IBM TCPIP packet traces in Redbook SG24-5613
Appendix A.
If it works with the OAT interface set to primary then you probably have an
OAT configuration problem.
Bill
----- Original Message -----
From: "Fernando Ochoa" <yfzu...@yahoo.es>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Wednesday, September 27, 2006 7:04 AM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
Alan, Chris,
.
The physical interface is a point-to-point interface. I never have seen a
MAC for this interface, the 7513 router has no ARP entry for this IP
address. Actually, it's not possible to ping from router to host CIP IP
address, it's a known documented (cisco) limitation.
The virtual 4/2 interface has the config:
interface Channel4/2
no ip address
max-llc2-sessions 2048
lan TokenRing 0
source-bridge 200 1 250
adapter 2 4006.31f4.81a9
lan TokenRing 7
source-bridge 300 14 350
adapter 10 4006.31f4.8169
.
Bill Hecox
I reviewed your configuration again.
If you change the mac address on the OSA you need to update the ARP table in
the default router/switch.
This can be done by doing a clear arp in the router/switch. Then the
router/switch will reissue the arp to learn the new mac. You could also try
performing an outgoing ping to the default route from the stack. That might
create a new
arp from the stack which should update the router/switch arp table.
It is probably not a good idea to have both an OSA connection and a CIP
connection in the same
stack to the same router. Everytime I hear of someone trying this they have
connectivity problems.
If you want redundency use a balanced configuration. Two CIPs or two OSAs.
Bill
----- Original Message -----
From: "Fernando Ochoa" <yfzu...@yahoo.es>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Tuesday, September 26, 2006 10:51 AM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
Hello Chris, hello all,
OK, I'll try to explain the problem better.
1.- Actual state (TCPIP and SNA working OK).
TCPIP: VIPA with 2 devices, 1 CIP connection and 1 OSA-Express 1000BaseT
feature configured as OSE (non-QDIO mode). OMPROUTE with RIP, OSA is
configured as primary (input/output). The same for 2 LPARs, it's necessary
to define OAT entries for physical and virtual IPs.
SNA: only a production subarea connection using CIP device. DLC
connections (802.2 protocol, DIAL=YES) not used, but successfully checked
for CIP or OSA devices on 2 LPARs (OAT for SNA is necessary too).
SubArea connection diagram:
HOST1<-->CIP ESCON (virtual TR)<-->DLSW (SRB)<-->IP<-->DLSW
(SRB)<-->FEP (TR)<-->HOST2
2.- Future State
Objetive: to pass all the traffic to OSA device. There are several SNA
routers, but only a CIP connection.
Plan: change the OSA MAC address to CIP MAC Address. OSA is ethernet, and
CIP is TR, so CIP MAC address is bitswapped following the scheme:
40 06 31 F4 81 69
0100 0000 0000 0110 0011 0001 1111 0100 1000 0001 0110 1001
0000 0010 0110 0000 1000 1100 0010 1111 1000 0001 1001 0110
02 60 8C 2F 81 96
New MAC address meets OSA Ethernet conditions in
SYS1.SIOASAMP(IOAFENET)
Future SubArea connection scheme:
HOST1<-->OSA FE (Bridging)<-->DLSW (Bridging)<-->IP<-->DLSW
(SRB)<-->FEP (TR)<-->HOST2
Chris Mason
Comments are embedded.
Chris Mason
----- Original Message -----
From: "Bill Hecox" <Bill....@mail.com>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Thursday, 28 September, 2006 3:21 AM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
> Fernando,
>
> I reviewed your configuration again.
>
> If you change the mac address on the OSA you need to update the ARP table
in
> the default router/switch.
As I understand Fernando's last post, he is happy that the changed MAC
address for the OSA port is appearing in the ARP table as he expected.
> ...
>
> It is probably not a good idea to have both an OSA connection and a CIP
> connection in the same
> stack to the same router. Everytime I hear of someone trying this they
have
> connectivity problems.
Also again according to Fernando's second post in this thread, his OSA/CIP
configuration works to his satisfaction - as long as he doesn't try this
duplicate MAC reconfiguration.
> If you want redundancy use a balanced configuration. Two CIPs or two OSAs.
With the usual proviso, Fernando appears to be trying for a smooth migration
from CIP to OSA rather than long-term coexistence for the purposes of
availability.
> Bill
Chris Mason
Comments are embedded.
Chris Mason
----- Original Message -----
From: "Bill Hecox" <Bill....@mail.com>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Wednesday, 27 September, 2006 6:58 PM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
> Fernando,
>
> I think you should be ok with a duplicate virtual mac address on the CIP.
Fernando has taken the MAC address used in the NCP definition for the SNA
link to the CIP and tried to specify it as the OSA port LAA. The MAC address
is duplicated on the OSA feature.
> It can only be accessed with Source Route Bridging and as long as it is
not
> visible to the IP network.
As I understand it Fernando is using IP with the CIP - see his second post
in the thread - so the CIP must in some way be visible to IP.
> So that leaves the question as to why you are having a problem. ...
> ...
> If it works with the OAT interface set to primary then you probably have
an
> OAT configuration problem.
I think I have got to the bottom of what Fernando means by "primary" - and
"secondary" - and it is *not* the OSA option for routing unidentified IP
packets - which is what I think you have in mind.
> Bill
Chris Mason
1.
I'm afraid you are tending to assume that everyone can understand your
abbreviated way of describing your configuration as perhaps only you and
your colleagues talk about it. When "primary" and "secondary" are talked of
and OSA features are involved, this usually refers to how shared OSA
adapters are configured to their various LPARs and hence supporting CS IP
instances. You seem to be using "primary" and "secondary" in connection with
your dynamic routing protocol and how you use this to influence which
interface is used, the "primary", and which is not used, "the secondary",
unless the "primary" fails.
I suspect I for one will not be able to "get my head round" your
configuration - and the way you control your routes - without seeing the
relevant DEVICE, LINK and HOME statements and the relevant RIP_Interface
statements in your OMPROUTE file.
I'm familiar with "border router" only with OSPF, not RIP. I was not aware
that RIP had any special designations for types of router. Is this perhaps
an OSPF border router which can accept RIP route advertisements and
generates RIP route advertisements? In any case, I expect all we need to
know is that there is a router adjacent to the OSA and CIP interfaces which
cooperates with them using RIP route advertisements.
2.
For access to OSA/SF GUI I have used only APPC/MVS, TCP/IP and TSO 3270
IND$FILE. IOAJAVA is new to me but I guess it's another logical alternative,
namely JAVA in a browser.
The sequence you describe for changing the configuration seems to correspond
to the one I gave in an earlier post.
Note, this time, at least for assurance that all is as it should be with
SNA, you should go on to step "h" even if step"g" is not entirely
successful.
3.
Note that I'm not familiar with the Cisco machine at all so I'm afraid your
definitions don't help me - although they might help others who work with
CIP machines. I have been trying to deal with your problem using an
understanding of the protocols involved.
As I said above, I'm assuming that what you call your "border router" is the
router adjacent over the LAN from the OSA and CIP interfaces.
However I'm now having a lot of difficulty understanding just exactly what
the CIP machines does - although I guess it still somehow corresponds to the
DLSw diagram. If we are to have an equivalent IP configuration with the OSA
feature, I would expect to be able to "see" ARP entries for the CIP in the
adjacent router.
I assume by "Now I have ARP entries in TCP stack for borders routers" you
mean that the CS IP ARP table shows the MAC and IP address of this adjacent
router. This is as it should be.
It's interesting that you also see the ARP entry for the OSA feature MAC and
IP address. I'm afraid I don't have my own systems to experiment with so I
can't say whether or not this is as it should be. The examples in the "z/OS
Communications Server IP System Administrator's Commands" manual are not
helpful.
There's a point of general design arising here. In my experience with
installing OSA features and in having VIPAs defined in the same CS IP, I
have adopted a design - because it seemed the only sensible way to do it -
which required that the OSA port had one IP address for each associated CS
IP instance. Any VIPAs were selected from an address range, a subnet address
range, separate from that of the subnet corresponding to the LAN to which
the OSA features attach.
It seems you have defined your VIPAs to belong to the same subnet as the LAN
to which the OSA features attach. Thus the VIPA has an ARP entry. Have I
misunderstood something terribly here? On the other hand maybe you don't
have the VIPA in the same subnet as the IP address for the OSA interface and
that explains why there is no ARP entry for the VIPA in the adjacent router.
Thus the ARP entry in CS IP for the VIPA is a "red herring".[1]
[1] Meaning a misleading irrelevancy. I'm sorry I don't know the equivalent
expression in Spanish.
Since we cannot establish equivalent configurations for the CIP and OSA I'm
rather doubtful about your attempt to use the same MAC address.
I would actually like to hear that SNA and IP work with the CIP when the OSA
is not active and that SNA and IP work with the OSA when the CIP is not
active. In other words your problem is definitely trying to run both the OSA
and CIP together.
---
Since your objective is to migrate the SNA traffic from using the CIP to
using the OSA and to be able to use either of the connections in the
meantime, let us try an approach other than having to have a duplicate MAC
address.
What you should do is create another logical link between the NCP and the
OSA port using the MAC address it has now. Since the NCP contains the
subarea network boundary, the ER and VR will originate in that node and,
depending on how many SNA subarea nodes belong to this subarea network,
creation of the additional PATH statements may be quite simple. Perhaps the
only subarea nodes are 2 VTAMs running in your 2 LPARs. That's it - and no
complications from duplicate MAC addresses.
Please post again if this is not clear for you. I've got a suspicion that
the person in your organisation who - I guess - last changed your subarea
definitions was whoever converted from a 3745 to the CIP and that he/she has
been "let go" since.
Chris Mason
----- Original Message -----
From: "Fernando Ochoa" <yfzu...@yahoo.es>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Wednesday, 27 September, 2006 1:04 PM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
> .
> The physical interface is a point-to-point interface. I never have seen a
MAC for this interface, the 7513 router has no ARP entry for this IP
address. Actually, it's not possible to ping from router to host CIP IP
address, it's a known documented (cisco) limitation.
>
> The virtual 4/2 interface has the config:
> interface Channel4/2
> no ip address
> max-llc2-sessions 2048
> lan TokenRing 0
> source-bridge 200 1 250
> adapter 2 4006.31f4.81a9
> lan TokenRing 7
> source-bridge 300 14 350
> adapter 10 4006.31f4.8169
> .
> So, I think the MACs defined in this interface are used only by SNA with
XCA nodes. I never have seen ARP entries in the borders routers for theese
MACs, nor in the TCPIP stack.
> Now I have ARP entries in TCP stack for borders routers and for OSA
interfaces (VIPA has the same MAC too). But I don't have entries for CIP
connection. In border routers I only can see the ARP for OSA interfaces, the
same MAC for two LPARs Ips (no ARP for VIPA, it's logic, it is not directly
connected).
> In the command "netstat dev" I can see the MAC address for OSA devices,
not for CIP device.
> So I think It should be possible to have the same MAC configured in CIP
and OSA devices.
>
> Regards, fernando.
>
> Fernando Ochoa de Zuazola
> mail: fernand...@t-systems.es
> Vitoria-Gasteiz - Spain
----------------------------------------------------------------------
Bill Hecox
Here is a CISCO Router configuration with a CIP Definition.
Only relevant entries are included.
source-bridge ring-group 200 <== virtual ring 200 in Cisco Router.
interface TokenRing0/0/0
no ip address
no ip directed-broadcast
no ip mroute-cache
early-token-release
ring-speed 16
source-bridge 21 1 200 <= Real T/R interface. Ring 21 bridge
1 Ring 200
source-bridge spanning
----------------------------------------------------------------------------
-------------------
interface Channel4/0
ip address 10.135.24.1 255.255.255.0
no ip redirects
no ip directed-broadcast
ip route-cache same-interface
no keepalive
claw C300 00 10.135.24.2 PROD CISCO TCPIP TCPIP broadcast
csna C300 08
csna C300 09
Interface Channel 4/0 is a point to point interface and does not contain a
mac address.
The 10.135.24.0 subnet is usually advertised to other routers to be known in
the network.
Claw statement specifies the M/F IP address. broadcast allows rip packets
to flow across interface.
Other parms on the CLAW statement are (C300) Escon Director address, (00)
last two digits of subchannel address,
"PROD CISCO TCPIP TCPIP" are matched up with parms in TCPIP PROFILE member.
CISCO can not ping the M/F CIP host ip addr if the Ping orginates in the CIP
router.
This is because of the way CISCO performs a Ping on Point-To-Point
interfaces.
The M/F can Ping the Cisco CIP ip address however.
Csna statements match up with XCA members in VTAM same as is used with
3172s.
Interface 4/2 is virtual and only exist in the CIP memory.
interface Channel4/2
no keepalive
llc2 t1-time 3000
max-llc2-sessions 4000
lan TokenRing 0 <= Virtual T/R Lan in CIP
source-bridge 2000 1 200 <= Ring 2000 Bridge 1 Ring 200 (Ring 200
defined in CISCO memory, see above)
adapter 0 4000.7507.7777 <= Virtual Mac address on Virtual T/R Lan
(Ring 2000) in CIP.
I do not remember the terminology for SNA over T/R but when a SNA station
attempts to contact (all routes broadcast)
a mac address on the network, it will locate the virtual mac through rif
(Ring 21 Bridge 1 Ring 200 Bridge 1 Ring 2000) .
If the OSA has the same MAC address. Both stations will respond to the all
routes broadcast.
Since the CIP virtual MAC 4000.7507.7777 is only in the CIP memory and not
on a physical interface an
IP ARP will never reach it.
Regards,
Bill
From: "Chris Mason" <chris...@belgacom.net>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Thursday, September 28, 2006 10:33 PM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
> > It can only be accessed with Source Route Bridging and as long as it is
> not
> > visible to the IP network.
>
> As I understand it Fernando is using IP with the CIP - see his second post
> in the thread - so the CIP must in some way be visible to IP.
>
>
Fernando Ochoa
Chris, I agree with you. I didn’t explain well. I will try to do it a new time.
1.- TCPIP pri/sec interfaces, yes, you are right, the same word is used on OAT. But I refered to ROUTING interfaces on the TCPIP stack.
2.- TCPIP profile and OMPROUTE files
DEVICE VDEV1 VIRTUAL 0
LINK VLINK1 VIRTUAL 0 VDEV1
DEVICE VDEV2 VIRTUAL 0
LINK VLINK2 VIRTUAL 0 VDEV2
DEVICE CIP CLAW 60A HOSTA C7500 NONE 20 20 4096 4096
LINK CIP1 IP 0 CIP
DEVICE OSADB4 LCS 00F0
LINK OSALB4 ETHERNET 0 OSADB4
HOME
53.254.15.1 VLINK1
53.254.21.12 OSALB4
53.254.21.33 CIP1
53.254.15.2 VLINK2
OMPCFG
RIP_Interface
IP_Address=53.254.21.12
Name=OSALB4
Subnet_Mask=255.255.255.248
MTU=1492
In_Metric=1
Out_Metric=1
RIPV2=Yes;
;
RIP_Interface
IP_Address=53.254.21.33
Name=CIP1
Subnet_Mask=255.255.255.248
MTU=1492
In_Metric=3
Out_Metric=3
Receive_RIP=RIP2
Destination_Addr=53.254.21.34
RIPV2=Yes;
;
Interface
IP_Address=53.254.15.1
Name=VLINK1
Subnet_Mask=255.255.255.0;
;
Interface
IP_Address=53.254.15.2
Name=VLINK2
Subnet_Mask=255.255.255.0;
;
Originate_RIP_Default
Condition=Never
Cost=1;
VIPA and physical devices are in different subnets.
3.- IOAJAVA
With z890/z990 appears feature OSA-Express 1000BaseT, tolerance PTFs deleted SIOAWIN member from SYS1.SIOAWIN library and added IOAJAVA to SYS1.SIOAJAVA library. After that, you must use this application to manage OSA cards.
4.- ARP
I think ARP is working OK. I saw the new mac for physical/virtual addresses un the TCPIP stack. I saw the physical int ARP un adjacent routers too (not virtual, that is in a not directly connected subnet).
5.- CIP conf
I think Bill explained it very well.
Only a note: in the past (1998), I had a lot of problems using the same bridge number for channel SRB and token-ring SRB (IOS 11.2.x). Cisco said that you can share bridge numbers, but it didn’t work for some IOS versions.
6.- NCP
Yes, I agree with you. I will ask for a new line in central NCP for ethernet OSA. I’ll try it for Subarea connection, and after that I’ll try to put it (bitswapped) in the CIP configuration. Fortunately (or not) I’m who migrated 3745 to CIP in 1997. I remember (more or less) NCP configuration, VRs, TGN, …
Thanks a lot, Regards.
---------------------------------
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
----------------------------------------------------------------------
Chris Mason
Now that I have done a bit of reading up on the CIP card - and thanks to
Bill, I'm a little clearer about this issue of the contentious MAC address.
Since the MAC address defined to the CIP card can be accessed only by a
logical SNA frame which has been "undressed" by DLSw logic in the same
router logic - so that the logical frame exists only within the router
buffers, it cannot be accessed by ARP requests on the real LAN. Thus, in
principle, what you want to do with the duplicate MAC address should be
possible - or at least it's worth trying until we discover a problem other
than ARP ...
Going back to the problem as stated in your original post, if you can "see"
the MAC address in the adjacent router, then it must be the MAC address as
specified in the OSA feature. Hence you do not have a problem "resetting"
the OSA.
Let's try to have a clear vision of which protocol "sees" what in order to
be sure you are systematic with your testing.
Returning to my configuration diagrams:
SNA configuration (unchanged from before):
Remote Local
VTAM-NCP-TR-CIP-VTAM
or
VTAM-NCP-TR-OSA-VTAM
Bridged TR configuration
NCP-seg1-DLSw router-seg2-DLSw router-seg3-(bridge)-seg4-CIP
----------------------------------
all internal
or
NCP-seg1-DLSw router-seg2-DLSw router-seg5-OSA
This is changed in that the router and CIP card contain the path from the
DLSW logic to the token ring connection end-point completely within the
router - as I suspected in my previous post. In addition, another segment
seems to be necessary - I need to do some more research on how exactly this
all hangs together.
A concern I have now is to know how, in the case of the OSA feature, the
DLSw function is performed. If this is in the same router as also contains
the CIP card, I hope it is configured to pass the "undressed" frames to and
from the real LAN and not just on the internal logical LAN. Otherwise the
SNA path will obviously not work.
IP configuration:
Remote Local
w/s IP-?-adjacent router-ethernet-router/CIP-channel-CSIP
or
w/s IP-?-adjacent router-ethernet-OSA-CSIP
Alternatively, the testing workstation (w/s) could be connected to the same
ethernet LAN as the OSA feature and the router containing the CIP card.
To progress with the duplicate MAC idea, we need to know what works and what
does not work when
1. the OSA is used without the CIP card definitions being active for both
SNA and IP
2. the CIP card is used without the OSA definitions being active for both
SNA and IP
3. both the OSA and the CIP card are used together for both SNA and IP
I'm inclined to think that testing could be with static routes so that
unexpected effects of the RIP routing are eliminated. For example, RIP has
to deal with accessing the same subnetwork both directly and indirectly
over, initially, a point-to-point link. I think the testing can be arranged
easily by using VARY OBEY on a BEGINROUTES/ENDROUTES block with and without
ROUTE statements and stopping and starting the OMPROUTE procedure.
Thinking about SNA testing, just for testing purposes, you might like to set
up a workstation and "DIAL=YES" XCA definitions so that you don't need to
bother operating the remote site VTAM - until you have had success with the
workstation testing.
Chris Mason
----- Original Message -----
From: "Fernando Ochoa" <yfzu...@yahoo.es>
Newsgroups: bit.listserv.ibmtcp-l
To: <IBMT...@VM.MARIST.EDU>
Sent: Friday, 29 September, 2006 5:47 PM
Subject: Re: [IBMTCP-L] Changing OSA Mac Address
VRs, TGN, .
>
> Thanks a lot, Regards.