Hi,
Please attach the log messages prior to the disconnection, they may give some insight on what was happening prior to the disconnection with FPC2. Did you observe any crash file for FPC2? You can see if any has been created with a show system core-dumps.
Hi Jonas,
I have gone through your reply, it is pretty useful for me.
I would like to try to build a layer 2 network without STP to achive sub-second failover and would like to use ERPS and MC-LAG. I have attached my topology herewith, would you please have a look of and let me know if this topology works.
Thank you,
Laxman Bhandari
Hi all,
Is there any way to avoid the console port initial config for a EX4600? The manual just shows how to do the initial config using the console port.
Juniper provide a RJ-45 to DB-9 console cable which is not useful if you have a new laptop without that kind of port.
Thank you!
Hi,
Console is the only way to do the initial config on the devie. The devie by default does not have any IP or services enabled on the device for telnet/ssh and hence this needs to be configured via console.
Regarding the console port access from the newer laptops, as they miss the DB9 male ports and Juniper provides the RJ-45 to DB-9 adaptor. One way around this is to get a USB to DB-9 male adapator and use it in combination with the RS-45 to DB9 female adaptor.
Or probably if you are having many more devices with the similar requirement, you can consider Airconsole to connect to console over wireless. Easy to connect via any device i.e. Mobile, Laptop remotely without plugging anything extra.
https://www.get-console.com/shop/en/27-airconsole
Hope this helps.
Thanks and Regards,
Pradeep Kumar M
|| If this solves your problem, please mark this post as "Accepted Solution" so we can help others too ||
One addition to Pradeep's answer, this is one example of the cable you need to connect to the device by console:
Just google for "usb db9 adapter", and you find lots if different vendors and cables.
Thank you Pradeep and F1ght3r! I have bought a male adaptor as suggested.
So a follow up. Turns out to be two bad cat6a patch cables causing this issue.
Running a network testing tool on them didn't show any problems, but when replaced I got it working without disconnects.
Regards, J
Hello,
We have the following topology:
CORE3 = EX4550-32T, 12.3R6.6
CORE3-New = QFX5100, 18.1R3-S7.1
CORE1 = EX4550-32F, 12.3R6.6
CORE3 config:
set forwarding-options analyzer VOIP input ingress interface xe-1/0/24.0 set forwarding-options analyzer VOIP input ingress interface xe-0/0/24.0 set forwarding-options analyzer VOIP input ingress interface xe-1/1/2.0 <--- UCS-B, P.25 set forwarding-options analyzer VOIP input ingress interface xe-0/1/2.0 <--- UCS-A, P.25 set forwarding-options analyzer VOIP input egress interface xe-1/0/24.0 set forwarding-options analyzer VOIP input egress interface xe-0/0/24.0 set forwarding-options analyzer VOIP input egress interface xe-1/1/2.0 <--- UCS-B, P.25 set forwarding-options analyzer VOIP input egress interface xe-0/1/2.0 <--- UCS-A, P.25 set forwarding-options analyzer VOIP output interface xe-0/0/27.0 <--- Recording Server (Output Mirror)
Above topology works on CORE3.
When we moved this topology and cables to a new switch "CORE3-New" , network got flooded, loss of pings, freezing of some switches, intermittent connectivity.
We then deactivated the analyzer on CORE3-New:
deactivate forwarding-options analyzer VOIP
but still the same behavior.
The solution *seems* to be configuring no-mac-learning on the mirror ports on the CORE3-New, we haven't tried that yet.
Currently we had to rollback and move the mirror ports to the old switch CORE3 and everything works again.
What is the difference between CORE3 and CORE3-New that might cause this behavior?
The configuration is the same, no-mac-learning is not configured on CORE3 and still everything works.
Any ideas?
Hi,
first of all - next time please create a new thread to avoid discussing several issues on top of each other. Makes it easier for people to search for the right information later on instead of looong threads :-)
For your question; I think you will have problems with this design as ERPS relies on defining east/west physical interfaces and link-down on each of these will trigger a notification for the other members of the ring. With MC-LAG you create a aggregated ethernet link with at least two physical ports between your QFX switches to avoid have the inter-chassis-link down at any time. This design works against the ERPS design.
Furthermore ERPS is not supported on QFX5000 series or EX4600 in virtual chassis - so doing a virtual chassis per site and then ERPS between the VC's won't be an option either. I suggest this isn't supported due to the architecture with a Junos RE VM running on-top of the physical hardware with a risk of too high latency in ERPS keep alive/notifications.
Only viable design I can think of with the proposed hardware and physical design, would be to have layer3 links betweens each site and then do your stretched layer2 via EVPN-VXLAN. Requires licenses on the QFX5110's and quite more configuration on each switch.. but it would do the job.
@iNc0g there are difference in operation between older (often referred to as Legacy - now all EOL'd) products and newer, as they use different internal ASICs. Older/Legacy are Marvell based, while new are Broadcom (or Juniper) based.
This (no-mac-learning with mirroring) looks to be something different between these [somewhat equivalent] products. I am sure this behavior of the QFX5100 also equally would apply to EX4600.
FYI only. HTH
Hello,
wrote:
We then deactivated the analyzer on CORE3-New:
deactivate forwarding-options analyzer VOIPbut still the same behavior.
While I don't have a solution for this particular problem, did You actually attempt break Your triangle topology to quell the flood while QFX was in place?
L2 frames have no TTL and can be circulated indefinitely - You need to logically break the loop to stop L2 flood,
Which You did when put old EX back in, and then You probably start thinking that QFX somehow loops frames even without analyzer enabled.
wrote:
The solution *seems* to be configuring no-mac-learning on the mirror ports on the CORE3-New, we haven't tried that yet.
Just wondering where this piece of advice comes from? Is it from JTAC or from some yet-unnamed source You found on the wider internet?
HTH
Thx
Alex
Hello iNc0g,
Since you are migrating from EX4550 (legacy), to QFX5100 (ELS), did you make sure that all the configuration was updated to ELS style?
Also, if the packets that the switch is receiving via xe-1/1/2/xe-0/1/2 have a destination mac learned through the trunk to core1 it is expected for the switch to forward that traffic, even if there is no dest mac the switch will simply flood the traffic throught the vlan, it will be the same behavior if you remove mac learning.
Based in the diagram, you have the voice vlan in all the trunks, what loop prevention feature you have configured?
If this solves your problem, please mark this post as "Accepted Solution".
Hi,
Since you are moving to ELS and QFX in particular, please make sure this is not a loop caused by RSTP, whic differs from EX and Legacy. Here is a KB that explains the differences: https://kb.juniper.net/InfoCenter/index?page=content&id=KB33693&actp=METADATA
I just wanted to make sure this is not a loop caused by the lack of the interfaces not being explicitly called under RSTP as a first step and also since the config is not completely there. I would request you to add the STP interface status to this thread as it might help identifying the underlying issue.
wrote: Hi,
Please choose .qcow instead qcow2.
Thanks
Hello!
Thank you for suggestion but it does not work. eve-ng does not recognize qcow format:
If just rename .qcow to .qcow2 then eve-ng sees an image but it is not bootable:
I've tried to convert qcow to qcow2 as well:
root@eve-ng:/opt/unetlab/addons/qemu/vqfxpfe-10K-F-19.4R1.10# qemu-img convert -f qcow -O qcow2 hda.qcow hda.qcow2 qemu-img: Could not open 'hda.qcow': 'source' uses a qcow feature which is not supported by this qemu version: QCOW version 3
/var/jail/etc 123M 122M -9.5M 108% /packages/mnt/jweb-ex-12.3R11.2/jail/var/etc
/var/jail/run 123M 122M -9.5M 108% /packages/mnt/jweb-ex-12.3R11.2/jail/var/run
/var/jail/tmp 123M 122M -9.5M 108% /packages/mnt/jweb-ex-12.3R11.2/jail/var/tmp
i've looked everywhere, have already performed the system cleanup
not sure where else to check under /var
nothing comes up as being overly large
fpc0:
configuration check succeeds
fpc1:
commit complete
fpc2:
commit complete
error: could not copy to juniper.save+
Hi ccarovich,
Could you please confirm what is the platform you have, as well share a couple of commands to double check,
root> start shell user root
root@RE:0% cd /var
root@:RE:0% du -cks * | sort -rn
root@:RE:0% find / -size +100000
Regards,
Model: ex2200-24p-4g
JUNOS Base OS boot [12.3R11.2]
root@1st-VC:RE:0% pwd
/var
root@1st-VC:RE:0% du -cks * | sort -rn
21114 total
19476 run
524 rundb
498 log
166 etc
112 jail
98 etcroot
94 mfs
62 db
14 tmp
14 spool
6 home
6 at
4 transfer
4 root
4 cron
4 BSD.var.dist
2 yp
2 validate
2 rwho
2 preserve
2 named
2 msgs
2 mail
2 lost+found
2 logical-systems
2 heimdal
2 empty
2 crash
2 backups
2 account
root@1st-VC:RE:0% find / -size +100000
root@1st-VC:RE:0%
ccarovich,
Please try to check the same but going into the member that is failing,
>request session member 2
>start shell user root
........
Something else you could try if there are no weird files found, is rebooting that specific member,
>request system reboot member 2
To avoid having a downtime of the whole stack.
Please marked as "Solved" if this worked for you
ccarovich,
In case you have no option to reboot I have found another possible solution,
From the shell mode of this member, same as before,
>request session member 2
>start shell user root
%cd /var/rundb (check that you are on right directory with "pwd")
%ls | grep juniper. (if there are files matching, delete them)
%rm juniper.*
%mgd -I
If after doing this you are still not able to commit, please try with a #commit full force
Please mark as "Solved" if this worked for you
