Hello,

merry xmas to you all. I hope you can enjoy some stressless days with your loved ones.

I'm using the days off work to do some cleanup work here and there. One of that is that I want to migrate my routed (tun) network connection of an OS/390 instance running in Hercules 4.4.1.0-SDL, in turn running on a Linux Debian 11 machine, to tap. I want to spare multiple intermediate routing networks but have the machine appear at the local LAN with its designated MAC address.

The very same instance runs SNA 802.2 DLC on a bridged interface without issue.

Hercules runs as root, but I prefer preconfigured interfaces for Hercules to use.

I don't use the fancy new Network Manager, but stock /etc/network/interfaces configuration:
- Eth1 is the physical port connected to the LAN switch (works),
- Tap0 is the bridged interface for SNA (works),
- Tap1 is the bridged interface for IP (doesn't work).


---8<--- /etc/network/interfaces ---8<---

auto eth1 tap0 tap1 br0

# Hercules OS/390: Port LAN Port
iface eth1 inet manual
up /sbin/ip link set dev $IFACE up

# Hercules OS/390: TAPs for Bridging.
iface tap0 inet manual
pre-up /sbin/ip tuntap add mode tap
up /sbin/ip link set dev $IFACE address 02:00:FE:DF:00:42
up /sbin/ip link set dev $IFACE up
post-down /sbin/ip link del dev $IFACE

iface tap1 inet manual
pre-up /sbin/ip tuntap add mode tap
up /sbin/ip link set dev $IFACE address 02:00:FE:DF:01:42
up /sbin/ip link set dev $IFACE up
post-down /sbin/ip link del dev $IFACE

# Bridge everything together and assign an IP address to the bridge.
iface br0 inet static
address 192.168.59.12
netmask 255.255.255.128
gateway 192.168.59.1
bridge_ports tap0 tap1 eth1

---8<---


Hercules configuration excerpt:

---8<---

0E40 LCS -e SNA tap0
0E42.2 LCS tap1

---8<---


Relevant configuration excerpts from TCPIP.PROFILE.TCPIP:

---8<---

; Required for EE
DEVICE IUTSAMEH MPCPTP
LINK LSAMEH MPCPTP IUTSAMEH

DEVICE LCS1 LCS E42
LINK TAP1 ETHERNET 1 LCS1


HOME
192.168.59.89 TAP1


PRIMARYINTERFACE TAP1


GATEWAY
;
; Direct Routes - Routes that are directly connected to my interfaces.
;
; Network First Hop Link Pkt Subnet Mask Subnet Value
; Class Hop Name Size (excl. Class!) (Remainder)

;The next commented line gives us an error:
;17.10.00 STC00043 EZZ0312I THE SUBNET MASK ON LINE 230 CONTAINS AN INCORRECT VALUE 0.0
;192.168 = TAP1 1492 0.0.255.128 0.0.59.0
192.168.59 = TAP1 1492 0


DEFAULTNET 192.168.59.1 TAP1 1492 0


START LCS1
START IUTSAMEH

---8<---

Link starts without error:

17.55.46 STC00052 EZZ4314I INITIALIZATION COMPLETE FOR DEVICE LCS1, LINK TAP1


I can see the MAC addresses of all three bridged devices on the switch port:

sw-keller-1g#show mac address-table | incl Gi0/2$
1 0200.fedf.0043 DYNAMIC Gi0/2
1 0200.fedf.0143 DYNAMIC Gi0/2
1 7efc.3ef5.66ca DYNAMIC Gi0/2

Note that the TAP code automatically increments the MAC address given while configuring the interface by one. So, the host-local side of the TAP has 02:00:fe:df:01:42, but the guest-local side uses 02:00:fe:df:01:43!


But I can't ping.


When "S TCPIP" is run from the master console, the TCP/IP code seems to check for IP address collisions:

18:01:13.178327 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.59.89 tell 192.168.59.89, length 46

Then it does a lookup because I've configured a DNS server (192.168.59.10):

18:01:13.784330 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.59.10 tell 192.168.59.89, length 46
18:01:13.784723 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP (0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8, length 46
18:01:14.811173 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.59.10 tell 192.168.59.89, length 46
18:01:14.811627 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP (0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8, length 46

This happens 11 times. Apparently, the ARP answer doesn't make it back to OS/390, because it tries multiple times?


Looking at 192.168.59.10's local ARP table, I see that the MAC address from tap1 is visible after S TCPIP but is purged after a while:

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at 02:00:fe:df:01:43 [ether] on ens160

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at <incomplete> on ens160

Now setting a static ARP entry on 192.168.59.10… but I still can't ping.


Looking at the local ARP cache of OS/390 via OMVS netstat -R ALL command shows that it only knows about its own MAC address and nothing else:

MVS TCP/IP onetstat CS V2R10 TCPIP Name: TCPIP
Querying ARP cache for address 192.168.59.89
Link: TAP1 ETHERNET: 0200FEDF0143


Unfortunately, I can't find out how to set a static ARP entry from OMVS. There seems to be no related command in ls /usr/lpp/tcpip/[s]?bin/


Browsing SG24-5227-01 (OS/390 eNetwork Communications Server V2R7 TCP/IP Implementation Guide
Volume 1: Configuration and Routing) there are some commands mentioned which aren't there in V2R10 ADCD, such as oeifconfig (PDF Page 506). The document can be obtained here:


Questions:
- How can I set a static arp entry in OS390 V2R10 ADCD?
- Is my GATEWAY configuration correct (sans assuming a /24 network instead of a /25)?
- Has anybody successfully established TCP/IP-Networking in a bridged environment as described above?

Thank you!

:wq! PoC

Fish, you are the guru of the LCS interface. Hope you see this post.
You may have some insight for troubleshooting this.

You are on the right track. Can you look at any stats that show
dropped packets? This might tell you how far the response got before
it could not make it to the host.

Also, it is a little unclear which component you are wanting to respond
with the ARP? OMVS or the host based bridge.

Can you get the bridge to do a packet trace? Or the TCP/IP trace at
the Layer-2 level? This might be informative about who is responding
(or not).

Packet counts might be useful in determining who is sending and who is
receiving if anyone.

Scroll down to the show mac address-table output...

Harold Grovesteen

On Sun, 2022-12-25 at 18:09 +0100, Patrik Schindler wrote:

Hello,

merry xmas to you all. I hope you can enjoy some stressless days with
your loved ones.

I'm using the days off work to do some cleanup work here and there.
One of that is that I want to migrate my routed (tun) network
connection of an OS/390 instance running in Hercules 4.4.1.0-SDL, in
turn running on a Linux Debian 11 machine, to tap. I want to spare
multiple intermediate routing networks but have the machine appear at
the local LAN with its designated MAC address.

The very same instance runs SNA 802.2 DLC on a bridged interface
without issue.

Hercules runs as root, but I prefer preconfigured interfaces for
Hercules to use.

I don't use the fancy new Network Manager, but stock
/etc/network/interfaces configuration:
- Eth1 is the physical port connected to the LAN switch (works),
- Tap0 is the bridged interface for SNA (works),
- Tap1 is the bridged interface for IP (doesn't work).


---8<--- /etc/network/interfaces ---8<---

auto eth1 tap0 tap1 br0

# Hercules OS/390: Port LAN Port
iface eth1 inet manual
????????up /sbin/ip link set dev $IFACE up

# Hercules OS/390: TAPs for Bridging.
iface tap0 inet manual
????????pre-up /sbin/ip tuntap add mode tap
????????up /sbin/ip link set dev $IFACE address 02:00:FE:DF:00:42
????????up /sbin/ip link set dev $IFACE up
????????post-down /sbin/ip link del dev $IFACE

iface tap1 inet manual
????????pre-up /sbin/ip tuntap add mode tap
????????up /sbin/ip link set dev $IFACE address 02:00:FE:DF:01:42
????????up /sbin/ip link set dev $IFACE up
????????post-down /sbin/ip link del dev $IFACE

# Bridge everything together and assign an IP address to the bridge.
iface br0 inet static
????????address 192.168.59.12
????????netmask 255.255.255.128
????????gateway 192.168.59.1
????????bridge_ports tap0 tap1 eth1

---8<---


Hercules configuration excerpt:

---8<---

0E40??? LCS? -e SNA tap0
0E42.2? LCS? tap1

---8<---


Relevant configuration excerpts from TCPIP.PROFILE.TCPIP:

---8<---

; Required for EE
DEVICE IUTSAMEH MPCPTP
LINK?? LSAMEH?? MPCPTP IUTSAMEH

DEVICE LCS1?? LCS?????????? E42
LINK?? TAP1? ETHERNET? 1? LCS1


HOME
?? 192.168.59.89? TAP1


PRIMARYINTERFACE TAP1


GATEWAY
;
; Direct Routes - Routes that are directly connected to my
interfaces.
;
; Network??? First Hop?? Link??? Pkt????? Subnet Mask??? Subnet Value
; Class????? Hop???????? Name??? Size???? (excl. Class!) (Remainder)

;The next commented line gives us an error:
;17.10.00 STC00043? EZZ0312I THE SUBNET MASK ON LINE 230 CONTAINS AN
INCORRECT VALUE 0.0
;192.168?????? =???????? TAP1??? 1492???? 0.0.255.128??? 0.0.59.0
?192.168.59??? =???????? TAP1??? 1492???? 0


DEFAULTNET 192.168.59.1? TAP1??? 1492 0


START LCS1
START IUTSAMEH

---8<---

Link starts without error:

17.55.46 STC00052? EZZ4314I INITIALIZATION COMPLETE FOR DEVICE LCS1,
LINK TAP1


I can see the MAC addresses of all three bridged devices on the
switch port:

sw-keller-1g#show mac address-table | incl Gi0/2$
?? 1??? 0200.fedf.0043??? DYNAMIC???? Gi0/2
?? 1??? 0200.fedf.0143??? DYNAMIC???? Gi0/2
?? 1??? 7efc.3ef5.66ca??? DYNAMIC???? Gi0/2

Note that the TAP code automatically increments the MAC address given
while configuring the interface by one. So, the host-local side of
the TAP has 02:00:fe:df:01:42, but the guest-local side uses
02:00:fe:df:01:43!

It does not look like the host is getting any packets from the bridge.
Either the bridge is not sending them, or TCPIP or LCS is dropping
them.

I, like you, find the two different MAC addresses concerning.

I am back to a packet trace, if you can manage one from something. I
would try to get the host and bridge to use the same MAC addresses
preferably through configuration (somewhere). But MAC addresses might
not be the problem.

But I can't ping.


When "S TCPIP" is run from the master console, the TCP/IP code seems
to check for IP address collisions:

18:01:13.178327 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: Request who-has 192.168.59.89 tell
192.168.59.89, length 46

Then it does a lookup because I've configured a DNS server
(192.168.59.10):

18:01:13.784330 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: Request who-has 192.168.59.10 tell
192.168.59.89, length 46
18:01:13.784723 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP
(0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8,
length 46
18:01:14.811173 02:00:fe:df:01:43 > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: Request who-has 192.168.59.10 tell
192.168.59.89, length 46
18:01:14.811627 00:50:56:98:0a:f8 > 02:00:fe:df:01:43, ethertype ARP
(0x0806), length 60: Reply 192.168.59.10 is-at 00:50:56:98:0a:f8,
length 46

This clearly says the host IP stack is sending an ARP response. As you
say the guest never sees it.

Back to packet counts. Hopefully these will reveal where the hole
exists.

This happens 11 times. Apparently, the ARP answer doesn't make it
back to OS/390, because it tries multiple times?


Looking at 192.168.59.10's local ARP table, I see that the MAC
address from tap1 is visible after S TCPIP but is purged after a
while:

Purging of inactive ARP cache entries is normal for ARP caches. It is
why in some cases a static ARP cache entry is helpful.

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at 02:00:fe:df:01:43 [ether] on ens160

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at <incomplete> on ens160

Now setting a static ARP entry on 192.168.59.10…? but I still can't
ping.


Looking at the local ARP cache of OS/390 via OMVS netstat -R ALL
command shows that it only knows about its own MAC address and
nothing else:

MVS TCP/IP onetstat CS V2R10?????? TCPIP Name: TCPIP
Querying ARP cache for address 192.168.59.89
Link: TAP1????????????? ETHERNET: 0200FEDF0143


Unfortunately, I can't find out how to set a static ARP entry from
OMVS. There seems to be no related command in ls
/usr/lpp/tcpip/[s]?bin/


Browsing SG24-5227-01 (OS/390 eNetwork Communications Server V2R7
TCP/IP Implementation Guide
Volume 1: Configuration and Routing) there are some commands
mentioned which aren't there in V2R10 ADCD, such as oeifconfig (PDF
Page 506). The document can be obtained here:



Questions:
- How can I set a static arp entry in OS390 V2R10 ADCD?
- Is my GATEWAY configuration correct (sans assuming a /24 network
instead of a /25)?
- Has anybody successfully established TCP/IP-Networking in a bridged
environment as described above?

Thank you!

:wq! PoC

Harold Grovesteen wrote:

Fish, you are the guru of the LCS interface.

I am?! When did this happen? Seriously! I know a little bit about LCS, sure, but I would hardly classify myself as a "guru"! (Especially not for Linux!!)

Hope you see this post.
You may have some insight for troubleshooting this.

You are on the right track.

I am?! How can that be?! I never responded to Patrik's post!

And the reason I didn't respond was because whatever his problem is completely out of my league. I know virtually NOTHING about Linux networking. (His use of "IUTSAMEH" in his guest's TCPIP profile is also something I'm unfamiliar with.)

Can you look at any stats that show dropped packets? This might
tell you how far the response got before it could not make it to
the host.

You must be talking to Patrik and not me! Yes?

Also, it is a little unclear which component you are wanting to
respond with the ARP? OMVS or the host based bridge.

Can you get the bridge to do a packet trace? Or the TCP/IP trace
at the Layer-2 level? This might be informative about who is
responding (or not).

A packet trace would probably help. I use Wireshark myself on Windows. I have no idea what you would use on Linux.

Sorry I can't offer more, but as I said, Linux networking issues are *completely* out of my league!

Sorry! :(

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

开云体育

Hello Harold,

thanks for chiming in!


Am 05.01.2023 um 21:05 schrieb Harold Grovesteen <h.grovsteen@...>:

You are on the right track. Can you look at any stats that show dropped packets? This might tell you how far the response got before it could not make it to the host.

Not sure if something not there can be counted. I think the only option I have is to check at each possible "tap" if things look complete, or not.

Also, it is a little unclear which component you are wanting to respond with the ARP? OMVS or the host based bridge.

Well, only things with an IP address are supposed to "speak" ARP. So it's the TCP/IP stack of OS/390 I suppose to respond. The host based bridge should be transparent, because it's not involved with L3 processing.

That this setup works in general is proven by the same bridge-group including a separate LCS device using SNA. And I do have a working connection to my AS/400 on Ethernet.

Can you get the bridge to do a packet trace?

I have not yet found out. But I can tcpdump on either side of the bridge and the packets I see are the same.

All in all, I've come to the conclusion that I probably have at least one configuration error in the TCPIP profile. Therefore I should read though the TCP/IP manual(s) being available. This is on my (seemingly endless) ToDo-List. :-)

I also should have a closer look about the encapsulation being used: Everybody speaks Ethernet II for IP. But as Grant Taylor pointed out, 802.2 LLC might be involved on the mainframe side.

It does not look like the host is getting any packets from the bridge. Either the bridge is not sending them, or TCPIP or LCS is dropping them.

I, like you, find the two different MAC addresses concerning.

Are they? Ian Shorter once pointed out that a TAP interface is just a L2 "pipe". The host side is an ordinary network interface, and the other (within Hercules) is API calls. You configure the "base" MAC with the ip command and the other side automatically is configured with that MAC + 1. I didn't take my time to find this in the official tuntap documentation. But it makes sense. One can *probably* change the guest side's MAC with an API call from within the guest.

I am back to a packet trace, if you can manage one from something. I would try to get the host and bridge to use the same MAC addresses preferably through configuration (somewhere).

Every switch (aka multiport-bridge) has MAC addresses on each port, because if (for any reason) the bridge must generate a packet by itself, it has a valid "return" address.

So, I'd rather not. If the bridge has a local MAC equal to the "output of the funnel" within Hercules, I bet packets won't be forwarded anymore: The L2 code in the kernel assumes they're addressed to itself. So they clearly must be distinct.

But MAC addresses might not be the problem.

I also thought about MAC addresses once. On a second look, they largely don't matter, because they're not involved in the packet forwarding process at all. Only the endpoints' MAC addresses matter. It's the learning and MAC table which matters. I just looked up the proper command for the Linux bridge: brctl showmacs [bridge]

Purging of inactive ARP cache entries is normal for ARP caches. It is why in some cases a static ARP cache entry is helpful.

I'm aware. :-)

But since I didn't find out how to set a static ARP entry on OS/390, there was no further diagnosing.

Thank you for your input! As said, I need to review the documentation at this point. I'm sure the culprit is either there, or an encapsulation mismatch.

:wq! PoC

Hi Patrik,

Your TCPIP.PROFILE.TCPIP contains:

DEVICE LCS1 LCS E42
LINK TAP1 ETHERNET 1 LCS1

The LINK statement is wrong, it should be:

LINK TAP1 ETHERNET 0 LCS1

Your Hercules configuration statement:
0E42.2 LCS tap1
creates an LCS with a single adapter, numbered 0.

Cheers, Ian

Hello Ian,

Am 09.01.2023 um 10:36 schrieb Ian <ian@...>:

Your TCPIP.PROFILE.TCPIP contains:

DEVICE LCS1 LCS E42
LINK TAP1 ETHERNET 1 LCS1

The LINK statement is wrong, it should be:

LINK TAP1 ETHERNET 0 LCS1

Your Hercules configuration statement:
0E42.2 LCS tap1
creates an LCS with a single adapter, numbered 0.

You da man! Thank you *very* much! You have a really sharp look! I'm very impressed!

Indeed, that solved the problem. Apparently no encapsulation issue with 802.2 LLC.

Now I need to find out why I can successfully ping from both sides of an EE connection form OS/390 to a newer IBM i box, but the EE connection doesn't come up.

Btw., adding the device(s) to Hercules at runtime, starting TCPIP, ending it and starting it anew yielded an error message about starting the device. A Hercules quit and IPL solved this issue. You want me to provide more details? Os is this enough for you to probably duplicate the issue?

:wq! PoC

Hi Patrik,

No, 802 played no part, the ETHERNET in the LINK statement specifies that the link will only use the Ethernet II protocol. If you specify 802.3 instead of ETHERNET the link will only use the 802.3 protocol, if you specify ETHEROR802.3 instead of ETHERNET the link will use both Ethernet II and?802.3 protocols. If you specify either of the 802 options, things may break!
?
Re the?adding the device(s) to Hercules at runtime question, create an issue at??showing the steps you take to (re)create the problem.

Cheers, Ian

Hello PoC,
I had the same problem just recently try changing this?

LINK TAP1 ETHERNET 1 LCS1

to this?

LINK TAP1 ETHERNET 0 LCS1

that's what fixed my system.
hope this helps!

Regards,
Vincent

Hi Patrik,

Happy New Year.

Here are some comments based on my experience with OS/390 on TAPs.? I don't use EE, but APPN and Subarea SNA work, as well as TCPIP.? I do not run Hercules as root.

---8<--- /etc/network/interfaces ---8<---

auto eth1 tap0 tap1 br0

# Hercules OS/390: Port LAN Port
iface eth1 inet manual
up /sbin/ip link set dev $IFACE up

# Hercules OS/390: TAPs for Bridging.
iface tap0 inet manual
pre-up /sbin/ip tuntap add mode tap
up /sbin/ip link set dev $IFACE address 02:00:FE:DF:00:42
up /sbin/ip link set dev $IFACE up
post-down /sbin/ip link del dev $IFACE

iface tap1 inet manual
pre-up /sbin/ip tuntap add mode tap
up /sbin/ip link set dev $IFACE address 02:00:FE:DF:01:42
up /sbin/ip link set dev $IFACE up
post-down /sbin/ip link del dev $IFACE

# Bridge everything together and assign an IP address to the bridge.
iface br0 inet static
address 192.168.59.12
netmask 255.255.255.128
gateway 192.168.59.1
bridge_ports tap0 tap1 eth1

---8<---

I run the network manager now, but based on some old notes I had from before, I don't see any issues with your configuration.? It looks like mine did before converting over to NMCLI.? Since it's working for SNA, that seems a good indicator that it should be right.

Hercules configuration excerpt:

---8<---

0E40 LCS -e SNA tap0
0E42.2 LCS tap1

---8<---

Yep, looks like mine (except for the TAP names).
5ce.2 LCS tap0501??????????????????? # for Linux / TCPIP
5de LCS -e SNA tap0502?????????????? # for Linux / SNA/APPN
5ee LCS -e SNA tap0503?????????????? # for Linux / SNA/Subarea

Relevant configuration excerpts from TCPIP.PROFILE.TCPIP:

---8<---

; Required for EE
DEVICE IUTSAMEH MPCPTP
LINK LSAMEH MPCPTP IUTSAMEH

?DEVICE VIPA1??? Virtual 0???? ?
?LINK?? LVIPA1?? Virtual 0 VIPA1
?DEVICE IUTSAMEH MPCPTP??????? ?
?LINK?? LSAMEH?? MPCPTP IUTSAMEH
I have a VIPA in my config that you don't, but I can't see that affecting basic functionality.

DEVICE LCS1 LCS E42
LINK TAP1 ETHERNET 1 LCS1

Here's my config for the LCS.? I see you are specifying port 1 where I have 0, you might try switching that.
? DEVICE ENT0?? LCS??????? 5CE ?
? LINK?? EN0??? ETHERNET 0 ENT0

HOME
192.168.59.89 TAP1

Looks good.

PRIMARYINTERFACE TAP1

Same, same.

GATEWAY
;
; Direct Routes - Routes that are directly connected to my interfaces.
;
; Network First Hop Link Pkt Subnet Mask Subnet Value
; Class Hop Name Size (excl. Class!) (Remainder)

;The next commented line gives us an error:
;17.10.00 STC00043 EZZ0312I THE SUBNET MASK ON LINE 230 CONTAINS AN INCORRECT VALUE 0.0
;192.168 = TAP1 1492 0.0.255.128 0.0.59.0
192.168.59 = TAP1 1492 0


DEFAULTNET 192.168.59.1 TAP1 1492 0

I gave up trying to figure out IBM's GATEWAY format and went with BEGINROUTES/ENDROUTES.? It was just easier for me to look at and understand..
?BEGINROUTES??????????????????????????????????????????????????????? ?
; ROUTE Destination???? Subnet Mask???? First Hop?????? Link MTU Size
; ROUTE xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx EN0? MTU 1492
? ROUTE 192.168.1.0/24????????????????? =?????????????? EN0? MTU 1492
? ROUTE 10.0.0.0/8????????????????????? 192.168.1.21??? EN0? MTU 1492
? ROUTE 172.16.0.0/12?????????????????? 192.168.1.21??? EN0? MTU 1492
? ROUTE 192.168.0.0/16????????????????? 192.168.1.21??? EN0? MTU 1492
? ROUTE DEFAULT???????????????????????? 192.168.1.254?? EN0? MTU 1492
?ENDROUTES??????????????????????????????????????????????????????????

START LCS1
START IUTSAMEH

Yep, me too.

---8<---

So, I guess the only possible configuration issue I can see would be the port number on the LCS LINK statement.

Link starts without error:

17.55.46 STC00052 EZZ4314I INITIALIZATION COMPLETE FOR DEVICE LCS1, LINK TAP1

Yep
15.02.55 STC01703? EZZ4314I INITIALIZATION COMPLETE FOR DEVICE ENT0, LINK EN0

I can see the MAC addresses of all three bridged devices on the switch port:

sw-keller-1g#show mac address-table | incl Gi0/2$
1 0200.fedf.0043 DYNAMIC Gi0/2
1 0200.fedf.0143 DYNAMIC Gi0/2
1 7efc.3ef5.66ca DYNAMIC Gi0/2

I can see the MACs of the IP interface on OS/390 in the switch here.? I can ping to and from a VM/ESA image on a different switch port and I've got a Subarea SNA link up to it as well.

s3560a>show mac address-table | inc Fa0/3
?? 1??? 0200.0200.0000??? DYNAMIC???? Fa0/3? <-- Raspberry Pi bridge interface
?? 1??? 0205.0100.0001??? DYNAMIC???? Fa0/3? <-- OS/390 TCP/IP interface
s3560a>

Note that the TAP code automatically increments the MAC address given while configuring the interface by one. So, the host-local side of the TAP has 02:00:fe:df:01:42, but the guest-local side uses 02:00:fe:df:01:43!

Right.? I configured a .00 address in NMCLI and Hercules bumped it to .01 for OS/390.

I'll skip the traces for now.? If the config issue above doesn't answer this, hit me up and I'll take another run with traces.

FYI, to help understand the below output, my current set up is:

OS/390 ----- Raspberry Pi ----- Cisco 3560 ----- Raspberry Pi ----- VM/ESA

My OS/390 image (hostname JS05, 192.168.1.105) is running on a Raspberry Pi (Pi2, 192.168.1.2).? Pi2 is connected to switch port Fa0/3 on the 3560.? My VM/ESA image (JS01, 192.168.1.101) is running on Pi1, IP address 192.168.1.1.? It is connected to switch port Fa0/1 on the 3560.

The OS/390 interfaces have the following MAC addresses:
TCPIP - 02.03.01.00.00.01? (my TAP0501, equivalent to your TAP1)
APPN - 02.03.02.00.00.01 (not currently inuse)
Subarea - 02.03.03.00.00.01 (my TAP0503, your TAP0)

Looking at 192.168.59.10's local ARP table, I see that the MAC address from tap1 is visible after S TCPIP but is purged after a while:

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at 02:00:fe:df:01:43 [ether] on ens160

Looking at my host's arp table, I see my guest (OS/390).
jeff@Pi2:~ $ arp -an | fgrep 105
? (192.168.1.105) at 02:05:01:00:00:01 [ether] on br0

# arp -an |fgrep 192.168.59.89
? (192.168.59.89) at <incomplete> on ens160

Checking back a few minutes later shows it still acitve, so it didn't go away like yours did.
jeff@Pi2:~ $ arp -an | fgrep 105
? (192.168.1.105) at 02:05:01:00:00:01 [ether] on br0

Looking at the local ARP cache of OS/390 via OMVS netstat -R ALL command shows that it only knows about its own MAC address and nothing else:

MVS TCP/IP onetstat CS V2R10 TCPIP Name: TCPIP
Querying ARP cache for address 192.168.59.89
Link: TAP1 ETHERNET: 0200FEDF0143

Not so, here...
JEFF:/u/jeff: >onetstat -R ALL
MVS TCP/IP onetstat CS V2R10?????? TCPIP Name: TCPIP??????????? 16:44:32
Querying ARP cache for address 192.168.1.101 (JS01, the VM/ESA image)
Link: EN0?????????????? ETHERNET: 020101000001

Querying ARP cache for address 192.168.1.32 (my Windows workstation, where I telneted from)
Link: EN0?????????????? ETHERNET: 6805CA3AB46C

Querying ARP cache for address 192.168.1.105 (JS05, OS/390, self)
Link: EN0?????????????? ETHERNET: 020501000001

Querying ARP cache for address 192.168.1.254 (my default gateway and DNS server)
Link: EN0?????????????? ETHERNET: DC7FA4213C55

Questions:
- How can I set a static arp entry in OS390 V2R10 ADCD?

Sorry, I don't know.

- Is my GATEWAY configuration correct (sans assuming a /24 network instead of a /25)?

It looks right to me, but I've had issues with GATEWAY and moved on the BEGIN/ENDROUTE, so I may be missing something.

- Has anybody successfully established TCP/IP-Networking in a bridged environment as described above?

Yes.? All 4 of my Pis are configured this way.? A lot of my images don't support TCP (or some even, SNA), but those that do run like this.


Good luck, I hope you find your issue.? If that configuration issue in TCPIP's LINK statement doesn't fix it and you'd like me to run some traces, let me know.
Jeff

开云体育

Jeff and Patrik,

You have no idea how much pleasure I receive in seeing these networking configurations, and per your responses WORKING!

My first IT job involved networking before networking as we know it today existed in the mid-1970's.? Worked with 270x / 270x EP systems and BTAM.? Worked with multi-subarea SNA networks and VTAM. Worked with the first release of mainframe TCP/IP on both MVS and VM.? From there expanded to various routers and switches in global IP networks, some transporting SNA.

And helped with Hercules networking along the way, QDIO in particular.

I have long since lost interest in system administration once I retired.? (Moved onto my own thing.) But, am very pleased to see these capabilities used in the emulation space and the new "blood" doing and learning.

Just wanted you to both know of my appreciation.? Keep up the good work!!

Harold Grovesteen