HI Team , i have a some questiones regarding the ospf virtual links. Topology is as below.
how can i communicate between Area0 and Area 3. do i need to create virutal link from ( B to C and C to D) or (B to C and B to D) ?
How many transit area's can be used in Virtual link ?
what type of LSA exchanged over Virtual link ?
Hi Sunil,
Virtual links are used to communicate an area with the backbone (area 0) through another area that has already a physical connection to the backbone. As you know, OSPF areas must be adjacent to area 0 to work.
In your scenario, Area 1 would be a transit area containing a virtual link for Area 2 to reach Area 0.
Here is what I have found on it:
"To configure an OSPF virtual link through an area, you specify the router ID (IP address) of the routing devices at each end of the virtual link. These routing devices must be area border routers (ABRs), with one that is physically connected to the backbone. "
Therefore, since Area 1 is the only one that is physically connected to the backbone, it would be the only area that can be used as a transit area for a virtual link. Area 3 would not be possible and a 0/0 route pointing to area 2 can be used instead.
I would expect to see LSA type 3 and type 4 for any ASBR on the network, since the Area 2 in this case will have the same routing database on OSPF as the rest of the domain.
Hi Experts
Is there any equivalent feature in Junos like cisco IPDT (IP Device tracking) ?
Thanks & Regards
Badar
Thank you all for your comments!
CORE3:
CORE3# run show configuration | display set | match stp
set protocols rstp interface ae0.0 mode point-to-point <--- ae0 was the trunk connecting CORE3 to CORE1
CORE3# run show spanning-tree bridge
STP bridge parameters
Context ID : 0
Enabled protocol : RSTP
Root ID : 4096.64:64:9b:1f:91:81
Root cost : 21000
Root port : ae4.0<-- trunk connecting CORE3 to CORE3-NEW (temporary solution until we move back the VOIP mirror ports to CORE3-NEW)
Hello time : 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Message age : 2
Number of topology changes : 339
Time since last topology change : 1467966 seconds
Topology change initiator : ae4.0
Topology change last recvd. from : 78:4f:9b:18:91:c2
Local parameters
Bridge ID : 32768.3c:8a:b0:e8:8b:41
CORE3# run show spanning-tree interface
Spanning tree interface parameters for instance 0
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ae4.0 128:5 128:7 32768.784f9b1891c2 20000 FWD ROOT
xe-0/0/24.0 128:537 128:537 32768.3c8ab0e88b41 200000 FWD DESG
xe-0/0/28.0 128:541 128:541 32768.3c8ab0e88b41 20000 FWD DESG
xe-0/1/2.0 128:563 128:563 32768.3c8ab0e88b41 2000 FWD DESG
xe-1/0/24.0 128:593 128:593 32768.3c8ab0e88b41 20000 FWD DESG
xe-1/1/2.0 128:619 128:619 32768.3c8ab0e88b41 2000 FWD DESG
CORE3-NEW:
CORE3-NEW# run show configuration | display set | match stp
set protocols rstp interface all
CORE3-NEW# run show spanning-tree bridge
STP bridge parameters
Routing instance name : GLOBAL
Context ID : 0
Enabled protocol : RSTP
Root ID : 4096.64:64:9b:1f:91:81
Root cost : 1000
Root port : ae0<--- trunk connecting CORE3-NEW to CORE1 (all vlans)
Hello time : 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Message age : 1
Number of topology changes : 35
Time since last topology change : 1452853 seconds
Local parameters
Bridge ID : 32768.78:4f:9b:18:91:c2
Extended system ID : 0
CORE3-NEW# run show spanning-tree interface
Spanning tree interface parameters for instance 0
Interface Port ID Designated Designated Port State Role
port ID bridge ID Cost
ae0 128:3 128:9 4096.64649b1f9181 1000 FWD ROOT
ae1 128:4 128:4 32768.784f9b1891c2 10000 FWD DESG
ae4 128:7 128:7 32768.784f9b1891c2 10000 FWD DESG
ae8 128:11 128:11 32768.784f9b1891c2 10000 FWD DESG
ae9 128:12 128:12 32768.784f9b1891c2 10000 FWD DESG
ae10 128:13 128:13 32768.784f9b1891c2 10000 FWD DESG
CORE3-NEW# run show spanning-tree statistics interface
Interface BPDUs BPDUs Next BPDU TCs Proposal Agreement
Sent Received Transmission Tx/Rx Tx/Rx Tx/Rx
ae0 12 772744 0 0/0 0/0 0/0
ae1 791803 19 0 0/0 0/0 0/0
ae4 781141 12 1 0/0 0/0 0/0
ae8 790094 0 0 0/0 0/0 0/0
ae9 769765 4 0 0/0 0/0 0/0
ae10 790036 0 1 0/0 0/0 0/0
ae11 789117 2 1 0/0 0/0 0/0
ae12 791858 0 1 0/0 0/0 0/0
ae13 791811 0 1 0/0 0/0 0/0
ae14 770779 0 1 0/0 0/0 0/0
ae15 770765 0 0 0/0 0/0 0/0
ae16 770827 0 0 0/0 0/0 0/0
ae17 770767 0 1 0/0 0/0 0/0
ae20 791766 75 1 0/0 0/0 0/0
CORE3-NEW# run show spanning-tree statistics bridge
STP Context : default
STP Instance : 0
Number of Root Bridge Changes: 43 Last Changed: Mon Apr 13 09:22:17 2020
Number of Root Port Changes: 29 Last Changed: Mon Apr 13 09:22:17 2020
Recent TC Received: ae0.0 Received : Mon Apr 13 13:58:17 2020
The "set protocols rstp interface ae0.0 mode point-to-point"config which was in use on CORE3 was not copied over to CORE3-NEW since this is the default configuration and doesn't need to be explicitly set on the QFX AFAIK.
While we had the flood/loop going on, we disabled each LACP interface 1 by 1 on CORE1 until ae8 (connecting CORE1 to CORE3-New) or aeXX connecting CORE1 to the UCS (don't remember which one) was found to be stopping the flood.
CORE1:
CORE1# run show configuration | display set | match stp set protocols rstp bridge-priority 4k set protocols rstp interface xe-0/1/0.0 edge set protocols rstp interface xe-0/1/1.0 edge set protocols rstp interface xe-0/1/2.0 edge set protocols rstp interface xe-0/1/3.0 edge set protocols rstp interface ae0.0 mode point-to-point <--- connecting CORE1 to CORE3-NEW set protocols rstp interface ae0.0 no-root-port set protocols rstp interface ae1.0 mode point-to-point set protocols rstp interface ae1.0 no-root-port set protocols rstp interface ae2.0 mode point-to-point set protocols rstp interface ae2.0 no-root-port set protocols rstp interface ae3.0 mode point-to-point set protocols rstp interface ae3.0 no-root-port set protocols rstp interface ae4.0 mode point-to-point set protocols rstp interface ae4.0 no-root-port set protocols rstp interface ae8.0 mode point-to-point set protocols rstp interface ae8.0 no-root-port set protocols rstp interface ae9.0 mode point-to-point set protocols rstp interface ae9.0 no-root-port set protocols rstp interface ae21.0 mode point-to-point set protocols rstp interface ae21.0 no-root-port set protocols rstp bpdu-block-on-edge
The thought of no-mac-learning configuration on CORE3-NEW to solve the issue was brought up by a vendor we work with, we havn't checked it yet. I am trying to understand exactly what happened and why before we start trying out things causing a downtime again.
@iNc0g - I thought you said said no-mac-learning "solved" your situation, not "The thought of no-mac-learning configuration on CORE3-NEW to solve the issue was brought up by a vendor we work with, we havn't checked it yet."
I extremely doubt that setting on mirrored output port would have any affect, especially for the situation you were reporting.
Good luck
Hello iNc0g,
So based in the outputs, it seems that core1 is the root bridge so all the ports must be forwarding, if that is the case, the trunk between core3-new and the UCS must be blocked, but based in the ouputs, it seems that everything is in forwarding. It sounds like the UCS device is not running rstp, so when you disabled the lacp interfaces you stopped the loop.
Could you check the UCS rstp configuration? If the UCS is the root bridge then the port between core3-new and core1 should be blocked.
If this solves your problem, please mark this post as "Accepted Solution".
Hi,
on CORE3-NEW, the 2 ports connected to UCS-A + UCS-B are access ports not trunk, members of VOIP vlan.
There is no rstp config on the cisco UCS.
I am still baffled about why this configuration works on CORE3 but causes a loop/flood on CORE3-NEW, no one seems to have an explanation for that, only theories about the solution.
Hi Ccarovich,
I suspect harddisk is missing in FPC2 which not allowing the commit to get complete.
kindly refer below KB and perform the suggested action.
https://kb.juniper.net/InfoCenter/index?page=content&id=KB27938&actp=METADATA
Please mark "accept as solution" if this answers your query. Kudos are appreciated too !
Regards
Nadeem
Hello iNc0g,
From what I see the switch is working as expected, forwarding the traffic. It would be good to compare the full configuration of both units to see if we are missing something.
Is the role of the ports going to the UCS's only to receive the mirrored traffic and forward it downstream, or they also send traffic upstream? As a WA, If the role is only to mirror the traffic, you can try to delete the vlan from the ports and leave them only with family ethernet-switching, that should keep the analyzer up and break the loop.
This is from a lab switch
{master:0}[edit]
root@R1# show interfaces xe-0/0/0
unit 0 {
family ethernet-switching;
}
{master:0}[edit]
root@R1# run show forwarding-options analyzer
Analyzer name : test
Mirror rate : 1
Maximum packet length : 0
State : up
Ingress monitored interfaces : xe-0/0/0.0
Egress monitored interfaces : xe-0/0/0.0
Output interface : xe-0/0/1.0
About the xSTP interfaces, the change you are seeing seems to be related to this KB33693 shared by jospina. In ELS devices (Core3-new) the interfaces-all is not implicit so it must be manually configured. Based in the output you have it in that way. In legacy, there is and implict all, so all the interfaces should be part of rstp by default, I guess you added ae0 later and manually add it, but it shouldn't make a difference.
CORE3-NEW# run show configuration | display set | match stp set protocols rstp interface all
Please let me know if it helps!
I have 36 cisco switches that needs to be migrated over to Juniper EX3400 VC. I know Juniper discontinue the migration tool they have on the web but I wish they still have it available or able to get offline copy. Is there a way or tool out there that to convert the Cisco config to Juniper config? I dont want to manually configure each ports on the Juniper EX3400 to match the Cisco configurations. I just need the cisco port configurations migrated over to Juniper and nothing else.
I might suggest you past your [single?] Cisco config here, and someone might be able to help. I've done this before, and the biggest pain (IMHO) is converting port numbering. Cisco starts with #1 as first number, while Juniper considers 0 a number. If anyone has an easy way/tool to just convert that part, would save you a bunch of time.
Now if every Juniper switch is going to have the same config, or same 90% config, might be easiest to just start from scratch and make config on Juniper via cli or jweb or SKY Ent.
Just FYI. Good luck.
Hi jonisccp,
Alternately try contacting your sales team and see if they can help, maybe they can access archived tools and might be of some help.
//Nexon
Hi, after upgrading to Junos 12.3R12-S14 on my EX 4200 switch I can not access the web-management anymore
junos version
> show version fpc0: -------------------------------------------------------------------------- Model: ex4200-48t JUNOS Base OS boot [12.3R12-S14] JUNOS Base OS Software Suite [12.3R12-S14] JUNOS Kernel Software Suite [12.3R12-S14] JUNOS Crypto Software Suite [12.3R12-S14] JUNOS Online Documentation [12.3R12-S14] JUNOS Enterprise Software Suite [12.3R12-S14] JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R12-S14] JUNOS Routing Software Suite [12.3R12-S14] JUNOS Web Management [12.3R12-S14] JUNOS FIPS mode utilities [12.3R12-S14]
log file
May 5 00:24:36 init: web-management (PID 4466) started
May 5 00:24:37 httpd-gk: WEB_CONFIG_OPEN_ERROR: Could not open '/jail/var/etc/httpd.conf' for writing May 5 00:24:37 httpd-gk: WEB_CONFIGURATION_UPDATE: Unable to read configuration during commit May 5 00:24:37 init: web-management (PID 4466) exited with status=1
system storage
> show system storage fpc0: -------------------------------------------------------------------------- Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 183M 130M 38M 78% / devfs 1.0K 1.0K 0B 100% /dev /dev/md0 69M 69M 0B 100% /packages/mnt/jbase /dev/md1 5.8M 1.1M 4.2M 21% /packages/mfs-fips-mode-powerpc /dev/md2 2.9M 2.9M 0B 100% /packages/mnt/fips-mode-powerpc-12.3R12-S14 /dev/md3 9.6M 5.0M 3.9M 56% /packages/mfs-jcrypto-ex /dev/md4 14M 14M 0B 100% /packages/mnt/jcrypto-ex-12.3R12-S14 /dev/md5 7.9M 3.3M 4.0M 46% /packages/mfs-jdocs-ex /dev/md6 6.0M 6.0M 0B 100% /packages/mnt/jdocs-ex-12.3R12-S14 /dev/md7 43M 39M 608K 99% /packages/mfs-jkernel-ex /dev/md8 109M 109M 0B 100% /packages/mnt/jkernel-ex-12.3R12-S14 /dev/md9 12M 7.5M 3.6M 68% /packages/mfs-jpfe-ex42x /dev/md10 21M 21M 0B 100% /packages/mnt/jpfe-ex42x-12.3R12-S14 /dev/md11 17M 12M 3.2M 79% /packages/mfs-jroute-ex /dev/md12 38M 38M 0B 100% /packages/mnt/jroute-ex-12.3R12-S14 /dev/md13 12M 7.2M 3.6M 67% /packages/mfs-jswitch-ex /dev/md14 21M 21M 0B 100% /packages/mnt/jswitch-ex-12.3R12-S14 /dev/md15 15M 10.0M 3.4M 75% /packages/mfs-jweb-ex /dev/md16 27M 27M 0B 100% /packages/mnt/jweb-ex-12.3R12-S14 /dev/da0s3e 123M 1.8M 111M 2% /var /dev/md17 252M 12K 232M 0% /tmp /dev/da0s3d 369M 26K 339M 0% /var/tmp /dev/da0s4d 62M 208K 57M 0% /config /dev/md18 118M 22M 87M 20% /var/rundb procfs 4.0K 4.0K 0B 100% /proc /var/tmp 369M 26K 339M 0% /packages/mnt/jweb-ex-12.3R12-S14/jail/var/tmp/uploads
nothing in /jail/var/etc
> start shell % cd /jail/var/etc % ls -al total 8 dr-xr-xr-x 2 root wheel 2048 Aug 22 2019 . dr-xr-xr-x 6 root wheel 2048 Aug 22 2019 ..
configuration
set system services web-management http port 80 set system services web-management http interface vlan.500
Apreciate any help.
Thanks,
Dan
Hi Ndanl,
This issue has been reported earlier where in upgrading to 12.3R12-S14 JWEB stops working.
If you want this feature work, upgrade the device 12.3R12-S15 or downgrade to 12.3R12-S12.
If this solves your problem, please mark this post as "Accepted Solution" so we can help others too 
Regards
Nadeem
I too have this issue on many of my EX2300 switch devices.
I see it on the devices that I have not upgraded yet.
JUNOS 15.1X53-D590.1 is see it
JUNOS 18.2R3-S2.9 does not have this issue.
I plan to upgrade but it will take time.
This command will remove/block it from the logs:
set system syslog file messages match "!(.*BRCM_SALM:brcm_salm_l2_addr_process_notif().*)"
But I would still like to know what it is referring to and if there is another way to stop it.
Hello Guillermo, All,
These messages are frequently seen on 15.1X code in EX2300 Virtual chassis.
These logs are debug messages and are reported when mac add failures are seen for remotely learned mac addresses, specifically the learn/delete process for remote MAC addresses.
The message basically means that the IFD is not found for the port, as at this time port is undergoing conversion.
These kinds of messages are informational and harmless.
Since they are for debug, there is no fix in order to eliminate these messages from Syslog
One possible way of dealing with these messages would be to filter them from the log file.
The instructions detailed in the article below will help you achieve this goal:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB9382&actp=METADATA&act=login
Command:-
set system syslog file messages match "!(.*BRCM_SALM:brcm_salm_l2_addr_process_notif().*)"
Please apply this filter and then monitor the behavior of the device.
I hope this helps. Please mark "Accept as solution" if this answers your query.
Kudos are appreciated too!
Best Regards,
Lingabasappa H
Good info. Is there a PR to get these messages hidden in a future release of SW?
Thanks
Hello Rccpgm,
Thanks for giving me kudos for the solution.
As of now, there is no PR that hides the above logs. If there is any PR raised for these logs, I will update the same on this thread.
As far as my understanding goes, these messages are not seen on the Recommended Version of EX2300.
In case if you don't wish to Apply the Syslog filter, upgrade the device to a stabilized and recommended version.
I hope this helps. Please mark "Accept as solution" if this answers your query.
Kudos are appreciated too!
Best Regards,
Lingabasappa H