TSuper question. Hopefully a champion will answer
Re: EX4550-32T and VCP
Re: Fluking Ports
have You ever figure it out the problem?
Juniper 2200 EX storm control
Experts, Just started noticing message:
ESWD_ST_CTL_ERROR_IN_EFFECT: ae0.0: storm control in effect on the port
ae0 is a trunk port to another switch, but show configuration ethernet-switching-options shows:
voip {
interface ge-0/0/3.0 {
vlan 80;
forwarding-class ezqos-voice-fc;
}
interface ge-0/0/6.0 {
vlan 80;
forwarding-class ezqos-voice-fc;
}
interface ge-0/0/8.0 {
vlan 80;
forwarding-class ezqos-voice-fc;
}
interface ge-0/0/9.0 {
vlan 80;
forwarding-class ezqos-voice-fc;
}
interface ge-0/0/0.0 {
vlan v80-voice;
}
interface ge-0/0/10.0 {
vlan 80;
forwarding-class ezqos-voice-fc;
}
}
storm-control {
interface all;
}
4300EX EX-BCM PIC errors
Experts,
I have started seeing these messages:
Jan 12 13:40:00 BZMDF fpc3 [EX-BCM PIC] ex_bcm_linkscan_handler: Link 46 UP
Jan 12 13:39:58 BZMDF fpc3 [EX-BCM PIC] ex_bcm_linkscan_handler: Link 46 DOWN
as errors Thank You
Re: Juniper 2200 EX storm control
Hi,
ESWD_ST_CTL_ERROR_IN_EFFECT
This condition occurs when a storm control error condition is detected.
The interface specified in the syslog message has exceeded the threshold for storm control and could either shut down or discard broadcasts, depending on the configuration. That is, the interface is receiving more broadcast traffic (either unicast or multicast) than the broadcast threshold limit set in the configuration.
Please refer to below KB :
Syslog message: ESWD_ST_CTL_ERROR_IN_EFFECT
You should look at your network (sniff the traffic in each VLAN) to verify what's the 'regular' BUM traffic level
Test the config with bigger bandwidth values for trunk port for exam.
- specifying the threshold bandwidth
{master:0}[edit] user@switch# show ethernet-switching-options storm-control { interface ge-0/0/0.0 { bandwidth 500000; } }
[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
Re: 4300EX EX-BCM PIC errors
I think this might be something juniper support might look, since I really cannot find anything.
Re: 4300EX EX-BCM PIC errors
Hi,
This is a logging done due to some call to the reference value. These log messages are merely informational and not harmful, you can ignore them.
You can use the below mentioned technical document to filter them if required:
[Junos Platform] Example - How to prevent certain syslog messages from being written to the log file
[KUDOS PLEASE! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
Re: 4300EX EX-BCM PIC errors
Yes I think the log is refering to some ports and flaping issue.
But the link is great - Thank You again.
Re: 4300EX EX-BCM PIC errors
Hi,
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..
Re: EX4550-32T and VCP
Try to answer some of your questions:
1) is it possible to create a VCP based LAG of 2*10G links between 2 members of a unique VC with 2 different link types :
a) 1 link based on SFP+ 10G optical ports of the expansion module
b) and 1 link based on RJ45 10G copper built-in ports of the 32ports EX4550 base module
or do both links inside the VCP based LAG have to be of the same type ?
on the drawing below, see for example the "vertical" VCP based LAG between member 00 and member 01 on the left side
=> Basic answer is yes. Members of a LAG do not have to be the same physical link type. This is a LAG/AE principle and is independant of whether used for Ethernet or VCP/Ethernet. I believe they actually could be of different speed and still work. Except maybe if you enabled 803.3ad/LACP on the LAG/AE as I believe this standard requires all members to be of the same speed, but I am not 100% sure of that. Check the standard could answer this for you, but at same time there are very few instances where most people would use mixed speeds.
I do know that in VCF, mixed speeds with the uplinks are actually supported, although not recommended, but VCF has a more advanced link load balancing algorithm than VC.
2) is it possible to have a VCP based LAG between 2 pairs of EX4550 in the same VC ?
see drawing below for the "horizontal" LAG (based on 2 SFP+ 10G Fiber links between the 2 DCs) that joints the members 00 & 01 pair on the left to the members 02 & 03 pair on the right ?
Of course. An Ethernet based VCP link is allowed within any One complete VC. This is one of the major advantages of Juniper VC vs other stacking technologies. This allows for geographically disbursed members within the VC. A VC could actually be created over a Ethernet WAN link as long at the round-trip delay is less than 100 msec.
No matter how you form the VC and what type of VCP connections you use, built-in or Ethernet based, the underlying IS-IS protocol knows how to build the topology and determine best [shortest] path between any 2 members.
Hopefully this provides the answers you seek.
Re: 4300EX EX-BCM PIC errors
Reported observation: “[EX-BCM PIC] ex_bcm_linkscan_handler" messages seen in the box
Resolution: These log message “pfex: [EX-BCM PIC] ex_bcm_linkscan_handler:” is informational message which is about interface going up and down. This is system detection mechanism found that port link state has changed.
Re: Juniper 2200 EX storm control
Hi Folks,
Looking at the log messages,
ESWD_ST_CTL_ERROR_IN_EFFECT: ae0.0: storm control in effect on the port
ESWD_ST_CTL_ERROR_IN_EFFECT- This condition occurs when a storm control error condition is detected. Storm control enables the switch to monitor traffic levels and to drop (BUM traffic) broadcast, multicast, and unknown unicast packets when a specified traffic level.
The following link shows a more detailed explanation of the Storm Control feature.
http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/rate -limiting-storm-control-understanding.html
The interface have an specific threshold to trigger this message. By default in the EX devices storm control level is set to 80 percent of the combined broadcast, multicast, and unknown unicast traffic streams.
When the interface received more than the 80% will trigger these messages.
I also found the following KB:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB22064
To sum up, you can change the default Storm control Level configuration for the interface to a higher value than 80%. For example:
[edit ethernet-switching-options]
lab# set storm-control interface ge-1/2/0 level 90 (This change the default from 80% to 90%)
lab# commit
I would like to know if the information above answers your question.
Re: EX2200 system overload problems with 15.1Rx upgrades
@Akeskin: We've not yet opened a case still. However there is no typo. We have adopted the 15.1 code pretty early due to some policy saying "you must not use firmware that is going to be EoE" - that was before Juniper decided to extend 12.3 support by one year...
I mentioned it in another thread - we still had the problems when we moved our test equipment from R4 to R5. As in the past R5 often was considered to be the first "mature" version of a new train I have some hope that things will become better now that the version overall has become recommended.
Just as a note also EX8200 NSSU is broken in the 15.1 code and leaves you with the XREs plus half the SREs updated but an error "access denied" appeares and so the other SREs do not upgrade even if you reboot them manually.. Plain software add with whole VC reboot works.
I cannot tell if this also applies to other models as I only tested NSSU for the 82's.
It is not very relevant to this topic here but similar behavior happened with our QFX5100 where I did the NSSU from the recent 14.1X53-D35 to the latest D40 interim release and after the NSSU OSPF was not working anymore. A reboot of the overall still working (checked via console) VC fixed this.. OSPF was in init state and not able to peer with the linked Cisco 6509's, while the links worked, according to LACP+LLDP. Also pinging the L3 interfaces worked. Restarting the routing process did not help. I just avoid NSSU whereever I can and only try it if it worked for my test equipment...
Inband Management on EX3300
Hi All,
I'm a Juniper n00b, so bare with me.
I'm setting up inband management and unable to hit the mgmt interface (am connected to the switch directly)
.
I've assigned an IP to a new MGMT vlan;
set interface vlan.10 family inet address 10.255.127.230
set vlan mgmt l3-interface vlan.10
set system services web-management http interface vlan.10
Unsure what is missing here.
Attached is config.
Any help appreciated.
Re: Inband Management on EX3300
Hi,
i think your problem is that you have created a vlan "MGMT" with vlan-id 10 and then another vlan named "mgmt" (lower-case) which you have attached the vlan.10 interface:
vlans { MGMT { vlan-id 10; } mgmt { l3-interface vlan.10; }
Try to delete "vlan mgmt" and attach l3-interface to vlan MGMT :-)
Re: Inband Management on EX3300
Corrected but no luck unforunately.
I can't ping the interface from the switch itself either.
Updated conf:
}
}
me0 {
unit 0 {
family inet {
address 10.255.254.1/17;
}
}
}
vlan {
unit 10 {
family inet {
address 10.255.127.230/32;
}
}
vlans {
mgmt {
vlan-id 10;
l3-interface vlan.10;
}
vlan-guest {
vlan-id 4001;
}
vlan-temp {
vlan-id 4000;
}
Re: Inband Management on EX3300
What physical interface/port are you on? You need to add interface into the VLAN, or associated VLAN to interface, Junos allows for both options. If this correct and still not working, then:
Does your PC/device see the switch IP and MAC in it's arp table? Something like arp -a I think works on windows, I know it works on my MAC. I assume you are seeing link on the interface/port, yes?
Re: Inband Management on EX3300
Ok, you cannot reach vlan.10 via me0.0. I expect that you via the management network (10.255.128.0/17) connected to me0.0 has a static route for 10.255.127.230/32 towards 10.255.254.1. Having a /32 route on a vlan interface does not make much sense :-)
This is not how you should do inband management. You should place the RVI (vlan.10) in your management vlan and define an IP in that subnet. I guess this is 10.255.128.0/17... So move the me0.0 IP to vlan.10 and change to different vlan if it makes sense.
But! May I guess? You are trying to do inband management on your EX3300 virtual-chassis to avoid loosing management access when the routing-engine is moved to another switch.
If i'm correct you can instead look into using the virtual management interface (vme) instead. This features provides a shared management IP for the virtual-chassis which moves to the active routing-engine. You just need to cable all management-interfaces to your management-infrastructure.
More info: https://kb.juniper.net/InfoCenter/index?page=content&id=KB25724&smlogin=true&actp=search
Hope this information helps modify your config to fit your need.
Juniper EX4200; Intermittent Packet leak to wrong Routing-Instance VLAN
Hi,
We currently have a pair of Juniper EX4200-48T (JunOS 12.3R12.4) running as separate Core LAN Switches, not stacked. They’re both configured essentially the same except for different IP / VRRP addresses. They have the Default routing-instance plus an additional routing-instance named Corporate and is of type virtual-router. The Default routing-instance has one RVI and a static default route. The Corporate routing-instance has several RVIs and is running OSPF plus a different static default route.
We have encountered an odd, intermittent problem in which some packets arriving on a Corporate VLAN that should be exiting on a different Corporate VLAN (IP route exists) are actually exiting the 4200 through the RVI/VLAN in the Default routing-instance..
To further confuse this, the packet source MAC address DOES NOT CHANGE as it transits the switch. The destination MAC address changes to the default router’s MAC address for the Default routing-instance. As expected the source and destination IP addresses do not change through the switch.
We have Wiresharked the ingress and egress interfaces and this is definitely happening within the EX4200. It appears that the packet is “leaking” to the wrong routing-instance VLAN.
Has anyone seen this before or have any ideas what could be causing this?
Thank you for your time. Larry
Re: QFX5200: issu yes or no?
Had a pretty bad support experience here. I opened a support case for that asking for this very topic and simply wanted to get an answer
- if the datasheet is just wrong or
- if the feature will be added a little later
The constant answer I got was "you don't have a support contract, we will not answer you". This is quite strange since we bought two of those for the lab in order to identify if those machines will work for a future setup or not. So right now it's not mission critical but that shouldn't be the point: my question was not support contract related but a general issue with the promise, that Juniper made and didn't keep.
To sum it up: this is not how a Vendor should deal with that. It's like asking a car vendor why it doesn't have the navigation installed that every catalogue said it has by default and the vendor answers that you won't receive an answer because you didn't come to his workshop for the last maintenance but chose an independent one.