On a KL emulation running Tops-20, if you want to run Phase IV,
you have a choice of the CI or NI. In order to not implement ARP
for DECnet, they came up with the idea of a certain range of 48
bit MAC address having a direct mapping.
For the CI, this is built off of the CI interface number and
there is no getting around that, as I recall. For the NI, it
wants to pick the MAC address. You can get around this by knowing
what MAC address it will pick and configuring that. It's
sometimes easier to just spend the $15 and get another USB
interface and dedicate it to the engine.
Otherwise, if you have three separate klh10's, they will insist on having their own separate MAC address.
I wasn't sure how you could do that except maybe with virtual
machines and some kind of hypervisor.
Oh. One more thing - tap2 and tap3 are for KLH, right? Is there some trickery you need to do in order to get the DECnet correct MAC address on things here? Also applies for the PyDECnet instance perhaps...
Johnny
On 2024-05-16 20:30, Anders Andersson wrote:
Thank you foryourfeedback Yes,the KLH10istancesall run on thsame Linux Mint
host that runs the apydecanet router calledKSKAL,and I haveno additioal
hardware on that internal segment which lookslike this now:
oot@kaskal:/home/andersa# brctl show
bridge name bridge id STP enabled interfaces
bridge0 8000.26d039e4c0f4 no tap1
tap2
tap3
If that doesn't indicate that thethreetap interfaceshavbeen addedto
the bridge,I don't know what does. Are there any other diagnostics you
want me to check? I dont know whether the following add anything relevant:
root@kaskal:/home/andersa# ifconfig bridge0
bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.9.78 netmask 255.255.255.0 broadcast 192.168.9.255
inet6 fe80::4cf6:1fff:fe01:f257 prefixlen 64 scopeid 0x20<link>
ether 26:d0:39:e4:c0:f4 txqueuelen 1000 (Ethernet)
RX packets 557072 bytes 143985475 (143.9 MB)
RX errors 0 dropped 450854 overruns 0 frame 0
TX packets 106193 bytes 4586565 (4.5 MB)
TX errors 0 dropped 0overruns 0 carrier 0 collisions 0
root@kaskal:/home/andersa# ifconfig tap1
tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::6032:eff:fedb:7b94 prefixlen 64 scopeid 0x20<link>
ether 62:32:0e:db:7b:94 txqueuelen 1000 (Ethernet)
RX packets 176227 bytes 46414104 (46.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 318825 bytes 90356527 (90.3 MB)
TX errors 0 dropped 0overruns 0 carrier 0 collisions 0
root@kaskal:/home/andersa# ip tuntap show
tap0: tap persist
tap1: tap
tap2: tap
tap3: tap
The threeTOPS-20 hosts arealso awareof and can communicate with each
other. When I run tcpdump -i bridge0 I do see DECnet, DEC LAT and TCP/IP
ARP traffic to or from the three TOPS-20 hosts pass by,according to the
ethertype code as well as decoding done by tcpdump.
The KLH10 instances obtain their tap interfaces as part of their
startup configuration, so I have to restart them whenever I have reset
the bridge which I haven't done in a few days now. This is a sample net
device onfiguration line from one host:
devdef ni0 564 ni20 dedic=true ifc=tap2 ifmeth=tap+bridge ipaddr=192.168.9.72
dpdelay=3
The number of the interface specified with ifc= doesn't seem to matter the machine
still gets assigned the next unassiged tap interface in order.And it did work previously.
Eventually I hope to put all the bridge and pydecnet configuration intoa
hecnet.service file andstart it from systemd.
Now I plan to restartpydecnet while logging bridg0 traffic using tcpdmpto see
what comes up.
/AndersAndersson
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se