I mentioned before that I would cover a way to determine which EX chassis console you were connected to within an EX virtual-chassis, even if you didn’t have individual member host-names, or have not implemented the great solution suggested by NetworkSecurityGuy over on The Art of Netjitsu.
Chances are you’d probably never want to have to do this, but the exercise of reverse-engineering what was going on was interesting for me, so as much as anything this is a way to document what I found so I never have to do it again. And perhaps at some point in the future somebody else will wonder about the same thing and this will be a useful resource, because when I searched the Internet I was unable to find any pages that contained this information.
Quick Recap
To set the scene, the problem I was trying to solve was how to know which member of a Juniper EX virtual-chassis (VC) you had consoled into, given that when you connect to the console port, as soon as you enter a username your session is redirected to the Master routing-engine.
The first “trick” to knowing which member you are physically connected to is that when you login on the master switch, you do not see “Logging to Master” as part of your output. Once logged in, you will see the prompt confirming which member switch number you are connected to, and stating that it’s the master.
So the problem I was left with was for the non-master switches how could you identify the source?
Reverse Engineering
My guess was that the console redirection would have to be an IP connection between the non-master member and the member, and the logical place for that to occur would be on the inter-chassis connections within the VC. Those connections show up as interface bme0 in the CLI, and there are number of units (sub interfaces) configured on each switch.
{master:0}
john@vcsw01> show interfaces bme0 terse
Interface Admin Link Proto Local Remote
bme0 up up
bme0.32768 up up inet 128.0.0.1/2
128.0.0.16/2
128.0.0.32/2
tnp 0x11
bme0.32769 down up eth-switch
bme0.32771 down up eth-switch
So how can we see what connections exist to interface bme0? Well, the first thing to note is that the IP addresses are in the 128.0.0.x range. Clearly they’re not really in the inet.0 routing table, otherwise a huge chunk of the Internet would be unavailable when traffic was routed through the switch, but nonetheless those are the IPs in use, so that gives us something to look for. Thankfully there’s a way to see all the system connections on a Juniper switch, and that’s show system connections:
{master:0}
john@vcsw01> show system connections
fpc0:
-------------------------------------------------------
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 128.0.0.16.38 128.0.0.1.52362 ESTABLISHED
tcp4 0 0 128.0.0.16.58286 128.0.0.1.6234 ESTABLISHED
tcp4 0 0 128.0.0.32.16123 128.0.0.16.58284 ESTABLISHED
tcp4 0 0 128.0.0.16.58284 128.0.0.32.16123 ESTABLISHED
tcp4 0 0 *.6023 *.* LISTEN
tcp4 0 0 *.6023 *.* LISTEN
tcp4 0 0 128.0.0.16.58283 128.0.0.1.6234 ESTABLISHED
tcp4 0 0 *.6022 *.* LISTEN
tcp4 0 0 128.0.0.16.58278 128.0.0.1.6343 ESTABLISHED
tcp4 0 0 128.0.0.16.58275 128.0.0.1.6011 ESTABLISHED
[...]
udp4 0 0 *.161 *.*
udp4 0 0 *.56234 *.*
udp4 0 0 *.6123 *.*
udp4 0 0 *.6123 *.*
udp4 0 0 *.7334 *.*
udp4 0 0 *.6333 *.*
fpc1:
-------------------------------------------------------
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 128.0.0.17.38 128.0.0.17.49353 ESTABLISHED
tcp4 0 0 128.0.0.17.49353 128.0.0.17.38 ESTABLISHED
tcp4 0 0 10.196.244.11.22 10.196.240.7.2707 ESTABLISHED
tcp4 0 0 128.0.0.1.6234 128.0.0.16.58286 ESTABLISHED
[...]
Even though I’ve heavily truncated the command output, it still generates an awful lot of information, so how am I going to tell which one might be a console connection? First, we should filter to connections that show ESTABLISHED, as nothing else is relevant. Beyond that, the process turns out to be a little hit and miss. What I tried to do initially was to view the connections when I didn’t have a console connection to a non-master switch, then connect on a non-master switch console and grab the connection list again. Then I ran a diff between the two. It turns out that the connections between the switches are in a constant state of flux, and the diff was showing that almost every connection had changed between the two grabs I executed. At that point, I grabbed a few more connection lists and visually compared them. Since the inter-chassis communication was constantly opening and closing sessions on different ports, what I’m looking for is something that doesn’t change between these grabs. A little eyeballing and I noticed that connections to port tcp/513 appeared to be constant. I killed my console connection, and the tcp/513 connection disappeared; connect again and the tcp/513 connection came back. So now I know that on a Juniper EX virtual-chassis, the redirected console connection is initiated by the non-master switch to the master switch on the bme0 interface on port tcp/513. I can use that information to figure out what connection has been made, and thus which member switch made the connection – but to decode that I need to know the IPs on each switch’s bme0 interface.
Grabbing the IPs
Login to the master switch, and do:
show interfaces bme0 terse
Write down the IPs assigned to the bme0 interface. Now we need to go to the other VC member switches. Assuming the master is member 0 (in this example), and there are also a member 1 and member 2 switch, we will need to log into the other members and grab their IPs as well. You can initiate a session to the other switches like this:
request session member 1
You can’t do much on the other switches because they are not the master, but what you can do is to repeat the show int bme0 terse command, and note down the IPs for each member.
Once you’ve done that for all member switches, you’ll have a list of all the IPs (or at least, the last octet of the IP address) and which switch they exist on:
Member |
IP1 |
IP2 |
IP3 |
|---|---|---|---|
0 |
1 |
16 |
32 |
1 |
6 |
7 |
32 |
2 |
18 |
32 |
In my case, I found that all three switches had a unit with the IP address 128.0.0.32, so it’s a fair assumption that since that IP is not unique, you can safely ignore it as it won’t be a destination for the console connection.
I have not done enough testing yet to know whether there is a consistent relationship between member number and IP addressing. If I find out, I’ll update the post to say so.
Putting It Together
Now all we have to do is to link the connections on tcp/513 to the IPs on the chassis. Make sure that you have a connection to the master switch, and that nobody is connected on a console. Connect to the first non-master console port and log in. We’ll check for connections on port 513:
show system connections | match EST | match \.513
With any luck, you’ll see the two sides of the console connection showing up (one from the originating member, and one from the master which is the endpoint for the connection). For example:
tcp4 0 0 128.0.0.1.513 128.0.0.6.1014 ESTABLISHED
tcp4 0 0 128.0.0.6.1014 128.0.0.1.513 ESTABLISHED
The IP address ending with .513 is the destination for the session – that is, the master chassis’ IP address – and we don’t care about this because we already know which is the master. So look at the other end of that connection (128.0.0.6.1014), and we can see that the session to the master was initiated by 128.0.0.6, which – by looking at our handy dandy table of bme0 information – we can identify as being member 1. So now we know that while our session is active on member 0 (master), the physical console we are connected to is for member 1. For completeness, repeat your test by logging in to the remaining members and checking the system connections and you will have complete confirmation of your connectivity.
Is This Useful?
Would I like to do this every day? Absolutely not. But in a squeeze when I really need the information, this is a neat way to get the end information without having to make a configuration change. As I said in a previous post though, how often do you need to do this? The geek in me says that I definitely would like to know which chassis I am connected to; the common sense in me suggests that it’s overkill.
Ideal Solution
The “best of both worlds” solution would appear to be to integrate a single global host-name for the VC so that LLDP and SNMP are happy bunnies, then follow NetworkSecurityGuy’s suggestion and configure unique pre-login and post-login banners for each member using the group member configuration. Geek satisfied, and NMS satisfied; that’s the power of the Internet right there!
But isn’t it nice to know how to find those internal console connections now?
No?
Yeah ok, I hear you. But now you have a secret nugget of information; the sort of thing you can whip out at geek parties in order to win the respect of your friends.
The geek ones, that is. The other ones will shun you, but I’m guessing you’re used to that by now.
Have a great day!
Leave a Reply