Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

DECnet Phase V question.

 
The Brit
Honored Contributor

DECnet Phase V question.

Info:

OpenVMS 8.3-1H1, TCPIP Services Vers 5.6, ECO 3, DECNet Phase V. (using DECnet-over-IP)
Hardware is BL860c Itanium blade in c7000 enclosure.
Node is configured as cluster (single Node).

The blade has 4 LOM NICs, EWA0, EWB0, EWC0, and EWD0, configured through LANCP as teamed pairs, i.e.

LLA0 = (EWA0, EWB0(Active))
LLB0 = (EWC0, EWD0(Active))

LLA0 is configured in TCPIP Services as the primary system interface LE0 (See attachment).
LLB0 has no assigned IP address.

In SCACP, SCS communication is turned off on LLA, restricting cluster communication to LLB.

In the blade enclosure, the blade is configured for VC with an assigned profile. In the profile, NIC Ports 1 & 2 (EWA0 & EWB0)are directed out of the enclosure, via uplinks, to the main network.
NIC Ports 3 & 4 (EWC0 & EWD0) are confined to the enclosure backplane (i.e. no external uplink ports), this is normal for a cluster which is internal to the enclosure.

Note: There are NO observed issues with this configuration.

My question is related to the validity/correctness of the protocol assignments on the two Logical devices LLA and LLB.

When I do a

$ mc lancp show config /users ! I get :-

LLA0 EWB0 Ethernet X-31 Up 1000 Full No 1500 AA-00-04-00-32-04 MMF LLA
AA-00-00-77-0C-00 (default)
LLA3 60-07 NISCA 1498
LLA8 08-00-2B-80-3C DNA Name Service 1492
LLA9 80-3C DNA Name Service 1498
LLA10 FE DECnet-V 1497
LLA11 60-03 DNA Routing 1498
LLA12 08-00 IP 1500
LLA13 08-06 ARP 1500
LLA14 86-DD IPV6 1500
LLB0 EWD0 Ethernet X-31 Up 1000 Full No 1500 AA-00-00-77-0C-1C MMF LLB
LLB3 60-07 NISCA 1498
LLB8 08-00-2B-80-3C DNA Name Service 1492
LLB9 80-3C DNA Name Service 1498
LLB10 FE DECnet-V 1497

i.e. I see "FE DECnet-V" on both devices. Is this correct/safe/OK/scary, considering that the use of LLB may not always be just internal to the blade chassis. It may in the future be put to some other use, it may be be assigned its own IP address and allowed to exit the chassis.

Would this not cause a problem for DECnet in that both devices would be broadcasting the same DECnet address??

The question was brought up by a collegue, however I don't have the networking expertise necessary to provide an authoritative answer. I know there are smart guys out there for whom this is "bread-and-butter"

The attachment contains a bunch of information, however if you need to know any thing else, just let me know.

Thanks in advance.

Dave.
12 REPLIES 12
Graham Burley
Frequent Advisor

Re: DECnet Phase V question.

Can you post the output of:
NCL>sho csma-cd station * all

There are some logicals that will prevent DECnet starting on specific interfaces, but I'll have to check elsewhere to jog my memory.
The Brit
Honored Contributor

Re: DECnet Phase V question.

Graham,
Information attached.

thanks

Dave
Volker Halle
Honored Contributor

Re: DECnet Phase V question.

Dave,

you're not using 'DNA Routing' on LLB, so you should be safe regarding duplicate Phase IV MAC addresses. There is no routing circuit configured to use LLB0.

To get rid of the DNA Name Servcie protocols on LLB, you could use the DNS$ETHERNET_DEVICE system logical - see this thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1339751

Volker.
Hoff
Honored Contributor

Re: DECnet Phase V question.

IIRC, the FE stuff is the CLNP LSAP, which is a wad of acronyms which usually means exactly nothing to anyone that's not memorized various parts of the ISO OSI networking scheme.

CLNP within Phase V is akin to UDP within an IP stack, or to IP itself.

You're running DECnet Phase IV routing on LLA0: here, but not on LLB0:

Phase IV addressing can suffer collisions when LAN segments are bridged; without intervening managed switches and/or DECnet Phase IV routers. Native Phase V routing uses the NIC addresses, so there should be no collisions there; presuming you don't accidentally create a virtual collision using the NAT capabilities in various of the blade blocks.

Scary? No. Not at all.

[Insert Phase V snark here.]
Volker Halle
Honored Contributor

Re: DECnet Phase V question.

Dave,

you might want to clean up your DECnet configuration ! Remove all those CSMA-CD stations referring to the individual EWc devices using:

$ @NET$CONFIGURE ADVANCED
...
[3] Configure Devices on this machine
...

and enter NONE for all EW devices, which are not useable anyway, becasue they are members of LAN Failover Sets, but DECnet config is not clever enough to exclude them. You probably only want to configure LLA0 for DECnet use.

Volker.
The Brit
Honored Contributor

Re: DECnet Phase V question.

Volker,
Maybe I'm misunderstanding your comment, however it does look like there is a routing circuit on LLB, (see attachment).

The only difference that I can see between LLA and LLB is, as pointed out by Hoff, that PhaseIV addressing is enabled on LLA, but not on LLB.

Dave
Bill Hall
Honored Contributor

Re: DECnet Phase V question.

Dave,

I've attached the LANCP and NCL output from one of my ES47 that contains four DEGX2-TA for a total of eight ports. They are configured as three LL devices, LLA for DECnet V with phase IV addressing, LLB for public tcpip and LLC for a private tcpip network, and two ports are used for SCA communications only.

Your configuration may work, but it isn't pretty and may hinder troubleshooting a real problem in the future. If it were my system, I'd want to clean it up, per Volker's suggestion as a start.

Bill
Bill Hall
Volker Halle
Honored Contributor

Re: DECnet Phase V question.

Dave,

yes, LLB does not use a DECnet Phase IV compatible address, so no 60-03 protocol (DNA-Routing).

But please consider to clean up your DECnet config as suggested in my previous reply.

Volker.
Graham Burley
Frequent Advisor

Re: DECnet Phase V question.

[There are some logicals that will prevent DECnet starting on specific interfaces, but I'll have to check elsewhere to jog my memory.]

I think my memory was actually jangling about DECdts / DTSS.