Hello,
So just to simplify, your first 12 ports should be in vlan x.
And remaining ports would be in vlan y.
And you want to make sure that the moment you configure first 12 ports into vlan x, ping from machines connected to these 12 ports should not stop to the machines connected to port on vlan y.
Is that correct?
On the working setup, do you have a trunk port on juniper switch that connects to L3 device with vlan x & vlan y as part of it?
Regards,
Rushi
Hi,
I am receiving the following message repeatedly:
"L2ALD_MAC_MOVE_EXCEEDED_BD_ACTION_NONE: Limit on MAC moves exceeded at VLAN vlan-trust+1for MAC 00:ae:45:54:a0:6e moved from interface ge-0/0/2.0 to interface ge-0/0/5.0;Mac move limit is 0. No action ( Forwarding the packet)"
I cannot find this MAC address within my show arp / dhcp server bind tables. I have seen in the forums that this is possibly a loop.
Not finding anywere in the SRX where i can set mac-move limits and actions. Is this even something i should worry about?
ge-0/0/2 {
unit 0 {
family ethernet-switching {
vlan {
members vlan-trust;
ge-0/0/5 {
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members all;
Repeats:
Mon Aug 20 21:19:18 2018 vlan_name vlan-trust+1 mac 00:ae:45:54:a0:6e was moved from ge-0/0/5.0 to ge-0/0/2.0 with flags: 0x2101f
Mon Aug 20 21:19:19 2018 vlan_name vlan-trust+1 mac 00:ae:45:54:a0:6e was moved from ge-0/0/2.0 to ge-0/0/5.0 with flags: 0x2101f
*comes up as no vendor*
Global Configuration:
MAC aging interval : 300
MAC learning : Enabled
MAC statistics : Disabled
MAC limit Count : 16383
MAC limit hit : Disabled
MAC packet action drop: Disabled
LE aging time : 1200
LE VLAN aging time : 1200
Global Mode : Switching
Routing instance VLAN name Tag Interfaces
default-switch vlan-phones 100
ge-0/0/3.0
ge-0/0/4.0
ge-0/0/5.0*
default-switch vlan-ss 3
ge-0/0/3.0
ge-0/0/4.0
ge-0/0/5.0*
default-switch vlan-trust 1
ge-0/0/1.0*
ge-0/0/2.0*
ge-0/0/3.0
ge-0/0/4.0
ge-0/0/5.0*
ge-0/0/6.0
ge-0/0/7.0
When i blocked the MAC address, IP phones at another location stopped working. Anything i could try would be helpful
i have a new ex2200 switch which i am trying to get connected (physically) by using the RJ-45 cable with a DB9 female connector on it- came with the switch.
my laptop doesnt have a serial connector. i dont even know if the switch is even good. i do not have a server to get a DHCP address from. i dont have a PC which has a male serial cable either.
all i want to do is get connected so i can run "ezsetup"
i cant get any response - login prompt- from the switch no matter how i connect to it. rj45, serial, etc.
this has got to be the dumbest way to get connected to a switch.
You can do the configuration via the jweb interface on one of the normal ethernet ports.
The dhcp setup you need for this is to put your laptop or pc as a dhcp client which will get an address from the switch not a server.
There is a 10 minute limit from first power on to launch the jweb ez setup. The details are here.
That particular mac string 00:ae:45: is not assigned to any company yet so apparently your ip phones are using this as a generated address. Likely what is happening is the phones are using the same address via the software generating it being the same.
That would account for the moves too as multiple devices using the same mac would appear to be mac moves to different interfaces.
I would check with the ip phone vendor site to see if there are firmware updates that deal with the issue.
Can I protect ARP flooding from DDos to prevent control plane on EX switch?
Normally, We can use firewall filter and write condition in order to map with service or protocol but in case of ARP, How to protect its?
Ok, that is something i can look into. I can see all the Cisco IP phone MAC addresses off the call manager. None of those match. I will reach out to cisco and see if any firmware updates might address this issue.
What i did was put an input and output filter on the ge-0/0/2.0 interface with that mac address. This is now preventing it from going back and forth across the interfaces. Its a quick fix as i implement some additional configuration across the switches that connect to the SRX.
Ok that did not work. Spanning tree and everything else is set up. no where on the SRX can i even set an option for anything related to mac moves. This MAC address does not exist. I guess my only option is to unplug things and see if that stops. Yay juniper...........great.
wrote: What i did was put an input and output filter on the ge-0/0/2.0 interface with that mac address. This is now preventing it from going back and forth across the interfaces. Its a quick fix as i implement some additional configuration across the switches that connect to the SRX.
Model: ex4200-24p, ex4200-24t
Junos: 15.1R6.7
I'm trying to configure a route distinguisher on a virtual-router routing instance. I fail with the following:
# set routing-instances 15 route-distinguisher 65535:1
#commit
[edit routing-instances]
'15'
RT Instance: Route-distinguisher cannot be configured for virtual-router instance: 15
error: configuration check-out failed
What gives?
Also, I wonder if it matters. Are route distinguishers only signficant at the network edge, over BGP?
Hi
I want to run RSTP on all the interfaces of my switches ( they are in VC). I have some normal interfaces and some are aggregated interfaces. I want to run RSTP on all of them . I want to avoid group configuration. Please tell me full comands to configure it . My switch interfaces are mentioned below .:
set protocols rstp interface all command is not working
--------------------------------------------------------------------------------------------
ge-0/0/1 up up
ge-0/0/1.0 up up aenet --> ae2.0
ge-0/0/2 up up
ge-0/0/2.0 up up aenet --> ae3.0
ge-0/0/3 up up
ge-0/0/3.0 up up aenet --> ae4.0
ge-0/0/4 up up
ge-0/0/4.0 up up aenet --> ae5.0
ge-0/0/5 up up
ge-0/0/5.0 up up aenet --> ae6.0
ge-0/0/6 up up
ge-0/0/6.0 up up aenet --> ae7.0
ge-0/0/7 up up
ge-0/0/7.0 up up aenet --> ae8.0
ge-0/0/8 up up
ge-0/0/8.0 up up aenet --> ae9.0
ge-0/0/9 up up
ge-0/0/9.0 up up aenet --> ae10.0
ge-0/0/10 up up
ge-0/0/10.0 up up aenet --> ae11.0
ge-0/0/11 up up
ge-0/0/11.0 up up aenet --> ae12.0
ge-0/0/12 up down
ge-0/0/13 up down
ge-0/0/14 up down
ge-0/0/15 up down
ge-0/0/16 up down
ge-0/0/17 up down
ge-0/0/18 up down
ge-0/0/19 up down
ge-0/0/20 up down
ge-0/0/21 up down
ge-0/0/22 up down
ge-0/0/23 up down
ge-0/0/24 up down
ge-0/0/25 up down
ge-0/0/26 up down
ge-0/0/27 up down
ge-0/0/28 up down
ge-0/0/29 up down
ge-0/0/30 up down
ge-0/0/31 up down
ge-0/0/32 up down
ge-0/0/33 up down
ge-0/0/34 up down
ge-0/0/35 up down
ge-0/0/36 up down
ge-0/0/37 up down
ge-0/0/38 up down
ge-0/0/39 up down
ge-0/0/40 up down
ge-0/0/41 up down
ge-0/0/42 up down
ge-0/0/43 up down
ge-0/0/44 up down
ge-0/0/45 up down
ge-0/0/46 up down
ge-0/0/47 up down
xe-0/2/0 up up
xe-0/2/0.0 up up aenet --> ae0.0
ge-1/0/0 up up
ge-1/0/0.0 up up aenet --> ae1.0
pfe-1/0/0 up up
pfe-1/0/0.16383 up up inet
inet6
pfh-1/0/0 up up
pfh-1/0/0.16383 up up inet
ge-1/0/1 up up
ge-1/0/1.0 up up aenet --> ae2.0
ge-1/0/2 up up
ge-1/0/2.0 up up aenet --> ae3.0
ge-1/0/3 up up
ge-1/0/3.0 up up aenet --> ae4.0
ge-1/0/4 up up
ge-1/0/4.0 up up aenet --> ae5.0
ge-1/0/5 up up
ge-1/0/5.0 up up aenet --> ae6.0
ge-1/0/6 up up
ge-1/0/6.0 up up aenet --> ae7.0
ge-1/0/7 up up
ge-1/0/7.0 up up aenet --> ae8.0
ge-1/0/8 up up
ge-1/0/8.0 up up aenet --> ae9.0
ge-1/0/9 up up
ge-1/0/9.0 up up aenet --> ae10.0
ge-1/0/10 up up
ge-1/0/10.0 up up aenet --> ae11.0
ge-1/0/11 up up
ge-1/0/11.0 up up aenet --> ae12.0
ge-1/0/12 up down
ge-1/0/13 up down
ge-1/0/14 up down
ge-1/0/15 up down
ge-1/0/16 up down
ge-1/0/17 up down
ge-1/0/18 up down
ge-1/0/19 up down
ge-1/0/20 up down
ge-1/0/21 up down
ge-1/0/22 up down
ge-1/0/23 up down
ge-1/0/24 up down
ge-1/0/25 up down
ge-1/0/26 up down
ge-1/0/27 up down
ge-1/0/28 up down
ge-1/0/29 up down
ge-1/0/30 up down
ge-1/0/31 up down
ge-1/0/32 up down
ge-1/0/33 up down
ge-1/0/34 up down
ge-1/0/35 up down
ge-1/0/36 up down
ge-1/0/37 up down
ge-1/0/38 up down
ge-1/0/39 up down
ge-1/0/40 up down
ge-1/0/41 up down
ge-1/0/42 up down
ge-1/0/43 up down
ge-1/0/44 up down
ge-1/0/45 up down
ge-1/0/46 up down
ge-1/0/47 up down
xe-1/2/0 up up
xe-1/2/0.0 up up aenet --> ae0.0
ae0 up up
ae0.0 up up eth-switch
ae1 up up
ae1.0 up up eth-switch
ae2 up up
ae2.0 up up eth-switch
ae3 up up
ae3.0 up up eth-switch
ae4 up up
ae4.0 up up eth-switch
ae5 up up
ae5.0 up up eth-switch
ae6 up up
ae6.0 up up eth-switch
ae7 up up
ae7.0 up up eth-switch
ae8 up up
ae8.0 up up eth-switch
ae9 up up
ae9.0 up up eth-switch
ae10 up up
ae10.0 up up eth-switch
ae11 up down
ae11.0 up down eth-switch
ae12 up down
ae12.0 up down eth-switch
ae13 up down
ae14 up down
ae15 up down
ae16 up down
ae17 up down
ae18 up down
ae19 up down
ae20 up down
ae21 up down
ae22 up down
ae23 up down
ae24 up down
ae25 up down
ae26 up down
ae27 up down
ae28 up down
ae29 up down
ae30 up down
ae31 up down
ae32 up down
ae33 up down
ae34 up down
ae35 up down
ae36 up down
ae37 up down
ae38 up down
ae39 up down
ae40 up down
ae41 up down
ae42 up down
ae43 up down
ae44 up down
ae45 up down
ae46 up down
ae47 up down
ae48 up down
ae49 up down
ae50 up down
ae51 up down
ae52 up down
ae53 up down
ae54 up down
ae55 up down
ae56 up down
ae57 up down
ae58 up down
ae59 up down
ae60 up down
ae61 up down
ae62 up down
ae63 up down
ae64 up down
ae65 up down
ae66 up down
ae67 up down
ae68 up down
ae69 up down
ae70 up down
ae71 up down
ae72 up down
ae73 up down
ae74 up down
ae75 up down
ae76 up down
ae77 up down
ae78 up down
ae79 up down
--------------------------------------------------------------------------------
Thanks a lot
Virtual router instances do not use route distinguishers. They are used in L2 or L3 VPNs - instance types l2vpn, vpls, or vrf.
can you see the mac table of the switch the srx is connected to?
What we really need is the port the devices generating this mac address are connected to. The mac move on the SRX is upstream of that.
under the rstp section you can use either interface all or ranges
set protocols rstp interface all
or configure interface ranges and reference these in protocols rstp
https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interface-ranges.html
Hello!
Does anyone have a luck with Software Upgrade on QFX 10008 as it is described in Release Notes?
I'm trying to upgrade my box from 17.2R2-S2.1 to 17.4R1-S4.2 and now stuck on 12th step.
'request chassis routing-engine master switch check' command reports that backup RE is not ready for switchover:
minotaur@core-sw1-gdr.ki> ...-engine master switch check warning: Traffic will be interrupted while the PFE is re-initialized Standby Routing Engine is not ready for graceful switchover.
... and it does not become ready neither in 10 minutes, nor in 10 hours.
If I ignore that and force RE master switching then all FPCs restart, and I lose a box for approx. 15-20 minutes, and a lot of messages appears on console of backup RE:
Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:17 ... core-sw1-gdr.ki fpc0 fpc0 dcpfe: Frame 06: sp = 0x40065bf8, pc = 0x10f7e6b0 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:17 ... core-sw1-gdr.ki fpc0 fpc0 dcpfe: Frame 07: sp = 0x40065c18, pc = 0x107cc184 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:17 ... core-sw1-gdr.ki fpc0 fpc0 dcpfe: Frame 08: sp = 0x40065c68, pc = 0x1003af80 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: SCHED: Thread 30 (cmqfx_pseudo) ran for 1468 ms without yielding Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Scheduler Oinker Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 00: sp = 0x3ffa9958, pc = 0x100474c0 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 01: sp = 0x3ffa9978, pc = 0x1003840c Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 02: sp = 0x3ffa99e8, pc = 0x10997a04 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 03: sp = 0x3ffa9a88, pc = 0x107e3c50 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 04: sp = 0x3ffa9b38, pc = 0x107dc370 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 05: sp = 0x3ffa9b68, pc = 0x107dc9c8 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 06: sp = 0x3ffa9be8, pc = 0x10f7e6b0 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 07: sp = 0x3ffa9c08, pc = 0x107cc184 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:18 ... core-sw1-gdr.ki fpc1 fpc1 dcpfe: Frame 08: sp = 0x3ffa9c58, pc = 0x1003af80 Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:19 ... core-sw1-gdr.ki spmb1 CMLC: Going disconnected; Routing engine chassis socket closed abruptly Message from syslogd@core-sw1-gdr.ki at Aug 22 16:03:29 ... core-sw1-gdr.ki spmb1 CMLC: Going disconnected; Routing engine chassis socket closed abruptly
minotaur@core-sw1-gdr.ki>
Message from syslogd@core-sw1-gdr.ki at Aug 22 16:05:56 ...
core-sw1-gdr.ki fpc0 fpc0 dcpfe: SCHED: Thread 28 (cmqfx_pseudo) aborted, hogged 4245 ms
Message from syslogd@core-sw1-gdr.ki at Aug 22 16:06:11 ...
core-sw1-gdr.ki fpc1 fpc1 dcpfe: SCHED: Thread 28 (cmqfx_pseudo) aborted, hogged 4239 ms
Such behavior looks strange, and it conflicts with that is written in Release Notes: "Because the switch has two Routing Engines, perform a Junos OS installation on each Routing Engine separately to avoid disrupting network operation. ".
JTAC engineer for some weeks was convincing me that seamless software upgrade is not possible on QFX 10008, then I had just to ask him to close the ticket.
Any help is appreciated! Thanks!
This is expected during the upgrade and JTAC is right. The FPCs reboot because GRES is disabled.
You can try ISSU which is not service impacting, but check with JTAC if this is supported.
request system software in-service-upgrade /var/tmp/package-name.tgz
ARP policer can be applied, but looks like it's not supported on EX.
Example on inet interface,
# set interfaces x unit x family inet policer arp ARP_Policer
lab@j> show configuration firewall policer ARP_Policer
if-exceeding {
bandwidth-limit 8k;
burst-size-limit 1500;
}
then discard;
Note
By default, an ARP policer is installed that is shared among all the Ethernet interfaces on which you have configured the family inet statement. By including the arp statement at the [edit interfaces interface-name unit logical-unit-number family inet policer] hierarchy level, you can apply a specific ARP-packet policer to an interface. This feature is not available on EX Series switches.
Hi,
With GRES, the master RE can be switched without rebooting the linecards. However, it does not provide control plane resilience. NSR provides this part. With NSR, the protocol states and routes are synchronized between the primary and backup REs. With these two features, the master RE can be swapped/switched without any traffic loss.
This requires both REs to be using the same version, and AFAIK ISSU is not yet supported on QFX10002.
Perhaps in roadmap, you want to check Juniper Accounts Team on that!
In order to have minimum down time, upgrade as follows:
RE0 = Primary/Master
RE1 = Secondary/Standby
1. Upgrade Standby RE1 and reboot RE1:
a. show chassis routing-engine (determine which RE is master and standby)
b. request system software add /var/tmp/jinstall-host-qfx-package.tgz re1 (re1 – current Standby RE)
2. Reboot standby RE
a. request system reboot other-routing-engine
3. Verify Standby RE1 is online with upgraded software version
a. show chassis routing-engine | no-more
b. show version invoke-on all-routing-engines | no-more
4. Perform a Routing Engine master switchover
a. request chassis routing-engine master switch check
b. request chassis routing-engine master switch
5. Upgrade new standby RE (RE0)
a. request system software add /var/tmp/jinstall-host-qfx-package.tgz re0 (re0 – current Standby RE)
6. Reboot new standby RE
a. request system reboot other-routing-engine
Verification
# run show task replication
#show version invoke-on all-routing-engines
#run request support information | no-more
In this way, the backup RE was upgraded with no traffic loss. Then the master-ship was swapped.
This resulted in traffic loss as the FPCs rebooted to the master RE (both REs were not on the same version, so GRES/NSR did not help). Then the new backup RE was upgraded with no traffic loss. Finally, the RE mastership was swapped back, no traffic loss.
Generally, other method you may see are disable GRES & NSR prior the upgrade and re-enable post upgrade which is standard upgrade practice.
Hello Jad,
could you please share me the link which notifies that in 15.1R3 have implemented this support.