Quantcast
Channel: All Ethernet Switching posts
Viewing all 10307 articles
Browse latest View live

Re: Juniper EX4300MP activity LED's

$
0
0

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?


Re: Juniper EX4300MP activity LED's

$
0
0

@jonashauge - great minds think alike -Smiley Happy   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

Re: Network Time Protocol (NTP) Mode 6 Scanner vulnerability

$
0
0

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.

Re: Network Time Protocol (NTP) Mode 6 Scanner vulnerability

$
0
0

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?

Re: Network Time Protocol (NTP) Mode 6 Scanner vulnerability

EX4300 - Check-out failed for Chassis control process

$
0
0

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.

Re: Network Time Protocol (NTP) Mode 6 Scanner vulnerability

$
0
0

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/InfoCenter/index?page=content&id=JSA10613&actp=METADATA and PR 1234119 https://prsearch.juniper.net/PR1234119

 

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.

Re: Juniper EX4300MP activity LED's

$
0
0

Thanks for the update.  Glad the fix is in and working.

 


Re: EX4300 - Check-out failed for Chassis control process

$
0
0

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

how to find IP address of other end interface link connected to neighbor machine

$
0
0

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

Re: how to find IP address of other end interface link connected to neighbor machine

$
0
0

 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

 

https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-firewall-log.html

 

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 Smiley Happy.

Re: EX4200, PoE not working on all ports

$
0
0

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

Re: how to find IP address of other end interface link connected to neighbor machine

$
0
0

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.

 

Re: EX4200, PoE not working on all ports

$
0
0

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?

Re: how to find IP address of other end interface link connected to neighbor machine

$
0
0

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.

 

 


Is this a valid EX3400 vme port configuration

$
0
0

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

 

Re: Is this a valid EX3400 vme port configuration

$
0
0

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 Smiley Happy.

 

Re: Is this a valid EX3400 vme port configuration

$
0
0

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

Re: Is this a valid EX3400 vme port configuration

$
0
0
Hi Georgi_M, You don't need to trunk vlan 78 to DGS-1210-28. The accept port to the mgmt port should be sufficient and the default gateway will be out of the vme itself. Where does the rest of the mgmt network access request come from? I'm assuming that will be from behind the DGS-1210-28. In that case it will be switched to the mgmt port. Hope this helps. Regards, -r. -------------------------------------------------- If this solves your problem, please mark this post as "Accepted Solution." Kudos are always appreciated Smiley Happy.

Re: Is this a valid EX3400 vme port configuration

$
0
0

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 Smiley Happy.

Viewing all 10307 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>