What is the Juniper command used to clear the alarm from the switch (EX4300)?
Here is the displayed alarm message: Major FPC 0 Fan & PSU Airflow direction mismatch
↧
Re: Airflow direction mismatch alarm
↧
Re: Airflow direction mismatch alarm
@Freemind/clawrence:
If there's a genuine mismatch in air flow, then there's no way to clear the alarm.
However if you have managed to tamper and reversed the polarity then the alarm might clear. If there is no mismatch physically and yet you see this alarm, please try the following command:
set chassis alarm management-ethernet link-down ignore
There was a cosmetic glitch in some cases that causes the management link down to be read as an airflow mismatch alarm PR1327561 (resolved on 17.2).
Note that physically modifying the PSU isn't recommended and replacing it with the right part is best; especially if you may need an RMA some day.
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated 
.
↧
↧
SRX1500 HA Port L2 transport via QFX5110
Hi,
I currently have an SRX1500 cluster configured and working correcty. However, one of the nodes needs to be relocated to our second data center.
Obviously, this means that I will need to have the dedicated HA Control ports via Layer 2, in my case a QFX5110 cluster at each site.
I have tested via the local QFX5110 cluster but I am not receiving a link light on either control port on either nodes.
The VLANs used on the QFXs are access but when connected, there are no link lights on the control port.
Has anyone created the cluster via L2 and specifically on the SRX1500 with the Dedicated port.
FYI, IGMP Snooping is disabled on the QFX.
Any assistance would appreicated.
↧
Dot1x supplicant multiple with mixed clients (dot1x and mac-radius)
Hi, I'm trying to setup a port on our EX3300 (12.3R12-S7) to support multiple supplicants; I followed the configuration example found here: https://kb.juniper.net/InfoCenter/index?page=content&id=KB29795&cat=EX8216_1&actp=LIST
The port is connected to a managed, non Juniper switch, where clients are connected to. The clients are a Windows PC using 802.1x and a phone using MAC RADIUS; the managed switch is seen as a third device, using MAC RADIUS as well.
The clients can authenticate just fine if they are connected directly to the EX3300; when connected through the switch in the middle, only the phone can authenticate while the PC returns an authentication error.
The logs on the RADIUS server show that the PC is trying to connect using MAC RADIUS, while it should use 802.1x instead.
I found there is an authentication-order parameter to set the order in which authentication methods should be used, but it's been introduced in release 15.1R3: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/authentication-order-edit-authenticator.html
Does anybody know if there is a similar parameter in release 12.3? Or how to solve the issue described above without this parameter?
Thank you,
Marco
↧
Devices not receiving IP addresses
I have a building with 2 EX2200 24 port switches. One covers the front half the other the back. Multiple devices are unable to get ip address from the front switch. We have users that travel and upon returning they can't pick up an IP and we've had to put in statics. There is no dhcp pool configured on it. What can I look at to see why I'm not getting IPs? Leaving work so I won't be able to post config pics until Monday.
↧
↧
NSX versus EVPN
I have a customer who is evaluating using NSX for control plane for VXLAN traffic or simply use EVPN with their Juniper switches. I can't seem to find good documentation on one versus the other. While EVPN uses BGP (which is a more standard and robust protocol), OVSDB also achieves the purpose. Customer is also planning to have multiple sites and wants to enable communication between them. Can someone help me evaluate which option will be better?
↧
Re: NSX versus EVPN
Generally, the question is NSX vs Contrail, not NSX versus EVPN. I think you are really asking OSVDB vs EVPN. EVPN is an open standard, which should [eventually] provide interoperability between different vendors. OSVDB came from VMWare, via Nicira, and I think now is IETF draft standard. Many switch/router vendors, Juniper being one, support OSVDB (and EVPN as well) to interoperate with VMWare, but this may only be on a limited set of products.
As far as I know, and what little I know, NSX and VMWare are both generally closed systems. So if you expect NSX to manage other types of VMs (KVM and HyperV come to mind), that is unlikely to happen. This is a major difference today between NSX camp and Contrail.
Containers may change all of this, . . .
↧
Re: Devices not receiving IP addresses
Is the DHCP server is in same VLAN or differnet VLAN ? If it is different VLAN where we have configured the DHCP relay.
If we have L3 interface for the VLAN, are able to ping the DHCP server from this interface.
You can verify all these steps.
-Kiran
wrote: I have a building with 2 EX2200 24 port switches. One covers the front half the other the back. Multiple devices are unable to get ip address from the front switch. We have users that travel and upon returning they can't pick up an IP and we've had to put in statics. There is no dhcp pool configured on it. What can I look at to see why I'm not getting IPs? Leaving work so I won't be able to post config pics until Monday.
↧
Re: EX3300 - Sub Interface (New to Junos)
I'm trying to apply the sub-interface but I'm getting the following:
[edit vlans Mail l3-interface]
'l3-interface vlan.25'
Interface must already be defined under [edit interfaces]
error: commit failed: (statements constraint check failed)
Mail {
vlan-id 25;
##
## Warning: Interface must already be defined under [edit interfaces]
##
l3-interface vlan.25;
↧
↧
Re: EX3300 - Sub Interface (New to Junos)
You are missing interface config (under edit interfaces) with keyword "vlan". You need to add something like:
set interfaces vlan unit logical-unit-number family inet address inet-address
with logical-unit-number probably equal to 25 (match vlan-id - best practice).
↧
Re: Devices not receiving IP addresses
DHCP is configured on a router and all of the switches are L2.
↧
Re: NSX versus EVPN
Thanks for your response. I agree that NSX is more of a closed system, and may not have good support for Hyper-V as well.
One thing which i found favorable in NSX is that the configuration is easier. The VXLAN-VLAN bindings are configured through the NSX controller and also the L3 routes for communicating with the physical network. And this information is sent to the switches over the OVSDB schema. With EVPN, all the bindings and the customer information must be plumbed manually on the switches and this can be cubmersome for large deployments.
On the other hand, BGP is a more robust protocol and the chances of interoperability are much higher in the future. Moreover, there is no dependancy on a controller.
↧
Re: NSX versus EVPN
I think it really boils down to what the customer requirements are i.e. software/hardware VTEPs, scaling requirements etc. I've worked on a couple of scenarios that resulted in an NSX overlay within the virtualised infrastructure with a separate EVPN-VXLAN overlay in the physical network. NSX works well in VMware only environments and is pretty much fully integrated with vCenter. With regards to multiple sites, do you require L2 stretch between the sites or all L3? OVSDB with NSX is only used when integrating hardware VTEPs, or L2 bridging. I've never seen this deployed in production and the general feeling is to steer away from mixing hardware/software VTEPS. With regards to configuration, it's very unlikely that you would manually administer an EVPN overlay. Typically automation techniques and tools would be used.
Highlights
EVPN :
Industry standard adopted by all major vendors.
Provides a clear demarcation between Network and infrastructure
With the use of EVPN as the control plane, hardware VTEP gateways can support different modes of redundancy such as All-Active or Single-Active multihoming.
Hardware VTEP gateways offer high-density, high-performance and better scale.
For larger deployments, if there are a large number of BMSs that need to communicate with the virtualized workloads, or if there is need to handle large traffic volumes, then a high throughput hardware gateway offers a better solution.
Based on the desired deployment requirements, hardware VTEP gateways can be used to provide physical-physical (BMS-BMS), virtual-virtual (VM-VM) or virtual-physical (VM-BMS) connectivity.
Distributed model
NSX:
Centralised SDN based network overlay
Provides a logical network and security management plane, control plane and data plane functionality
Extends logical switch to support routing in the hypervisor (DLR)
NSX Edge can be for routing and for stateful services such as firewall and load balancing
VXLAN is used for transport networks
NSX controllers maintain and control the distribution of MAC / IP information to hosts
Does NOT natively support multi-tenancy. Requires 1 logical switch per tenant.
I would also suggest you take a look at Contrail as an alternative to NSX, as suggested by rccpgm
I hope this helps
↧
↧
Re: Devices not receiving IP addresses
What are the physical connections from the two ex to the router?
Are the devices on the working ex in the same vlan as the ones not working?
Is the router dhcp server setup for each vlan that needs dhcp or do you have forwarding configured on the ex?
↧
Re: Devices not receiving IP addresses
They're connected to one router by fibre which is connected to the router hosting the DHCP server by two T1 lines. The DHCP router is in another city. The two exs do host different VLANS and the majority of devices connected to each switch work. I can disconnect and reconnect devices that were plugged into jacks before this issue occured and they'll still pick up the same IP. I didn't originally setup the switches so I'll have to look when I get back to work.
↧
Re: jdhcpd: DH_SVC_SENDMSG_FAILURE
How to solve this.
↧
Re: jdhcpd: DH_SVC_SENDMSG_FAILURE
check you configuration
↧
↧
Re: jdhcpd: DH_SVC_SENDMSG_FAILURE
Seems like you have dhcp configuration on few ports which are not up. If dhcp is not required on those ports, please delete the dhcp on those interfaces and check if it resolves the issue.
By default system would have configured dhcp for ZTP on few interfaces. If the interface is down and there is dhcp traceoptions configured, you will see these continuous log messages.
Ex: For QFX following default configuration will be enabled for Zero Touch Provisioning.
If any of the interface em1.0 /irb.0 / vme.0 is down then the error messages "DH_SVC_SENDMSG_FAILURE" appear in the log.
set system processes dhcp-service traceoptions file dhcp_logfile
set system processes dhcp-service traceoptions file size 10m
set system processes dhcp-service traceoptions level all
set system processes dhcp-service traceoptions flag all
set interfaces em1 unit 0 family inet dhcp vendor-id Juniper-qfx5100-96s-8q
set interfaces irb unit 0 family inet dhcp vendor-id Juniper-qfx5100-96s-8q
set interfaces vme unit 0 family inet dhcp vendor-id Juniper-qfx5100-96s-8q
In above example if dhcp on vme is not required and that interface is down then "delete interfaces vme unit 0 family inet dhcp" would stop the log messages "DH_SVC_SENDMSG_FAILURE" .
↧
Re: NSX versus EVPN
Thanks. This is super helpful.
↧
QFX 5100 - QSFP Ports don't come up automatically*
Hello,
We have a QFX 5100 connected to a MX480 via 2x QSFP to 4x SFP+ Breakout cables.
We have an issue where after a power failure or powering on both the MX480 and QFX at the same time the QSFP ports do not come up automatically even after 20 minutes. We have to unplug the QSFPs and re-connect them for it to come up.
The MX480 shows links on the interfaces connected to the QFX but the QFX does not display any link lights and has the error (on all QSFP ports)
run show interfaces xe-0/0/48:0 error: device xe-0/0/48:0 not found
However:
If we power on the MX480 first, wait approx 15mins for it and the line cards to fully boot, and then power on the QFX, the links will come up shortly after the QFX boots. And vica versa; if we power on the QFX wait for it to fully boot, then power on the MX480, it will get a link and be able to ping between the two.
We need the links to establish without manual human input in the event of a power failure where both devices would be booting at the same time.
Is there anything that can be done/configured to resolve this?
Config on the QFX relating to the ports/ae going to the MX. (0/0/49 has the same config - ommitted below)
show | match 0/0/48 | display set set interfaces et-0/0/48 unit 0 family ethernet-switching vlan members default set interfaces et-0/0/48 unit 0 family ethernet-switching storm-control default set interfaces xe-0/0/48:0 description ** set interfaces xe-0/0/48:0 ether-options 802.3ad ae0 set interfaces xe-0/0/48:1 description ** set interfaces xe-0/0/48:1 ether-options 802.3ad ae0 set interfaces xe-0/0/48:2 description ** set interfaces xe-0/0/48:2 ether-options 802.3ad ae0 set interfaces xe-0/0/48:3 description ** set interfaces xe-0/0/48:3 ether-options 802.3ad ae0 set protocols rstp interface et-0/0/48 set interfaces ae0 aggregated-ether-options link-speed 10g set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk set interfaces ae0 unit 0 family ethernet-switching vlan members vlan801
Config on the MX480 relating to the ports/ae going to the QFX.
set interfaces xe-0/1/0 gigether-options 802.3ad ae2 set interfaces xe-0/1/1 gigether-options 802.3ad ae2 set interfaces xe-0/1/2 gigether-options 802.3ad ae2 set interfaces xe-0/1/3 gigether-options 802.3ad ae2 set interfaces xe-0/1/4 gigether-options 802.3ad ae2 set interfaces xe-0/1/5 gigether-options 802.3ad ae2 set interfaces xe-0/1/6 gigether-options 802.3ad ae2 set interfaces xe-0/1/7 gigether-options 802.3ad ae2 set interfaces xe-3/1/0 gigether-options 802.3ad ae2 set interfaces xe-3/1/1 gigether-options 802.3ad ae2 set interfaces xe-3/1/2 gigether-options 802.3ad ae2 set interfaces xe-3/1/3 gigether-options 802.3ad ae2 set interfaces xe-3/1/4 gigether-options 802.3ad ae2 set interfaces xe-3/1/5 gigether-options 802.3ad ae2 set interfaces xe-3/1/6 gigether-options 802.3ad ae2 set interfaces xe-3/1/7 gigether-options 802.3ad ae2 set interfaces ae2 description ** set interfaces ae2 aggregated-ether-options minimum-links 1 set interfaces ae2 aggregated-ether-options link-speed 10g set interfaces ae2 aggregated-ether-options lacp active set interfaces ae2 unit 0 family bridge interface-mode trunk set interfaces ae2 unit 0 family bridge vlan-id-list 801 set interfaces ae2 unit 0 family bridge vlan-id-list 804
↧