In my previous post I mentioned that there might be some reasons why having individual hostnames on Juniper EX virtual-chassis members might cause some issues for you. In this (short!) post, I’ll outline a couple of the implications.
SNMP Management
When you poll a Juniper EX Virtual-Chassis the sysName element returned will be that of whichever routing-enginer is master at the time of the poll. Implementing individual member host-names means that while initially a VC might identify itself as vcsw01a, after a routing-engine failover, it might identify itself instead as vcsw01b. This could potentially cause havoc with your network management systems, to say the least. I don’t believe it’s possible to poll each member individually; after all, the control plane responds to the polling, and the control plane can only be active on one switch at at time (the master). Sounds like a mess.
LLDP
If you happen to monitor LLDP neighbors, a routing-engine switchover will also change the hostname advertised in LLDP if each member has its own name. At the very least it adds a layer of confusion to topology discovery tools.
That said, one advantage might be that by looking at LLDP neighbors you can see which switch has the active routing-engine, as that’s the one showing up in the neighbor table!
The VC Concept
So why, then, does Junos even allow individual chassis naming? My initial reaction was “Well of course you want to do that” – but then when you look more closely at the things it can affect, I start wondering what the real benefits are. Initially, this came up because we wanted to confirm for sure which console port was connecting to which member switch, as part of a network audit. But beyond that narrow requirement, in reality do you ever need to know which member you’re connecting to?
The Virtual-Chassis concept is that you manage multiple switches as if they were one. On that basis, I believe that Juniper’s idea is that most people would probably only connect a single console cable to the VC device rather than one console cable to each member. Connecting to the console port on a non-master switch connects you right back to the master – because that’s where the control plane is. If it’s one switch, surely it should have one name?
Workarounds?
You can solve the SNMP sysName problem by manually coding the value the router should use in SNMP for sysName:
set snmp name vcsw01
It’s one more thing to configure, but it should solve that management problem. In other words, deploying individual member host-names should also go hand in hand with deploying a sysName override. Predictably this setting does not impact LLDP though.
But Then…
If I do decide to use a single (global) host-name for the Virtual-Chassis, I can no longer figure out which physical switch I’m attached to for the purposes of my console port audit. What will I do?
Well NetworkSecurityGuy (Joel) over at The Art of Netjitsu told me about a great solution that he came up with, and by happy coincidence he just posted about it. The gist of it – and you must read his post for the full details – is that not only can you define the host-name on a per-member basis via the group configuration, but you can also set a pre- and post-login banner per member, in which the switches can identify themselves. Thus when login, you will see which host you logged into and which host you ended up connecting to. Very clever stuff – good lateral thinking from Joel there, and it allows us to keep a single hostname for the cluster, which keeps the NMS folks happier.
Meanwhile I also promised a (somewhat absurd) solution to the “which chassis am I connected to” problem, and that’s coming next you lucky lucky things. Excited? Don’t worry, the solution will knock that right out of you 😉
Which do you think is better, a single hostname or individual member hostnames?
Leave a Reply