I have multiple customers who runs with EX-SFP-1GE-T for the HA control port without any issues.
There has been issues using 10G DAC for the fabric link in in Junos 15.1X49-D80 -> 15.1X49-D110 but with later releases it should "just work" :-)
I have multiple customers who runs with EX-SFP-1GE-T for the HA control port without any issues.
There has been issues using 10G DAC for the fabric link in in Junos 15.1X49-D80 -> 15.1X49-D110 but with later releases it should "just work" :-)
Thanks for the tip @jonashauge.
Hi,
thank you for your answer.
Unfortunatley no core dumps...
show system core-dumps
fpc0:
--------------------------------------------------------------------------
/var/crash/*core*: No such file or directory
/var/tmp/*core*: No such file or directory
/var/tmp/pics/*core*: No such file or directory
/var/crash/kernel.*: No such file or directory
/var/jails/rest-api/tmp/*core*: No such file or directory
/tftpboot/corefiles/*core*: No such file or directory
Regards
Hi,
thanky ou for your ideas.
% sysctl hw.re.reboot_reason
hw.re.reboot_reason: 131072
on all switches...
Pretty weird...
Regards
Hi everyone.
By default 2 QSPF+ ports on the rear are configured for VCP. Can we use 10G SFP+ to build Virtual chasis for longer distance on QSFP+ ports ? For example, in Brocade , we can use QSPF+ ports with 10GSFP+ to build chassis , the trade off is speed.
Additional info:
We have three EX4300-32F which are 80 meter apart, these switches have no uplink module ( 10GSFP+) but do have built in QSFP+ ports .
Thanks,
Have a good night!!
No, the rear QSFP+ ports are not able to be channelized into 4x10Gb ports. 40Gb SR4 does 100m on OM3 and 40Gb LR4 does 10km on SM so I'm not sure why you're concerned about 80m distance between switches.
On top of smickers input; You can create virtual chassis based on SFP+ ports - but with one contrain: You cannot use the 4 built-in SFP+ ports on EX4300-32F. It has to be via an uplink-module (EX-UM-4X4SFP for the EX4300-24T/EX4300-48T or EX-UM-8x8SFP for EX4300-32F)
This is documented in https://kb.juniper.net/InfoCenter/index?page=content&id=KB32266
Hi all,
I'm facing an issue with traffic through l2circuit, no traffic is going on that circuit while is showing UP others l2circuit is working (pass traffic).
I have a bockbone with 13 juniper EX4550 running all 12.3R12-S7, ldp and rsvp all enable on mpls interfaces.
between EX4550 cg-sw1 and cg-sw1 a circuit is configure as below
cg-sw1#
set interfaces xe-0/0/10 description "L2L Customer A"
set interfaces xe-0/0/10 mtu 9216
set interfaces xe-0/0/10 encapsulation ethernet-ccc
set interfaces xe-0/0/10 unit 0 family ccc
set protocols l2circuit neighbor 192.168.200.6 interface xe-0/0/10.0 virtual-circuit-id 2006
cg-sw6#
set interfaces xe-0/0/2 description "L2L Customer A"
set interfaces xe-0/0/2 mtu 9216
set interfaces xe-0/0/2 encapsulation ethernet-ccc
set interfaces xe-0/0/2 unit 0 family ccc
set protocols l2circuit neighbor 192.168.200.1 interface xe-0/0/2.0 virtual-circuit-id 2006
The circuit is UP has below but not traffic is passed:
cg-sw1> show l2circuit connections neighbor 192.168.200.6 interface xe-0/0/10.0
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad SP -- Static Pseudowire
LD -- local site signaled down RS -- remote site standby
RD -- remote site signaled down XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 192.168.200.6
Interface Type St Time last up # Up trans
xe-0/0/10.0(vc 2006) rmt Up Jan 7 18:40:49 2019 1
Remote PE: 192.168.200.6, Negotiated control-word: Yes (Null)
Incoming label: 308432, Outgoing label: 306320
Negotiated PW status TLV: No
Local interface: xe-0/0/10.0, Status: Up, Encapsulation: ETHERNET
{master:0}
cg-sw1>
What is very strange to me is, if I disable and enable port, traffic start going trough but, an other l2circuit stop forwarding traffic at the same time on the equipement traffic while is showing UP and all others continue to work.
I have done traceoptions under [protocols l2circuit] no trace collect as all l2circuit is showing UP, note that on juniper EX4550 I can't perform ping mpls (not support), do some one faced already this issue ? do you have an idea, who to troubleshoot well and solve this issue ?
I was thinking may be the issue is the PFE (Packet Forwarding Engine), I checked "show pfe route ip/mpls" all labels are exchange well.
Any suggestion will be wellcome.
Thank you.
Hello there,
There is not enough information to analyze. Please let us know:
1/ is there any other L2circuit BETWEEN THE SAME PAIR OF SWITCHES that passes traffic? If yes please post its config. If not, then please read https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-ex-series-components.html and make sure that core-facing interfaces on CG-SW1 AND CG-SW6 are untagged.
2/ have You tried disabling Control Word?
HTH
Thx
Alex
update from juniper
PR num is 1401915.
12.3R12-S13 is the fix release now
Hello aarseniev
Thank you for your reply.
For your first point:
Yes, there is others l2circuit BETWEEN THE SAME PAIR OF SWITCHES that passes traffic
Core facing interfaces are untagged
Find below how my config is organized.
For your second point, I did not yet disable Control Word, I'm still checking why this come, if any progress I will schedule a maintenance window in order to disable Control Word.
Any suggestions will be wellcome.
cg-sw1#
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/10 description "L2L Customer A"
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/10 mtu 9216
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/10 encapsulation ethernet-ccc
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/10 unit 0 family ccc
set groups SERVICE-CUSTOMER-A protocols l2circuit neighbor 192.168.200.6 interface xe-0/0/10.0 virtual-circuit-id 2006
set apply-groups SERVICE-CUSTOMER-A
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/3 unit 3300 description "L2L Customer B"
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/3 unit 3300 encapsulation vlan-ccc
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/3 unit 3300 vlan-id 3300
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/3 unit 3300 family ccc
set groups SERVICE-CUSTOMER-B protocols l2circuit neighbor 192.168.200.6 interface ge-0/0/3.3300 virtual-circuit-id 3300
set apply-groups SERVICE-CUSTOMER-B
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/6 unit 947 description "L2L Customer C"
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/6 unit 947 encapsulation vlan-ccc
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/6 unit 947 vlan-id 947
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/6 unit 947 family ccc
set groups SERVICE-CUSTOMER-C protocols l2circuit neighbor 192.168.200.6 interface ge-0/0/6.947 virtual-circuit-id 2011
set apply-groups SERVICE-CUSTOMER-C
cg-sw6#
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/2 description "L2L Customer A"
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/2 mtu 9216
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/2 encapsulation ethernet-ccc
set groups SERVICE-CUSTOMER-A interfaces xe-0/0/2 unit 0 family ccc
set groups SERVICE-CUSTOMER-A protocols l2circuit neighbor 192.168.200.1 interface xe-0/0/2.0 virtual-circuit-id 2006
set apply-groups SERVICE-CUSTOMER-A
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/4 unit 3300 description "L2L Customer B"
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/4 unit 3300 encapsulation vlan-ccc
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/4 unit 3300 vlan-id 3300
set groups SERVICE-CUSTOMER-B interfaces ge-0/0/4 unit 3300 family ccc
set groups SERVICE-CUSTOMER-B protocols l2circuit neighbor 192.168.200.1 interface ge-0/0/4.3300 virtual-circuit-id 3300
set apply-groups SERVICE-CUSTOMER-B
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/5 unit 947 description "L2L Customer C"
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/5 unit 947 encapsulation vlan-ccc
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/5 unit 947 vlan-id 947
set groups SERVICE-CUSTOMER-C interfaces ge-0/0/5 unit 947 family ccc
set groups SERVICE-CUSTOMER-C protocols l2circuit neighbor 192.168.200.1 interface ge-0/0/5.947 virtual-circuit-id 2011
set apply-groups SERVICE-CUSTOMER-C
From what I can tell the change is most likely applicable to any Juniper device that supports 802.1x with multiple supplicants, and the change is across all code streams, 12.3 and beyond. As for situation:
On EX2200/EX3200/EX3300/EX4200, when interface is enabled dot1x multiple supplicant mode and there is a firewall filter configured on loopback interface, MAC learning for unknown source might be dropped which causes dot1x authentication issue.
Just FYI.
Hi there
I noticed that any interface NOT assigned to a interface-range will not power on. Case in point
ge0/0/16 will not come on when assigned to a specific vlan. However when it assigned as part of a member range it comes on with no issues. What am I missing? I'm really new to Junos and learning as I go. The cisco side of my brain is screaming!!!
root@PPAL# show interfaces
interface-range user-ports {
member-range ge-0/0/0 to ge-0/0/47;
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members PPALINET;
}
storm-control default;
}
}
}
interface-range staff-ports {
member-range ge-1/0/1 to ge-1/0/3;
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members PPALSTAFF;
}
storm-control default;
}
}
}
interface-range inet-ports {
member-range ge-1/0/4 to ge-1/0/15;
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members PPALINET;
}
}
}
}
ge-0/1/0 {
ether-options {
802.3ad ae0;
}
}
ge-1/0/0 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members PPALPRINT;
}
storm-control default;
}
}
}
ge-1/0/4 {
unit 0 {
family ethernet-switching {
vlan {
members PPALINET;
}
}
}
}
ge-1/0/15 {
unit 0;
}
ge-1/0/16 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members 2606;
}
storm-control default;
}
}
}
ge-1/0/22 {
description "BMS Port";
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members 2606;
}
}
}
}
ge-1/0/23 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members 1706;
}
storm-control default;
}
}
}
ge-1/1/0 {
ether-options {
802.3ad ae0;
}
}
ae0 {
aggregated-ether-options {
link-speed 1g;
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members all;
}
}
}
}
irb {
unit 0 {
family inet {
dhcp {
vendor-id Juniper-ex2300-48P;
}
}
}
unit 27 {
family inet {
address 172.18.27.13/24;
}
}
unit 1706 {
family inet {
address 172.17.6.100/24;
}
}
unit 2106 {
family inet {
address 172.21.6.100/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 1.1.1.1/32;
}
}
}
vme {
unit 0 {
family inet {
dhcp {
vendor-id Juniper-ex2300-48P;
}
}
}
}
root@PPAL# show vlans
MGMTVLAN {
vlan-id 27;
l3-interface irb.27;
}
PPALHVAC {
vlan-id 2606;
}
PPALINET {
vlan-id 2306;
}
PPALPRINT {
vlan-id 2206;
}
PPALSTAFF {
vlan-id 1706;
l3-interface irb.1706;
}
PPALVOICE {
vlan-id 2106;
l3-interface irb.2106;
}
default {
vlan-id 1;
l3-interface irb.0;
}
Hi,
in my chassis Logfile I've tons of those messages:
There are two possibilities
One is communication error between the daemon who is managing LEDs and physical LEDs. The other is power supply flapping.
Are you seeing any alarm at the time of errors?
Two narrow down
1. Restart “craftd” via shell command “root% kill -9 <process ID of craftd>”
2. Reseat physically all power supplies on both FPCs
Ok, it must be the deamon for managing the LEDs because all LEDs are off but Ports working fine so far. I'm new in QFX and already wondering why all LEDs are off.
Maybe a hardware problem on both switches because reboot does not help to enable LEDs?
Restart of craftd did not help:
Jan 11 14:31:51 pem_tvp_periodic cbd=9518940 slot=1, state=1
Jan 11 14:31:53 chassis_handle_peer_receive: closing connection: errno = 0
Jan 11 14:31:53 closing connection on fd 42
Jan 11 14:31:53 craftd connection completed
Jan 11 14:31:56 pem_tvp_periodic cbd=9518940 slot=1, state=1
Jan 11 14:31:56 pem_tvp_periodic cbd=9518940 slot=1, state=1
Jan 11 14:32:01 pem_tvp_periodic cbd=9518940 slot=1, state=1
Jan 11 14:32:01 pem_tvp_periodic cbd=9518940 slot=1, state=1
Jan 11 14:32:06 pem_tvp_periodic cbd=9518940 slot=1, state=1
There are no alarms