Also, that configuration that you are seeing for interface xe-1/0/1 is part of the factory default configuration on an EX switch. 

Hi Sergii,

Thanks for reply.

In line with your directions, I did further look at the case...

Master> show configuration system | display set | match traceoptions

set system processes dhcp-service traceoptions file dihescipi_logfile
set system processes dhcp-service traceoptions file size 10m
set system processes dhcp-service traceoptions level all
set system processes dhcp-service traceoptions flag all
set system processes app-engine-virtual-machine-management-service traceoptions level notice
set system processes app-engine-virtual-machine-management-service traceoptions flag all

Master> file list /var/log/*_log* detail
-rw-r----- 1 root wheel 7170715 Mar 15 13:07 /var/log/dihescipi_logfile
-rw-r----- 1 root wheel 796877 Mar 15 13:06 /var/log/dihescipi_logfile.0.gz
-rw-r----- 1 root wheel 787786 Mar 15 13:05 /var/log/dihescipi_logfile.1.gz

I have some qs to you:

Q1) Clearly this traceoption is still enabled.  How to make sure this traceoption is not working for any automation purpose before making it deactivated or delete.

Q2) I don't think so this file was created today (Mar 15) as last commited date 5 month ago but not related to this file at that time. So how to find when this traceoption file was created and who? (my applogy this file was not created previously! We don't know when and who created).  ">sh sys rollback compara 0 1" with this command, each time needs to performed until  commit 49 to see change conf that related to this traceoption file. This way is really spending waste of time. Is there a efficient way or scripting to figure out the case? If so, can you explain pls.

Q3) As this traceoption is still running, why we are not seeing any warning or error that says storage exceeding volume or many creating files ext as we are seeing one of the Juniper strong recommendations is disabling traceoption when it is not using or capturing the packet. 

Thx.

Hi Sarah, answers inline.

---

 wrote:

Hi everyone.

Let say we have  three switches  VC , SW1 is the master. SW1 has following JUNOS pacakages  in var/tmp folder:

jinstall-ex-2200-12.3R12.4-domestic-signed.tgz

jinstall-ex-2200-12.3R11.2-domestic-signed.tgz

 

SW is booted from jinstall-ex-2200-12.3R12.4-domestic-signed.tgz

If we use "Virtual-chassis auto-sw-update" without specifying particular JUNOS image, what software will be downloaded to a new member switch if there is mismatch of JUNOS?

#########################333

[ANS] Its better to specify the intended package-name to install with the auto-sw-update i.e.:

set virtual-chassis auto-sw-update package-name

 

2) I noticed when I uploaded JUNOS into var/tmp/ folder from my FTP server,  and reboot the EX 2200 Switch , the installtion pacakage is not retained in /var/tmp folder once the  sw is booted. Is there any we can retain the installation package in VAR/TMP folder on EX200 switch?

[ANS]  Clearing /var/tmp/ is default FreeBSD behavior.  This is for the safe operation of the device.  Yes it's possible to toggle this behavior for a particular file by marking the immutable bit, but you should manage it properly i.e. clear the bit when you don't need the file anymore.

 

start shell user root
chflags schg /var/tmp/<file name> -------------> Makes the file permanent/persistent over a reboot

 

Note that even root user won't be able to delete it.  For example:

root@Juniper-EX2200:RE:0% rm /var/tmp/jinstall-ex-4500-15.1R7.9-domestic.tgz
override rw-r--r-- root/field schg for /var/tmp/jinstall-ex-4500-15.1R7.9-domestic.tgz? no
root@Juniper-EX2200:RE:0% ls /var/tmp/jinstall-ex-4500-15.1R7.9-domestic.tgz
jinstall-ex-4500-15.1R7.9-domestic.tgz

 

To restore normal behavior (clear upon installation/reboot):

chflags noschg /var/tmp/<file name>
 

Other than this, think there's a cheat way of keeping the file if you make the filename start with a dot (.) , but I haven't tried that.

 

Thanks have a good day!!

 

 

---

Hope this helps.

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .

Hi Erdix,

Please see my answers inline.

---

 wrote:

Q1) Clearly this traceoption is still enabled.  How to make sure this traceoption is not working for any automation purpose before making it deactivated or delete.

[Sergii] The sole purpose of traceoptions is to give you more insight into what the process is doing, e.g. troubleshooting. Traceoptions are not used for anything else in JUNOS, so please feel free to deactivate or delete these lines.  In your case you should use:

delete processes dhcp-service traceoptions
delete system processes app-engine-virtual-machine-management-service traceoptions 

Q2) I don't think so this file was created today (Mar 15) as last commited date 5 month ago but not related to this file at that time. So how to find when this traceoption file was created and who? (my applogy this file was not created previously! We don't know when and who created).  ">sh sys rollback compara 0 1" with this command, each time needs to performed until  commit 49 to see change conf that related to this traceoption file. This way is really spending waste of time. Is there a efficient way or scripting to figure out the case? If so, can you explain pls.

[Sergii] If the process is idle, or not used in your configuration, it will not write anything into the trace logs. AFAIK there is no CLI command that can provide you with all configuration changes performed during last 50 commits, but a simple shell script will easily do it (I'll provide it below).

Q3) As this traceoption is still running, why we are not seeing any warning or error that says storage exceeding volume or many creating files ext as we are seeing one of the Juniper strong recommendations is disabling traceoption when it is not using or capturing the packet. 

[Sergii] Unfortunately, there is no such warning in JUNOS. I fully agree with the recommendation to disable traceoptions during normal operations because they might interfere with normal operation of the kernel and daemons (depending on the configuration). For example, you might see adjacencies timing out if you configure verbose trace logs for RPD on PE router with millions of routes, because you will force RPD to write all its activity to the disk which will slow it down. Traceoptions should only be enabled during troubleshooting and disabled when they're not needed anymore. Of course, another risk is that all available space will be consumed overtime (but most traceoptions allow you to configure number and size of log files).

---

This is the simple script that should do the job:

root@mx1:/var/tmp # cat chk.sh
#!/bin/bash
i=49
echo "================================"
echo "Checking system commit history"
echo "================================"
cli -c "show system commit | no-more"
while [ $i -ge 1 ]
do
    j=$(( i - 1 ))
    echo "================================"
    echo "Comparing commit #${i} and #${j}"
    echo "================================"
    cli -c "show system rollback compare ${i} ${j} | no-more | except \"Cannot open configuration file\""
    i=$j
done

root@mx1:/var/tmp # sh chk.sh
================================
Checking system commit history
================================
0   2019-03-14 13:21:11 CET by root via cli
1   2019-03-11 10:27:41 CET by regress via cli
================================
Comparing commit #49 and #48
================================
[...]
================================
Comparing commit #1 and #0
================================
[edit protocols isis]
+    traceoptions {
+        file isis.log;
+    }
root@mx1:/var/tmp #

Best regards,

Sergii

----------------------------------------------------------------------------------------

Please mark this post as "Accepted solution" if your problem is resolved

----------------------------------------------------------------------------------------

Hi Sarah,

As far as I understand the EX will not upgrade the new member to match the Version of  the VC, that should be a manual step:

..."For a standalone EX4200 switch to join an existing Virtual Chassis configuration, it must be running the same version of Junos OS that is running on the Virtual Chassis master. If the software version on the new switch is not the same as the version running on the master, the master keeps the new switch in the inactive state"...

Source: https://www.juniper.net/documentation/en_US/junos/topics/example/virtual-chassis-ex4200-software-automatic-update.html 

As for your next question, from shell you can change the permissions of the file and set the "Inmutable flag" with chmod like this:

root@switch% pwd
/var/tmp
root@switch% ls -l -o
total 32
drwxr-xr-x 2 root wheel - 512 Dec 31 07:40 .schema-cache
-rw-r--r-- 1 root field - 2158 Dec 28 07:00 JJJJJJJ
drwxr-xr-x 2 root field - 512 Dec 28 06:57 gres-tp
drwxrwxrwx 2 root wheel - 512 Dec 28 06:57 install
drwxrwxrwx 2 root wheel - 512 Dec 28 06:57 pics
drwxr-xr-x 2 root field - 512 Dec 28 06:58 rtsdb
drwxrwxrwt 2 root wheel - 512 Dec 28 06:57 vi.recover

root@switch% chflags simmutable JJJJJJJ
root@switch% ls -l -o
total 32
drwxr-xr-x 2 root wheel - 512 Dec 31 07:40 .schema-cache
-rw-r--r-- 1 root field schg 2158 Dec 28 07:00 JJJJJJJ
drwxr-xr-x 2 root field - 512 Dec 28 06:57 gres-tp
drwxrwxrwx 2 root wheel - 512 Dec 28 06:57 install
drwxrwxrwx 2 root wheel - 512 Dec 28 06:57 pics
drwxr-xr-x 2 root field - 512 Dec 28 06:58 rtsdb
drwxrwxrwt 2 root wheel - 512 Dec 28 06:57 vi.recover

then remove it with chflags nosimmutable 

hope it helps!

Hi Erdix,

to verify the control traffic on the child interface you can actually do a monitor traffic interface of the link in this example you can see some lldp I see arps as well if I leave it long enough:

root@switch# run show interfaces terse | match ae
ge-0/0/0.0 up up aenet --> ae0.0
ge-0/0/1.0 up up aenet --> ae1.0
ge-1/0/0.0 up up aenet --> ae0.0
ge-1/0/1.0 up up aenet --> ae1.0

root@switch# run monitor traffic interface ge-0/0/0 size 1500
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-0/0/0, capture size 96 bytes

12:51:04.046298 In LLDP, name SRX345-0.ultralab.juniper.net, length 60
12:51:07.103351 Out LLDP, name d11-31, length 60
[|LLDP]

Hi Sergii,

Thanks for answers...I got your point.

Another thing that I like to ask is about your previous script is for on the box, isn't it? I like to do same thing via pyhton script remotely like what your shell script does. For instance, when running a pyhton script on my laptop, first it should be connected to the box (Virtual Chassis) over SSH/netconf and executing the commands and bringing all output into my laptop? Is this practible? If so,  could I please ask you about you have a working simlple pyhton script for achieving this task?

Thanks, 

Hello Erdix,

Yes, this script is supposed to be run on the box, and, unfortunately, I don't have a Python script for your task handy. I hope that your original problem is resolved, and I'll recommend asking your question regarding the Python script in the Automation section. It's more appropriate place for such questions and scripts.

Best regards,

Sergii

----------------------------------------------------------------------------------------

Please mark this post as "Accepted solution" if your problem is resolved

----------------------------------------------------------------------------------------

Hi Erdix.

---

 wrote:

Hi Sergii,

Thanks for answers...I got your point.

 

Another thing that I like to ask is about your previous script is for on the box, isn't it? I like to do same thing via pyhton script remotely like what your shell script does. For instance, when running a pyhton script on my laptop, first it should be connected to the box (Virtual Chassis) over SSH/netconf and executing the commands and bringing all output into my laptop? Is this practible? If so,  could I please ask you about you have a working simlple pyhton script for achieving this task?

 

Thanks, 

 

---

I have transformed the Sergii's shell script to Python script. See the code snippet below. The same is attached in ZIP file.

mat@ubuntu-autom:~/python$ cat chk.py
#!/usr/bin/python3
# import needed libraries
import sys
import re
from getpass import getpass
from jnpr.junos import Device
from jnpr.junos.exception import RpcError
from lxml import etree

# Get device details from user
hostname = input("Device hostname: ")
username = input("Device username: ")
password = getpass("Device password: ")
rollbacks = input("Starting rollback: ")

# initialize rollback number index with input from user
i=int(rollbacks)
print("==============================")
print("Checking system commit history")
print("==============================")
# create new device instance
dev=Device(host=hostname, user=username, passwd=password)
#open connection to device
dev.open()
# get information about commits "show system commit" via RPC and convert to string
commit_info=etree.tostring(dev.rpc.get_commit_information({'format':'text'}), encoding='unicode')
# trim unneeded tags and print the commit information
print(re.sub('<output>\n|\n</output>', "", commit_info))
# cycle through rollbacks until we compare rollback 1 and 0
while i >= 1:
   #secondary index
   j=i-1
   # print infor about rollback versions we want to compare at this iteration step
   print("==============================")
   print("Comparing commit #%d and #%d" % (i, j))
   print("==============================")
   # try to get rollback compare , try is to catch error when user inputs rollback value > 49
   try:
      #  get "show system rollback compare i j" via RPC as type "lxml.etree._Element"
      cmpr=dev.rpc.get_rollback_information({'format':'text'}, compare=str(i), rollback=str(j))
      # if rollback number is <= 49  but doesn't exist on device, the bool value is returned
      if isinstance(cmpr, bool):
         # inform user the rollback #i doesn't exist
         print("Rollback number #%d does not exist." % i)
      # else we have valid output from RPC
      else:
         # convert the output to string
         cmpr_str=etree.tostring(cmpr,encoding='unicode')
         #trim unneeded tags and print the rollback difference information
         print(re.sub(r'<rpc.*\">\n|</rpc-reply>', "", cmpr_str))
   # error caught - rollback number was >  49
   except RpcError as err:
      # print error message
      print ("Unable to retrieve rollback compare: {0}".format(err))
   # decrease rollback index
   i=i-1
# close connection to device
dev.close()

I tested script using Python3 on Ubuntu VM against QFX5100 Virtual Chassis  and SRX100 single node . The ouput from QFX5100 VC is following ( output truncated):

mat@ubuntu-autom:~/python$ python3 chk.py
Device hostname: QFX
Device username: mat
Device password:
Starting rollback: 49
==============================
Checking system commit history
==============================
0   2019-03-04 11:33:47 UTC by mat via cli commit synchronize
1   2019-03-04 11:32:22 UTC by mat via cli commit synchronize
2   2019-03-04 11:11:14 UTC by mat via cli commit synchronize<omitted for brevity>
==============================
Comparing commit #49 and #48
==============================
[edit interfaces]
+   xe-1/0/3 {
+       flexible-vlan-tagging;
+       encapsulation extended-vlan-bridge;
+       unit 400 {
+           vlan-id 400;
+       }
+   }
[edit vlans 351869bd-e8b9-36ad-9e30-90bd173f600d]
+    interface xe-1/0/3.400;<omitted for brevity>
==============================
Comparing commit #1 and #0
==============================
[edit interfaces ge-1/0/36 unit 0 family inet]
+       filter {
+           input VYPADEK-BKP;
+           output VYPADEK-BKP;
+       }

There is built-in some elementary error handling related to rollback number in the script.

OS and library versions:  Ubuntu 18.04.1 LTS, Python 3.6.7,  PyEZ 2.2.0 , lxml 4.3.2

Many thanks at @Sergii for initial script and all the replies.

Let us know if it helped.

Hello,

Hardware and software in question:

Juniper:

hardware: EX4300-48MP (multigigabit)

Junos ver: 18.3R1.9

Cisco:

Hardware: Catalyst 4300X-16 port in virtual stack (VSS) that consists of two units

Ios ver: 15.0(1r)SG10

Issue:

I've setup LAG 10g interfaces (4 ports) but when I enable ports on both sides, on juniper all ports are no longer accessible. Weird part(s):

- the management interface is inaccessible event though it shows in junos cli  "up" status. All 4 10g ports are also showing up status and indicator led on the hardware is showing active/green light.

- On Cisco side is the same story. All 4 ports are showing connected, including ether-channel and also, indicator led on the hardware is showing active/green light.

Relevant ports configuration on Juniper:

============================

xe-0/2/0 {
ether-options {
802.3ad ae1;
}
}
xe-0/2/1 {
ether-options {
802.3ad ae1;
}
}
xe-0/2/2 {
ether-options {
802.3ad ae1;
}
}
xe-0/2/3 {
ether-options {
802.3ad ae1;
}
}
ae1 {
description "LAG to Cisco";
aggregated-ether-options {
lacp {
active;

================================================

Relevant Cisco configuration:

================================================

interface Port-channel111
description HR SRV RM
switchport
switchport mode trunk

!

interface TenGigabitEthernet1/1/5
description HR Jun4300 Link 1
switchport mode trunk
channel-group 111 mode active
!
interface TenGigabitEthernet1/1/6
description HR Jun4300 Link 2
switchport mode trunk
channel-group 111 mode active

!

interface TenGigabitEthernet2/1/13
description HR Jun4300 Link 3
switchport mode trunk
channel-group 111 mode active
!
interface TenGigabitEthernet2/1/14
description HR Jun4300 Link 4
switchport mode trunk
channel-group 111 mode active

============================================================

Any suggestion would be greatly appreciated.

I think you have missed to define your ae1 interface as a switchport with tagged vlans - at least your configuration doesn't show.

Something like this to allow all vlans on the trunk:

set interfaces ae1.0 family ethernet-swithing interface-mode trunk

set interfaces ae1.0 family ethernet-swithing vlan members all

Let us know if this resolves your issue.

Hi Jonas and thank you for the reply.

It is defined but in my haste, I neglected to copy entire config for the interface:

=======================

ae1 {
description "LAG to Cisco";
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ default all ];
}

======================

Regards,

T

I suspect that you definition of both vlan members default and all makes an error. I will suggest to remove vlan default:

delete interfaces ae1.0 family ethernet-switching vlan members defaults

If it still doesn't work, please provide the following output from the Juniper switch. You can obfuscate vlan names if needed.

show ethernet-switching interface ae1

show spanning-tree interface ae1

show ethernet-switching table interface ae1.0

I've attached the command output and sorry for formatting which is not that great.

Thank you!

T

Everything looks OK as mac addresses are learned on the different vlans and STP is forwarding.

Another guess from here: is your management of the EX switch placed on the default vlan? If yes, then you need to define native-vlan on ae1 as Cisco per default sends vlan 1 untagged via trunk links and juniper puts a tag on everything.

Native vlan is configured like this:

set interfaces ae1 native-vlan-id 1

If this is a wrong guess, please test if you can configure a random access port with VLAN2 (vlan tag 20) and see if you can see the mac address of your test host on the Cisco switches. 'show mac-address table vlan 20 | i Po111' or similar - my Cisco-foo is very rusty :-)

Hi Yasmin,

Thank you for your reply and sorry for the late response.

The configuration file does not show existing interfaces automatically

---

I am using a qfx5100-48s-6q which accept SFP transciever. Do you mean if i insert a SFP transciever into the slot, the configuration will not show it automatically ?

---

There is no command that will allow you to do that quickly; you would need to delete those interfaces from the configuration with the delete command.

Does that mean i will have to go to operation mode, do a "show interface terse" to see the actual interfaces, then match it against the configuration ?

Regards,

Alan

Hi Mriyaz,

Thank you for your reply.

---

Simply "delete" from the config mode (#) will remove all hierarchies, then you may key in the necessary configuration.

But these also means all my actual usable configurations will be gone as well ?

Regards,

Alan

---

 wrote:

Hi Mriyaz,

 

Thank you for your reply.

 

---

Simply "delete" from the config mode (#) will remove all hierarchies, then you may key in the necessary configuration.

But these also means all my actual usable configurations will be gone as well ?

 

Regards,

Alan

---

---

 wrote:

Hi Mriyaz,

 

Thank you for your reply.

 

---

Simply "delete" from the config mode (#) will remove all hierarchies, then you may key in the necessary configuration.

But these also means all my actual usable configurations will be gone as well ?

[Ans] Yes, that is correct.  You can selectively delete part of the configuration to an extent using the right hierarchy i.e. if you did a delete from "edit interfaces" hierarchy, that clears all configuration of all interfaces.  Then you'll need to key in the desired interfaces' configuration prior to committing the changes

 

In a sense, this is best useful when configuring the device afresh.  

 

Using delete on interface hierarchy:

{master:0}[edit]
labroot@simicacd01h# edit interfaces

{master:0}[edit interfaces]
labroot@simicacd01h# delete
Delete everything under this level? [yes,no] (no) yes

{master:0}[edit interfaces]
labroot@simicacd01h# show | compare
[edit interfaces]
- et-0/0/0 {
- unit 0 {
- family ethernet-switching {
- storm-control default;
- }
- }
- }
- sxe-0/0/0 {
- unit 0 {
- family ethernet-switching {
- storm-control default;
- }
- }
- }
- xe-0/0/0:0 {
- flexible-vlan-tagging;
- mtu 9192;
- encapsulation flexible-ethernet-services;
- unit 0 {
- vlan-id 1;
- family inet {
- mtu 1500;
- address 11.0.0.2/24;
- }
- family iso;
- family inet6 {
- mtu 1500;
- address 2001:558:22:8209::2/64;
- }
- }
- unit 100 {
- vlan-id 100;
- family inet {
- address 12.0.0.2/24;
- }
- family inet6 {
- address 2001:559:22:8209::2/64;
- }
- }
- }
- xe-0/0/0:1 {
- disable;
- mtu 9192;
- unit 0 {
- family inet {
- address 22.0.0.2/24;
- }
- family iso;
- family inet6 {
- address 2001:558:22:8208::2/64;
- }
- }
- }
- et-0/0/1 {
- unit 0 {
- family ethernet-switching {
- storm-control default;
- }

 

 

Regards,

Alan

---

Hope this helps.

Regards,
-r.

--------------------------------------------------

If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .

Hi Both,

How do we actually know which interfaces/logical units are system-generated and can be ignored ? Is there any documentation for this ?

E.g. I got this em2 interface that is up with logical unit 32768 (even higher then 32767)  and it has an IP assigned .

But i cannot find this interface in my configuration.

admin> show interfaces terse

em2 up up
em2.32768 up up inet 192.168.1.3/24

Any idea how/can i remove this ? How do i even disable this interface ?

I am using qfx5100-48s-6q

Regards,

Alan

Hi Alan,

em2 used exclusevely for communication between two Junos VMs, for example for control-plane protocols - NRS, NSB, GRES.

There is no need to remove or disable this interface.

Regards,

Roman