Juniper EX Virtual-Chassis Host-Name

Let’s assume that you are creating a Juniper virtual-chassis switch using, say, three EX4200s. Should you configure a host-name that represents the whole VC, or should you have names for each individual member of the VC instead? And how do you configure those? Well it’s simple, but there are some gotchas involved.

Decide on a Naming Scheme

The simplest approach is probably to figure out the name for the VC as a single entity, and then – optionally – distinguish each chassis with a suffix to that name. For example, you might have:

     VC Name: vcsw01

Member Names: vcsw01a, vcsw01b and vcsw01c

But there’s a problem here – all members of the VC will share the same configuration, so if you do “set system hostname”, then all three systems will implicitly inherit the same name. The switches actually don’t have a problem with that, and in fact if you really don’t care which member you’re connecting to so long as it’s the master, it may be unimportant – except for the Data Center Operations folks, who need to be able to identify the individual members perhaps. So, assuming you want to just name the VC, it’s as simple as naming any other Junos device:

set system host-name vcsw01

EX Console Access

This is where it all gets complicated. Two things are worth considering when you connect to the console of a virtual-chassis switch:

1. The login prompt will reflect the system host-name. If you just set a name for the VC as a whole, you will see the same hostname regardless of which console you connect to.
2. Juniper VC assumes – perhaps reasonably – that since most commands are only valid on the master VC member, you should always connect there. Thus when you connect to a non-master VC member, you are redirected to the master anyway:

vcsw01 (ttyu0)

login: john

Logging to master
Password:

--- JUNOS 12.3R3.4 built 2013-06-14 00:08:02 UTC
{master:0}
john@vcsw01>

Ok, so how do you know which VC member you are physically consoled through? Well, for VCs containing three or more hosts I will explain a method in the next post, but suffice it to say that unless I missed a really obvious command, it’s not straightforward to find out.

One immediate clue, regardless of how many hosts you have in the VC, is that if you console into the master switch, you do not see the “Logging to master” message. If there are only two switches in the VC, then by a process of elimination you know that the other console must be the second member – but that’s not so useful for a VC with three members.

Name The Members

So if you’re convinced that it’s worth considering naming the VC members uniquely, then the good news is that it’s relatively straightforward. All it requires is that you add group configuration for each member in the virtual chassis. In this example, there are three members, numbered 0, 1 and 2:

set groups member0 system host-name vcsw01a
set groups member1 system host-name vcsw01b
set groups member2 system host-name vcsw01c
set apply-groups [ member0 member1 member2 ]

Which gives us:

groups {
    member0 {
        system {
            host-name vcsw01a;
        }
    }
    member1 {
        system {
            host-name vcsw01b;
        }
    }
    member2 {
        system {
            host-name vcsw01c;
        }
    }
}
apply-groups [ member0 member1 member2 ];

It’s that simple. Oh, but when I log in on the console, it still only says “vcsw01”. That’s because you also have to remove the ‘main’ system host-name in order for this to take effect; otherwise, it overrides the group configuration. Let’s do that:

{master:0}[edit]
john@vcsw01# delete system host-name
{master:0}[edit]
john@vcsw01# commit
fpc0:
configuration check succeeds
fpc1:
commit complete
fpc2:
commit complete
fpc0:    
commit complete

{master:0}[edit]
john@vcsw01a#

The hostname in my command prompt immediately reflects the change; note that I now see vcsw01a . Hooray! Now let me console into member 1 instead, and check the prompt:

vcsw01 (ttyu0)

login:

Oh. The login prompt doesn’t identify the host after all. Well this is just a quirk it seems. Log in, then log out again:

vcsw01 (ttyu0)

login: john

Logging to master
Password:

--- JUNOS 12.3R3.4 built 2013-06-14 00:08:02 UTC
{master:0}
john@vcsw01a> quit

vcsw01b (ttyu0)

login:

And viola (sic). We now know which member of the VC we are connecting to!

DNS and Network Management

Don’t forget that for management purposes you will still want a DNS entry for ‘vcsw01’ that should point to the IP address configured on vme.0, which is the management address for the whole virtual-chassis:

set interfaces vme unit 0 family inet address 10.255.255.104/24

You might also want to set up CNAME entries for vcsw01a,b and c pointing back to vcsw01, for simplicity. When I connect to host ‘vcsw01’, I will automatically connect to the master chassis (via vme.0), and based on my command prompt I now immediately know which chassis is master:

{master:1}
john@vcsw01b>

In this case, there has been a routing-engine switchover, and now ‘vcsw01b’ is master rather than vcsw01b. Good to know, right?

Not Everything Is Roses

All this individual chassis naming sounds idyllic, but it comes at a price when it comes to network management. In true Network News style (“Coming up, we look at which TV programs could cause you to die unexpectedly”), I’ll post on that very shortly, but I won’t tell you exactly when, in order to keep you watching right to the end of the broadcast. Blogcast? Something like that.

Coming Next

I promised to explain the evil method I came up with to determine which chassis member you are consoled in to when you have only configured the global system host-name; and so I shall, in the next post. After reading it, maybe you’ll want to use the group configuration going forward, I promise.

Or maybe you won’t after I discuss some of the negatives of using group member names. What a tease I am. Stay tuned!

 

Do you have any other tips on naming or managing a Juniper EX virtual-chassis?