In the continuing series of “Junos is just mockin’ me now” posts, here’s a recent Whiskey Tango from an EX4200 virtual-chassis running 12.2R2.4:
{master:0}[edit]
john@EX4200VC# load patch /var/tmp/change123
|
error: session failure: unexpected termination
error: remote side unexpectedly closed connection
Connection to EX4200VC closed.
[john@jumpbox:~]#
Uhhh… I loaded the patch, and was unceremoniously disconnected?
I’ve Been Dumped
It’s not clear to me what was going on here. Did Junos throw me out? Did ssh glitch somehow and was unhappy about something it received? I was able to reproduyce this repeatedly and consistently. Interestingly though (perhaps), the patch was actually loaded successfully. For me to know that the config was loaded means that my user session was not cleaned up and my config was not ditched.
Users Editing the Configuration
On reconnecting to the switch and going into configuration mode I was presented with an all too familiar warning:
{master:0}
john@EX4200VC> edit
Entering configuration mode
Users currently editing the configuration:
john terminal p0 (pid 60050) on since 2014-01-03 22:28:36 UTC, idle 00:00:48
{master:0}[edit]
The configuration has been changed but not committed
{master:0}[edit]
john@EX4200VC#
Joy. I was not only dumped out for some reason, but apparently my session is still hanging there. In case you don’t know, it’s fairly easy to fix this. Grab the pid from the listed session (in this case 60050) and issue this command:
{master:0}[edit]
john@EX4200VC# run request system logout pid 60050
{master:0}[edit]
john@EX4200VC#
Tadah, the dead session is gone.
When Is The Difference Between A Diff?
So I still have no idea what caused my SSH disconnection to happen. The patch file was valid (it was created on the switch itself). Once I had re-entered the configuration manually and committed it, I tried loading the patch again. This time I was not disconnected though. Although, with some amusement I did try loading it then doing a show | compare, and the pedantic accuracy of this diff can’t be ignored:
{master:0}[edit]
john@EX4200VC# show | compare
[edit interfaces ae0 unit 0 family ethernet-switching vlan]
- members [ vlan-30 vlan-10 vlan-31 ];
+ members [ vlan-31 vlan-30 vlan-10 ];
Yep, same VLANs, different order. Different. Can’t argue with that I suppose.
That’s all. Just thought I’d share my fun for the day.
Hey John, I know you did not receive a specific error other than being dropped but I would like to see you test this again. 🙂 prior to your load patch, try a commit full.
“A ‘commit’ (performed after configuration changes) checks only the corresponding daemons. However the ‘commit full’ action requires all the daemons to check and evaluate the new configuration. A ‘commit full’ is useful for if you get an error with commit or when you’ve changed the config significantly.”
FWIW, if adding vlans (or any other area that allows bracketed items), if you just add one like this:
set vlan members vlan-30
it will always put it at the end. If you want them in a specific order, you can always specify the bracketed order; like this:
set vlan members [ vlan-10 vlan-30 vlan-31 ]
However, if vlan-30 was already there, you will get the order like this:
[ vlan-30 vlan-10 vlan-31 ] ## since vlan-30 was already there…
if you need to reorder it, you could always wipe out all vlan members and then add it back as a bracketed order, which will take as given, or you could insert members vlan-10 before vlan-30 as the commonly accepted JUNOS reordering technique.
Cheers!
-=]NSG[=-
*nod* Good tips, thanks NSG.
In this case it’s slightly stranger – all three vlans were already in the configuration, so re-adding them should have not changed the order at all (like in your last example where the existing VLAN is untouched). I found it curious that while there was no net change, the order did change for some reason.