Thanks for the info.
Can you provide the PR number for other to refer to? and were you informed if the firmware would be included in later Junos releases?
Thanks for the info.
Can you provide the PR number for other to refer to? and were you informed if the firmware would be included in later Junos releases?
@jonashauge - great minds think alike - PR # is 1429327, which is associated with another PR # 1415107. Looks like fix is going into:
18.2R3
18.3R3
18.4R2
19.1R2
19.2R2 (too late for R1, I believe)
19.x and above
HTH
For this situation you do need to open a TAC case, and get them to work the SIRT change into the 15.1 code stream for EX4200. You should also ask them to include in next 12.3 SR.
We had the same internal security audit run last year and the same vulnerability was identified. I did not pursue it at that point since the Nessus software identified quite a few other problems we did work on. So what you are saying is this issue has existed for awhile and Juniper has just not addressed it in Junos to date?
Do you know what the SIRT vulernability (CVE) for this situation is? I believe it might be CVE-2016-9310. A quick search brings up this link:
https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10796&actp=METADATA
From looking at this, it appears EX4200 not affected? I would still think this type of situation should be work (at least in parallel) with TAC.
Hi,
I installed a pair of EX4300 a few weeks ago. Very simple setup, and using virtual chassis.
Today I had to make a few changes to the configuration, but commit failed:
root@tpsw01# commit fpc0: configuration check succeeds fpc1: error: Check-out failed for Chassis control process (/usr/sbin/chassisd) without details error: configuration check-out failed fpc0: error: remote commit-configuration failed on fpc1 error: commit failed
The log doesn't show much interesting:
tpsw01 mgd[10495]: UI_COMMIT: User 'root' requested 'commit' operation (comment: none) tpsw01 mgd[10495]: UI_CHILD_EXITED: Child exited: PID 11979, status 7, command '/usr/sbin/mustd'
Both switches are running the same version of Junos, 17.3R3-S4.2:
root@tpsw01# run show system snapshot media internal fpc0: -------------------------------------------------------------------------- Information for snapshot on internal (/dev/da0s1a) (primary) Creation date: Apr 10 21:10:46 2019 JUNOS version on snapshot: jcrypto-ex: 17.3R3-S4.2 jdocs-ex: 17.3R3-S4.2 jsd : powerpc-17.3R3-S4.2-jet-1 jsdn-powerpc: 17.3R3-S4.2 junos : ex-17.3R3-S4.2 junos-ex-4300: 17.3R3-S4.2 jweb-ex: 17.3R3-S4.2 Information for snapshot on internal (/dev/da0s2a) (backup) Creation date: Apr 17 20:57:12 2019 JUNOS version on snapshot: jcrypto-ex: 17.3R3-S4.2 jdocs-ex: 17.3R3-S4.2 jsd : powerpc-17.3R3-S4.2-jet-1 jsdn-powerpc: 17.3R3-S4.2 junos : ex-17.3R3-S4.2 junos-ex-4300: 17.3R3-S4.2 jweb-ex: 17.3R3-S4.2 fpc1: -------------------------------------------------------------------------- Information for snapshot on internal (/dev/da0s1a) (primary) Creation date: Apr 10 21:10:45 2019 JUNOS version on snapshot: jcrypto-ex: 17.3R3-S4.2 jdocs-ex: 17.3R3-S4.2 jsd : powerpc-17.3R3-S4.2-jet-1 jsdn-powerpc: 17.3R3-S4.2 junos : ex-17.3R3-S4.2 junos-ex-4300: 17.3R3-S4.2 jweb-ex: 17.3R3-S4.2 Information for snapshot on internal (/dev/da0s2a) (backup) Creation date: Apr 17 20:58:13 2019 JUNOS version on snapshot: jcrypto-ex: 17.3R3-S4.2 jdocs-ex: 17.3R3-S4.2 jsd : powerpc-17.3R3-S4.2-jet-1 jsdn-powerpc: 17.3R3-S4.2 junos : ex-17.3R3-S4.2 junos-ex-4300: 17.3R3-S4.2 jweb-ex: 17.3R3-S4.2
Any ideas?
I tried to do a "commit full" but with the same error message.
I opened a ticket with JTAC about this same vulnerability on our EX4600 core. They pointed me to this
This vulnerability has been described on security bulletin JSA10613: https://kb.juniper.net/
They said the best way to mitigate this is a firewall rule, here is what they wrote
If a possible attack has been identified, or if the NTP process is occupying a large amount of CPU or memory resources, the most effective mitigation is to apply a firewall filter to allow only trusted addresses and networks, plus the router's loopback address, access to the NTP service on the device, rejecting all other requests. For example:
term allow-ntp {
from {
source-address {
<trusted-addresses>;
<router-loopback-address>;
}
protocol udp;
port ntp;
}
then accept;
}
term block-ntp {
from {
protocol udp;
port ntp;
}
then {
discard;
}
}
This term may be added to the existing loopback interface filter as part of an overall control plane protection strategy. In general, security best practices recommend having such a filter term, even during normal operation.
Thanks for the update. Glad the fix is in and working.
hi there,
can you show us the output of:
#commit | display detail
it seems to be FPC1 thats not committing this might give us a better lead
Hi,
Consider I have 2 juniper devices A & B
A & B are connected with the phyiscal interface.
I logged in to A device & I know the IP address on connected physical interface end.
How to find from machine A what is the IP address of other physical interface end which is connected to device B.
Thanks,
Nilesh
Hi nileshbhadane,
I'm assuming you're troubleshooting a connectivity issue. There's no standard way to know this, but some fun ideas:
a) If you expect to receive any L3 protocol traffic from the peer, just apply an input firewall filter and log packets matching the protocol in question.
Example:
set firewall family inet filter test term 1 from protocol ospf
set firewall family inet filter test term 1 then log
set firewall family inet filter test term 1 then discard
set firewall family inet filter test term 2 then accept
wait for a minute and once interface can see input packets (show interfaces extensive), then check:
show firewall log
b) If you have ISIS enabled on both ends there will be an Interface address TLV in the IIS hello (IIH) packet that includes interface address.
Example:
IPv4 Interface address(es) TLV #132, length: 4
IPv4 interface address: 68.86.2.195
0x0000: 4456 02c3
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .
The mystery deepens. We received a replacement switch from Juniper, installed it and the same behavior. The switch has Ruckus APs patched in on ports 0-31, ports 32-47 are empty. The APs on ports 0-24 are getting PoE power, the APs on ports 25-31 are not. This is from the Juniper documentation:
"The power budget calculation for class 0 and class 4 powered devices, whose power allocation is based solely upon class, is based on actual power consumption. These values are displayed in the Power consumption field in the output of the show poe interface CLI command. The power budget is the sum of the power consumption values for all PoE-enabled interfaces."
When we issue the "show poe interface" command it shows these APs as class 4 devices. The maximum power column shows 25.0w(L) where the L means LLDP negotiated this power. The power consumption columns show actual power usage which is between 5 and 5.6w.
My latest theory is the switch is not calculating the power budget based on actual power consumption like it should but rather maximum power consumption. PoE+ can deliver up to 30w per port
24 ports delivering power x 30w per port = 720w
The total power budget for the switch is 740w. If one more port were powered it would jump over the power budget. If the switch is not calculating the power budget correctly, this is a software issue. I will do some digging along these lines. The other way to handle this is to change poe from "class" to "static" and set max power on each port to 15w (740w total divided by 48 ports = 15.4w per port). Setting it statically to 15w per port should be able to power up all APs easily since they only draw a bit more than 5w each
On the device A use this command substituting the interface of interest.
show arp interface ge-0/0/0.0
This will show the mac and ip address of connected other interfaces.
If none show up, issue a ping to the addresses in the subnet of the interface and check again afterwards for the refreshed mac listing.
As I mentioned in an earlier post, we have these WiFi APs patched into this switch for nearly 3 years. During that time we have upgraded Junos on this stack 4 or 5 times meaning a reboot. There was never a problem to now. The only change is we are nowing using lldp-med since installing a new phone system in the past month. We have always had lldp enabled but just recently added lldp-med. I know that lldp and lldp-med has capabilities around PoE. I wondering if the addition of lldp-med somehow changes the PoE parameters for this switch and now the switch thinks its PoE power budget is exhausted?
A simple way would be to check the exact IP subnet configured on Device A interface.
If it is connected to a Switch/Router then usually it is a point to point link so it could be /31 or /30. So it should tell us what could be the ip address on the other side.
If the interface is connected to the host/server then i believe we can check with lldp output as well (provided that it is configured on the other side).
If not then we might have to use the method of firewall logs etc...
Show lldp neighbor
Hope this helps.
Hello,
I need a little help someone to validate is this normal working configuration.
The question is about the vme port of EX3400 switch (version 15.1X53-D57.3 )
The topology is attached to this post.
Will this configuration cause a loop or some problem ?
Here is the configuration for the vme port:
web-management {
https {
system-generated-certificate;
interface [ irb.8 irb.2016 vme.0 ];
-------
unit 0 {
family inet {
address 192.168.78.21/24;
}
}
---------
routing-options {
static {
route 192.168.22.101/32 next-hop 192.168.78.1;
route 192.168.22.111/32 next-hop 192.168.78.1;
}
}
I'm asking about this, because after few months operating OK in this way, the switch was rebooted after utility power loss. After that, it was working fine for 2-3 days and in one moment, we've lost access to it and to all device connected to it. We tried to reboot again but it was inaccessible until we disconnected the MGM port because we were trying to connect to it with laptop directly and in this moment (after few seconds) everything start working again.
BUT ! when we connected the laptop it was working OK for few minutes and then suddenly it stopped again (it was inaccessible for other front ports connected devices, the mgm(vme) port was accessible in this moment). We tried of course to disconnected the mgm port again with hope this will fix the issue, but unfortunately it doesn't. There was a "minor alarm" for low disk space so we issued the command to clean up files and the switch started to work again.
Now it's working fine for 5 days but with mgm(vme) cable disconnected!
Can someone give a clue for this strange behavior?
Regards,
Georgi
Hi Georgi M,
Why is the mgmt VLAN (vlan 78) trunked to the uplink port? If that's being done for some good reason (users also exist in vlan 78) then it can potentially create a flood on the mgmt port. Please remove vlan 78 from the uplink/trunk and connect the mgmt port back again. See if we are good.
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .
Hi,
We use vlan 78 only for managing device(no users) in both locations. It's in the trunk because of the DGS-1210-28 mgm access (192.168.78.22). It's the untagged vlan in the trunk between them.
You've said to connect the mgm port again... how? with direct cable between one front port and mgm port? Is this a valid ?
Regards,
Georgi
Hi Georgi M,
In other words, the mgmt port is meant for out-of-band access and your physical connection from the mgmt port to the mgmt access switch (DGS-1210-28) is enough to provide access to the switch. Please see this:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB10880&cat=EX_SERIES&actp=LIST
Also, routing other vlan subnets via the mgmt network is not advisable like this. What are these /32 IPs and intention of having these static IPs? Please refer the above KB for simple config to get mgmt access working. That also applies when configuring the vme: https://kb.juniper.net/InfoCenter/index?page=content&id=KB11044&cat=EX4200_1&actp=LIST
static {
route 192.168.22.101/32 next-hop 192.168.78.1;
route 192.168.22.111/32 next-hop 192.168.78.1;
}
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .