If you can confirmed not seen in 18.2R3-S2+ that would be great to know.
Thanks
↧
Re: NULL ifd for bcm port
↧
Re: NULL ifd for bcm port
Hello Rccpgm,
Greetings!.
Thanks for the reply.
As far as my understanding goes, the log messages are suppressed in 18.2R3-S2 and above versions. The issue shouldn't be seen on the 18.2 release as it is the recommended Junos version for EX2300 specifically.
Link for Junos Software Versions - Suggested Releases to Consider and Evaluate
https://kb.juniper.net/InfoCenter/index?page=content&id=kb21476&act=login#ex_series
In may JTAC cases, I see the customers have upgraded the device to solve the issue.
Also, From the above comment section by @NYSED-netadm, he has faced the same issue and claims he has got it resolved by upgrading the device to 18.2R3-S2.9.
Hope this helps. Hit a Kudos if you felt this as informative.
Best Regards,
Lingabasappa H
↧
↧
Re: NULL ifd for bcm port
I would mark as "Accepted as Solution" but I think only originated can do this - Thanks.
↧
Re: NULL ifd for bcm port
Hello Rccpgm,
Thanks for appreciating me with kudos.
Hey Guillermo.gerbatin,
Please go through the conversation and comments and let me know that answers your query.
If you find the answers to be precise and correct, please mark the solution as accepted which will help others to go through the solution given by me.
I hope this helps. Please mark "Accept as solution" if this answers your query.
Kudos are appreciated too!
Best Regards,
Lingabasappa H
↧
LOOP protection in RSTP
Normally, in RSTP when ALT port can't receive the bpdu from designated port ( ONLY bpdu packets can't through some transmission device between 2 switches ,but the physical link is normal ) ,it will be in Forward .But if the path from nonroot brigde to root bridge is also noraml . LOOP and BROADCAST Storm will occur.
I set bdpu-timeout-action block under the ALT port in rstp to avoid the situation above. That means when the ALT interface can't receive the bpdus from designated port it will be still in BLK (Role 
IS (Loop-Prev) ).
Details : set protocols rstp interface ge-0/0/2 bpdu-timeout-action block
But there IS the other problem that if the primary link is down and also the ALT interface is in BLK with Role IS (Loop-Prev). The ALT interface won't be forward . I have toally down .
Any command to aviod that even though the ALT interface in BLK (Loop-prev ) ,it will be forward when primary line(the path from nonroot brigde to root bridge) is down ?
↧
↧
Re: BPDU protection is RSTP
Hi,
Please know that the interface in "Loop-Incon" state will recover itself and transition to its original state (ALT) when it receives BPDUs.
There's one other option you can consider if the port may need to still go to forwarding state i.e. to use "bpdu-timeout-action alarm" instead of "block". With "alarm" action configured, if the port doesn't receive BPDUs then the port moves to designated port role and forwarding (FWD) state once the max-age timer expires (~6-40secs), and we can see the event logged:
Example:
Loop_Protect: Port ge-0/0/1.0: Received information expired on Loop Protect enabled port
However there's a tradeoff to make here depending on the network/chances of either issues (issue causing switch not sending BPDU on non-designated ports versus actual port issues on designated-ports).
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated![Smiley Happy]( "Smiley Happy")
.
Please know that the interface in "Loop-Incon" state will recover itself and transition to its original state (ALT) when it receives BPDUs.
There's one other option you can consider if the port may need to still go to forwarding state i.e. to use "bpdu-timeout-action alarm" instead of "block". With "alarm" action configured, if the port doesn't receive BPDUs then the port moves to designated port role and forwarding (FWD) state once the max-age timer expires (~6-40secs), and we can see the event logged:
Example:
Loop_Protect: Port ge-0/0/1.0: Received information expired on Loop Protect enabled port
However there's a tradeoff to make here depending on the network/chances of either issues (issue causing switch not sending BPDU on non-designated ports versus actual port issues on designated-ports).
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated
.
↧
EX3400 DHCP Snooping not working?
Hi all,
I've searched around Google/these forums for many hours and have looked at many a thread and Juniper TechDoc. I cannot seem to validate that DHCP snooping is 1.) configured correctly and 2.) actually working. Relevant config snippets are below.
Switch version: 18.2R3-S2.9
daxter@EX3400-24P> show configuration vlans WLAN
vlan-id 20;
forwarding-options {
dhcp-security {
arp-inspection;
ip-source-guard;
}
}
And as you can see, there is no DHCP snooping options for validation commands.
daxter@EX3400-24P> show dhcp ?
Possible completions:
client Show DHCP client information
relay Show DHCP relay information
server Show DHCP server information
statistics Show DHCP service statistics
{master:0}
↧
Re: EX3400 DHCP Snooping not working?
Hi Daxter,
1) Configuration -> To enable DHCP snooping, you need to do is enable dhcp-security for that specfic VLAN and I see that is already done. So the DHCP snooping database table must be already built and being updated dynamically for this VLAN WLAN. ARP inspection and IP-source-guard are additional port security features which also make use of the DHCP snooping database.
2) Actually Working -> You can check the DHCP snooping database to verify if its working for which you can use the command "show dhcp-security binding". For DHCPv6, "show dhcp-security ipv6 binding"
Please refer to https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-dhcp-security-binding.html for example outputs.
Hope this helps.
Thanks and Regards,
Pradeep Kumar M
|| If this solves your problem, please mark this post as "Accepted Solution" so we can help others too ||
↧
Re: EX3400 DHCP Snooping not working?
"show dhcp-security binding"
Wow I'm dumb. I didn't even notice this was an option. Thank you for setting me straight!
I have no binding entries for some reason. I'm thinking this is because of the default switch behavior of trusting trunk ports. Unfortunately, my access points require the port to be a trunk. I see on the EX3400 with ELS, there is no way to "untrust" a trunk port. So this feature is essentially useless on this platform it seems.
↧
↧
LLDP table uses ID
Hey Guys,
I have a python script which constructs LLDP frame and sends it to the switch, example capture:
07:52:50.282224 LLDP, length 50
Chassis ID TLV (1), length 18
Subtype Local (7): 48:df:37:9c:fb:78
0x0000: 0734 383a 6466 3a33 373a 3963 3a66 623a
0x0010: 3738
Port ID TLV (2), length 5
Subtype Local (7): eth5
0x0000: 0765 7468 35
Time to Live TLV (3), length 2: TTL 120s
0x0000: 0078
Port Description TLV (4), length 4: eth5
0x0000: 6574 6835
System Name TLV (5), length 9: detcatod1
0x0000: 6465 7463 6174 6f64 31
End TLV (0), length 0But when I attempt to fetch lldp neighbors I see this:
dudib@det_EX4600# run show lldp neighbors interface xe-0/0/2 LLDP Neighbor Information: Local Information: Index: 927 Time to live: 121 Time mark: Sun May 10 08:01:14 2020 Age: 27 secs Local Interface : xe-0/0/2 Parent Interface : - Local Port ID : 516 Ageout Count : 0 Neighbour Information: Chassis type : Locally assigned Chassis ID : 39373638-3935-5A43-4A39-333930353536 Port type : Mac address Port ID : 48:df:37:9c:fb:78 Port description : Embedded ALOM, Port 2
I have EX4600 switch, and in EX4550 this problem doesn't reproduce.
I want the Port Description to be eth5 and System Name to be shown, also I don't know why the chassis ID is that and not 48:df:37:9c:fb:78.
Thanks in advance
↧
Re: LLDP table uses ID
Hi DudiB,
The LLDP defaults differ, so please try to play with "port-description-type" and "port-id-subtype" under "set protocols lldp" and verify results.
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .
↧
Re: LLDP table uses ID
Hey mriyaz!
Thanks for the response, I was trying to play with those settings but no luck..
In addition I noticed weird behaviour - I cleared the table and it populated back before my host sent the LLDP packet..
Could there be some bug around this? we're using Junos: 17.3R3-S4.2
And this problem reproduces to all of our EX4600 models.
↧
Re: EX3400 DHCP Snooping not working?
Use 18.4R1 or higher. Untrust on Trunk supported added there.
https://apps.juniper.net/feature-explorer/feature-info.html
fKey=8547&fn=Untrusted%20mode%20on%20trunk%20port
I would suggest using latest 18.4 S-release, which is 18.4R3-S2 (found under Junos SR for OS).
Get back with your results.
↧
↧
Re: LLDP table uses ID
Hi DudiB,
If you're using the port-id subtype interface-name and the neighbor (in your case crafted) has this configured as well, this should work. Could you try this setting?
root@QFX# set protocols lldp neighbour-port-info-display ? Possible completions: port-description Display port description of neighbor in port info port-id Display port-id information of neighbor in port info
Regarding chassis ID, please try to make the Chassis ID subtype to 4 and then send the MAC, that should work I think.
04:38:47.621060 In -----original packet----- 0c:86:10:80:b1:05 > 01:80:c2:00:00:0e, ethertype LLDP (0x88cc), length 339: LLDP, length 325 Chassis ID TLV (1), length 7 Subtype MAC address (4): 0c:86:10:80:b1:00 0x0000: 040c 8610 80b1 00 Port ID TLV (2), length 4 Subtype Local (7): 520 0x0000: 0735 3230
Hope this helps.
Regards,
-r.
--------------------------------------------------
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .
↧
Re: EX3400 DHCP Snooping not working?
Running the new software and setting an override for the trunk port - I have DHCP snooping bindings now. A new issue has cropped up, however. The software does not allow "overrides untrust" to be configured with "ip-source-guard".
I'm starting to regret buying Juniper
↧
Re: EX3400 DHCP Snooping not working?
From your response, I can only assume you are new to Juniper EX products. I also assume your requirement if some port level security for WLAN/AP network. Do whose switches were you using previously, with this WLAN network? I sort of assume the WLAN is not new, so from which vendor is your WLAN? What was the previous configuration on your old switches?
I assume you are looking to enable DHCP Snooping on a Tagged Interface, which you then want to be untrusted. So under vlans vlan-name forwarding-options you have set dhcp-snooping with set arp-inspection and set overrides trusted. I assume when you then try and add set ip-source-guard, you now receive a commit error?
Maybe you could send your most current config, and what the commit error is?
↧
Re: EX3400 DHCP Snooping not working?
I am new to EX switches and JunOS. This is a switch in my home lab. I use various L2 security features (dhcp snooping, DAI, ip source guard) on my guest wireless network. I've used Aruba/Cisco previously. Both would allow all three of these features to be enabled simultaneously. There's no sense in trusting a trunk port by default. My DHCP server is only off one trunk, so only that one trunk should be trusted. It's kinda dumb that Juniper enforces this by default.
WLAN access points are Ruckus. No controller/mesh. Just standalone APs.
"set overrides trusted" makes any port in that group trusted, which is not what I want. I had "set overrides untrusted" in the group and attached the trunk ports. The commit error simply states that ip-source-guard cannot be enabled with any overrides.
↧
↧
Re: migrating from cisco to juniper EX3400 VC
I remember I tool to migrate from legacy to ELS, but I don't remember any tool for Cisco to Juniper
What configuration do you need to migrate?
↧
Re: Switch in 4300-MP virtual chassis shuts down PPMD_PFE_SHUTDOWN
Please provide these outputs
show chassis routing engine
show system core-dump
↧
Re: Switch in 4300-MP virtual chassis shuts down PPMD_PFE_SHUTDOWN
Regarding the messages you are wondering:
Sep 5 03:36:47.577 2260-ex4300 ppmd[7538]: %DAEMON-3-PPMD_PFE_SHUTDWN: PPMD: Connection Shutdown/Closed with PFE: fpc2
Sep 5 03:36:47.944 2260-ex4300 ppmd[7538]: %DAEMON-3-PPMD_PFE_SHUTDWN: PPMD: Connection Shutdown/Closed with PFE: fpc2
Like my colleague mention, this are normally due to high CPU on the device.
Since these are related to high CPU a PR cannot be open since it’s not affecting a specific Junos release and we can see that this could be due to kernel being busy.
Also as a site note you can also be getting this messages so please take a look at the logs carefully.
ex4300 kernel: %KERN-5: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 7200000/75000/8
ex4300 kernel: %KERN-5: tcp_timer_keep:Local(0x80000001:52699) Foreign(0x80000001:9500)
ex4300 kernel: %KERN-5: tcp_timer_keep: Dropping socket connection due to keepalive timer expiration, idle/intvl/cnt: 7200000/75000/8
ex4300 kernel: %KERN-5: tcp_timer_keep:Local(0x80000001:52565) Foreign(0x80000001:9500)
ex4300 kernel: %KERN-5: tcp_timer_keep: Dropping socket connection due to keepalive timer
For these messages, there are already some PRs created:
https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1363186
https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1209847
However unless we get more information providing an even more accurate explanation will be really hard to tell so I would suggest you to open a case if you feel more investigation is needed.
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated .
↧