All Ethernet Switching posts

We are working on getting notifications for ports that go into a BPDU state when a loop happens. And once again the newer EX-2300 switches are causing issues. (I really hate how inconsistent these switches are.)

So we have a trap receiver set up and we are sending BPDU traps to it. What we can NOT find is how to tell an EX-2300 to send a trap when a port comes out of a BPDU state and is back up and running correctly.

So to further clarify. On a EX-2200 or EX-3300 you need to tell the switch to send a trap based on:

set event-options policy snmptrap events ESWD_BPDU_BLOCK_ERROR_DISABLED
set event-options policy snmptrap events ESWD_BPDU_BLOCK_ERROR_ENABLED
set event-options policy snmptrap then raise-trap

(There is more to the config than the above but in general those are the settings needed for the trap.)

So the "DISABLED" is a port going into a blocked state and the "ENABLED" is it coming out (and yes, it still can go right back into a blocked state if the loop still exists). All of this works as it should and has an expected outcome. We get the traps correctly sent to the trap server.

Our problem comes in with an EX-2300. So to monitor a port getting blocked by a loop:

set event-options policy snmptrap events "L2CPD_RECEIVE_BPDU_BLOCK_ENABLED: BPDU_PROTECT"

The above works sending the trap for a port going into a blocking state. What we can't find is the correct event-options policy to send a trap when it comes out of a blocking state.

From what we've read the documentation all points to the same web pages for doing this for either type of EX switch... none seem to show an ELS level switch and sending an SMMP trap message for it coming out of a blocked state.

From the messages logs you get:

Oct 21 08:25:59 cl2ntt18 l2cpd[5503]: L2CPD_RECEIVE_BPDU_BLOCK_ENABLED: BPDU_PROTECT: Interface ge-0/0/35 is DOWN: BPDU error detected
Oct 21 08:25:59 cl2ntt18 l2cpd[5503]: L2CPD_RECEIVE_BPDU_BLOCK_ENABLED: BPDU_PROTECT: Interface ge-0/0/34 is DOWN: BPDU error detected
Oct 21 08:26:59 cl2ntt18 l2cpd[5503]: BPDU_PROTECT: Interface ge-0/0/35 is UP: BPDU error Cleared
Oct 21 08:26:59 cl2ntt18 l2cpd[5503]: BPDU_PROTECT: Interface ge-0/0/34 is UP: BPDU error Cleared

But trying (we've tried a bunch of variations of the above in the policy - none have worked):

set event-options policy snmptrap events BPDU_PROTECT

Is NOT enough to have the trap sent to the trap receiver.

Any idea how to get an EX-2300 to send a trap message when a port comes out of a BPDU blocking state?

Unfortunately, the booting to the alternate slice did not help. I ended up having to install from USB and formatting the disk in the process:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB20643

This process was relatively painless and very simple.

No sure if its related but everytime the switch reboots it member 0 falls back to the older firmware that is on the backup flash, upgraded the switch the primary partition is on 15.1R7 and the backup is on 15.1R5 performed snapshot of alternate slice but instead of flashing the da0sa2 with 15.1R7 it flashed the primary back to 15.1 R5 and now both the partitions are on 15.1R5 again and the switch continues to reboot.

Hi all,

I have a server connected to an EX3400. The server is at 1g/Full-duplex (autonegotiation). However, I am seeing the following errors

Input errors: Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0 Output errors: Carrier transitions: 6, Errors: 0, Drops: 70542, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0 Egress queues: 12 supported, 8 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 0 15712340 70542 1 0 0 0 2 0 0 0 3 0 0 0 8 0 31986728 0 9 0 0 0 10 0 0 0 11 0 0 0 Queue number: Mapped forwarding classes 0 best-effort 1 expedited-forwarding 2 assured-forwarding 3 network-control 8 mcast-be 9 mcast-ef 10 mcast-af 11 mcast-nc

The interface config is pretty simple, nothing fancy

XYZ@123> show configuration interfaces ge-0/0/12 native-vlan-id 50; unit 0 { family ethernet-switching { interface-mode trunk; vlan { members 50-51; } } }

The issue I am facing is low download speed. Can someone please help me understand what should I do to fix this Drops?

Thanks

It looks to me like it's dropping traffic only from the BE queue.

Do you have any class of service configured?

Please run:

show configuration class-of-service

Hi everyone.

https://www.juniper.net/documentation/en_US/junos/topics/concept/rate-limiting-storm-control-understanding.html

According to the documentation above:

"A traffic storm is generated when messages are broadcast on a network and each message prompts a receiving node to respond by broadcasting its own messages on the network."

Can someone please give me an example of such a message?

Also, can such a storm happen if we have STP to prevent topology loops?

Thanks,

Deepak

Hi Luke, following is the output.

XYZ@123> show configuration class-of-service host-outbound-traffic { forwarding-class network-control; }

Hello,

The best example I can see - ARP broadcast (and all related to these issues)

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/using-storm-control-to-prevent-network-outages.html

This is not always triggered by L2 Loop - so the STP is not a key factor in here.

Hello.

On qfx5100-48s switch LED status and Chassis hardware status absent after upgrade JunOS starting from version 19.

For example, with version 18.1R3-S6.1 - LED Status is blinking and "show chassis hardware" show the "Xcvr 7 NON-JNPR MTC230307WR SFP-T". After upgarde to version 19 or 20 - LED light is off, and "show chassis hardware" show nothing, but interface work properly.

Is there a solution to the problem?

Hello,

it seems that your SFP-T with the S/N MTC230307WR is not a Juniper original SFP-T. 3rd party transceivers can work, but it is not guaranteed that they work. Sometimes there is some code change in newer JUNOS releases which prevent 3rd party transceivers to work. What sounds quite strange is that your interface works fine, but the transceiver is not showing up in the "show chassis hardware" output, this is almost impossible.

My personal experience is, that only original Juniper copper SFPs are working fine with Juniper devices (in contrary to fiber SFPs), 3rd party copper SFPs have huge problems.

If you want to check which Juniper copper SFPs are supported, you can find the full list here:

https://apps.juniper.net/hct/product/?prd=QFX5100

looks like something changed in 19.x/20.x code to make the recognition of the 3rd party SFP no longer be recognized. Just FYI, there should be no Junos code that 'disallows' any SFP (Juniper or 3rd party) from not working. Not recognized is one thing, not working is another. At same time Juniper does not guarantee any operation using 3rd party optics.

Options are as I see it:

1. Leave as is, as appears to be working, except for recognition.

2. Go back to manufacturer of Optic, and get them to change internal programming of their optic to work with Junos 19.x/20.x. There would be no-guarantee (from Juniper) that this will still work as desired come 21.x+ SW. Don't bother opening Juniper case, TAC does not work on 3rd party optic situations, like this one.

3. Go back to older code.

4. Purchase Juniper branded optics. Work with local partner/Juniper sales team get price closer to what you pay for 3rd party optics, which I assume is reason you went 3rd party in first place.

Good luck.

Thanks Andrei.

But receiving devices don't respond to ARPs with their own broadcast messages. I'm trying to figure out this sentence from the documentation.

"each message prompts a receiving node to respond by broadcasting its own messages on the network."

--Deepak

Hello

https://ijcsi.org/papers/IJCSI-8-2-456-460.pdf

This is one of the documents that describe them.

The ARP storm is just one of the possible reasons.

BR,

Andrei

Hi everybody,

I do understand why a lot of people would prefer working on Cisco. I need my client to boot from my PXE server on another subnet and I spent my day searching how to do it ... With a Catalyst, I did it in 30 seconds:

interface GigabitEthernet2/0.10
encapsulation dot1Q 10
ip address 192.168.1.250 255.255.255.0
ip helper-address 192.168.2.100
ip nat inside
!
interface GigabitEthernet2/0.20
encapsulation dot1Q 20
ip address 192.168.2.250 255.255.255.0
ip nat inside

With QFX ... ???

root> show version
fpc0:
--------------------------------------------------------------------------
Model: vqfx-10000

{master:0}[edit forwarding-options]
root# show
storm-control-profiles default {
all;
}
helpers {
tftp {
interface {
em0 {
server 192.168.2.100;
}
}
}
}

Regards,

Gueug

Hi,

Check this document, it has configuration for dhcp/bootp relay.

Tim

Greetings,

Juniper actually have some good articles explaining how to configure a pxe boot with multiple dhcp servers.

See the next example that I have with me from previous scenarios;

set forwarding-options dhcp-relay route-suppression destination

set forwarding-options dhcp-relay overrides allow-snooped-clients

set forwarding-options dhcp-relay overrides delete-binding-on-renegotiation

set forwarding-options dhcp-relay server-group DHCP-SERVERS 10.10.10.1

set forwarding-options dhcp-relay server-group DHCP-SERVERS 10.10.10.3 PXE

set forwarding-options dhcp-rela active-server-group DHCP-SERVERS

set forwarding-options dhcp-rela group DHCP-SERVERS interface irb.100

set forwarding-options dhcp-rela group DHCP-SERVERS interface irb.200

set forwarding-options dhcp-rela group DHCP-SERVERS interface irb.300

set forwarding-options dhcp-relay forward-snoped-clients configured-interfaces ---- > optional, only for mc-lag setting.

///////////

Set forwarding-options dhcp-relay forward-snooped-clients all-interfaces ->>>MC-LAG setup>> enables the ICL to forward DHCP receiving a DHCP request/ack when state is not present with Relay software it will drop by default, when this knob is configured it will forward it.

set forwarding-options dhcp-relay overrides allow-snooped-clients ->>>>> this will create state in DHCP relay wh (renew/inform) is received from Client for which state was not present

set forwarding-options dhcp-relay route-suppression destination ->>>>> Suppress installation of destination rout the access-internal option are mutually exclusive; however, the access-internal option also suppresses destination routes.

ref:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB29822&actp=METADATA

https://kb.juniper.net/InfoCenter/index?page=content&id=KB30596

If this help you to resolve your query please mark as resolved!

Thank you,

Esteban Montes

It would seem the config file needs to be corrected in the build. So this will need reapplied after a reboot.

Ive seen this on 20.1R1-S3.3 and 20.2R1-S2.1

Here is my quick fix.

run start shell user root
cd /var/etc
vi ttys

ttyu0 "/usr/libexec/getty std" vt100 on secure
ttyu1 "/usr/libexec/getty std" unknown on secure
ttyu2 "/usr/libexec/getty 3wire" vt100 onifconsole secure
ttyu3 "/usr/libexec/getty 3wire" vt100 onifconsole secure
ttyu4 "/usr/libexec/getty 3wire" vt100 onifconsole secure
ttyu5 "/usr/libexec/getty 3wire" vt100 onifconsole secure
ttyu1 "/usr/libexec/getty std" unknown on secure

!!! Delete the duplicate of ttyu1 at the bottom

:wg write quite and now restart the getty process

kill -HUP 1

JUST making note.. On my other 2300-c-12p my ttys looks like this
Only two lines.

ttyu0 "/usr/libexec/getty 3wire" vt100 on secure
ttyu1 "/usr/libexec/getty 3wire" unknown on secure

Hello,

Just as an idea, try this one

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/automation-using-correlated-events-to-trigger-an-event-policy.html

https://www.juniper.net/documentation/en_US/junos/topics/example/junos-script-automation-event-policy-controlling-using-regular-expressions.html

You will need to correlate the even with UP event.

PS:

I also found this one is very helpful

https://apps.juniper.net/syslog-explorer/

Andrei

Interesting... I'll have to look at these a bit more closely. But I'm not sure you can correlate it with an UP event(?). There's no guarantee that port(s) you are looking for will come back up to an active link state. I originally was thinking of looking for a link on the port with no corresponding BPDU down message to follow... but that logic fails if the loop is simply removed.

(Or I need to read the referenced web pages much more closely. Which I do plan to do.)

We did end up opening a TAC case for this although that is going rather slowly and still don't have a solution yet. It really feels to me that it is something that was missed and needs to be put back in place....(?) Hopefully the TAC case sheds some light on this.

We also have found the same behavior on a EX 3400 switch. It sends the trap for port down but nothing when it comes backup.

Thanks for the reply.

I see the point.

You can also look on this one:

https://www.juniper.net/documentation/en_US/junos/topics/example/junos-script-automation-event-policy-triggering-using-nonstandard-syslog-messages.html

You need to have sort of "BPDU related event" will it be UP or clear - so you need to trigger based on the match.

For sure there is a different direction

https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-script-automation-event-script-overview.html

so you can think to convert all this into an OP script +/or event script.

Andrei

The:

Using Nonstandard System Log Messages to Trigger an Event Policy

Looks promising. I'll have to try that since I do know what the log message looks like. I should be able to get that to work.

But I still question why the Trap doesn't seem to be there in the first place... similar to the 2200 and 3300: ESWD_BPDU_BLOCK_ERROR_DISABLED

followed by

ESWD_BPDU_BLOCK_ERROR_ENABLED.

It feels like the 2300 and 3400 should also have something similar. I guess we'll see what TAC says.

Or at least an explanation as to why it's not there.

Hi!

Today I was labbing something similar to this and I found you post. I know you created this topic about three years ago. Possibly you've resolved the issues in the mean time. Hopefully this message finds you well if you get a chance to read it in the future!

I have some remarks, I don't have your configurations / full topology available here so I cannot give 100% solid solutions and my own lab was not complete with enough equipment to even fully verify my own goals.

You wrote regarding unusable next-hop on P5-RR:

[quote]

---> it shows the next-hop as unsuable even though there is a route in inet.0

[/quote]

By default in JUNOS the next-hop for BGP VPN routes are resolved using RIB inet.3 . If not route is there, the VPN route becomes a Hidden route. How to resolve it? There are few options:

- run MPLS with e.g. LDP / RSVP. Active MPLS LSPs put a route in the RIB inet.3 so the route resolution succeeds

- configure static route in rib inet.3 (as you did)

- change the resolution ribs

- change MPLS route lookup

I think you're building an EVPN-VXLAN network, so it would be overkill to configure LDP / RSVP to create the inet.3 routes. Instead, on the RR (P5 router) you configured a static route in RIB inet.3 to resolve the unusable next-hops for RIB bgp.evpn.0. You can also configure a Discard next-hop instead of pointing it to "10.0.0.6 resolve". Or even simpler:

- set routing-options rib inet.3 static route 0/0 discard

You can see the behavior with:

###################################

user@qfx-leaf> show route resolution table bgp.evpn.0
Tree Index: 1, Nodes 0, Reference Count 4
Contributing routing tables: inet.3

###################################

Alternatively you can change the route resolution for inet.3 using:

- set routing-options resolution rib bgp.evpn.0 resolution-ribs [ inet.0 inet.3 ]

The above command should then show:

###################################

Contributing routing tables: inet.0 inet.3

###################################

Or delete dependence on inet.3 for route resolution and [ move all routes from inet.3 into inet.0 / depend on routes in inet.0 ]:

- set protocols mpls traffic-engineering bgp-igp

Regarding the issue with RouteTarget routes on QFX51:

> lab@QFX51> show route advertising-protocol bgp 10.0.0.5
> bgp.rtarget.0: 6 destinations, 7 routes (1 active, 0 holddown, 6 hidden)

There is one active route, and it is being advertised to the P5-RR.

There are also 6x Hidden routes there. You can resolve them using the same solutions as in my remark #1. In my lab I noticed that the routes then move from Hidden state into the bgp.rtarget.0 RIB. I suspect that once they are not hidden anymore, the QFX51 learns membership for the EVPN route-targets from P5-RR and it should then advertise the EVPN routes (they were not being sent in your example) to P5-RR.

You can also specify on P5-RR to send a "default" RTF route (family route-target advertise-default) and it will tell PE devices (QFX51) to send all routes to the P5-RR.

As a closing remark, I don't think you hit a few bugs but just a few missing knobs in the configuration. JUNOS can be complicated at times 🙂

https://computer.howstuffworks.com/lan-switch13.htm

This may explain to you how a broadcast can be generated unintentionally and this will not happen on a converged STP topology. On a converged STP it can be a DOS kind of attack using crafted ARP packets to chock the BW of intended gateway of host.

If this solves your problem, please mark this post as "Accepted Solution".
If you think that my answer was helpful, please spend some Kudos.

Thanks

Amit

Hello colleagues,

According to my understanding and reading about configuring rstp on Juniper interfaces:

if bpdu-block-on-edge is configured:

- When BPDU is received the port will be blocked.

-It should be configured on all host interfaces to prevent any possible loops.

-it should not be configured on the ends of links between switches.

But our customer has the below recommendations:

Interface To	Configuration	Notes
Global	BPDU Block-On-Edge	BPDU Block-On-Edge will operate on all Edge ports to ensure that the reception of a STP BPDU will block the port
Host Port	Edge Port	Rapid transition to a forwarding state, BPDU Block-On-Edge will automatically be applied to the port from the Global configuration
Switch	Edge port	Rapid transition to a forwarding state, BPDU Block-On-Edge will automatically be applied to the port from the Global configuration Rapid transition to a forwarding state, BPDU Block-On-Edge blocks the port in the event of a loop during start-up. The external switch to be connected to the fabric must configured with STP disabled so that when a loop is formed, BPDUs flowing from the fabric will automatically be forwarded through the loop back to the fabric switch resulting in the port on the fabric switch being disabled.

and so seems it has Edge port enabled on Fabric switches towards Access ones and disable on Access ones towards Fabric ones (configuration is below), so my question how is that working? ACC swithces are sending BPDUs I guess to Fabric switches so in theory Fabric ports should be blocked, but it is not and all is working fine, so it seems I am missing something, can you help in understanding this.

VCF ae20 > ACC01 ae0

------------------------------

S00-VCF> show configuration | display set | match ae20
set interfaces xe-11/0/17:0 ether-options 802.3ad ae20
set interfaces xe-12/0/17:0 ether-options 802.3ad ae20
set interfaces ae20 apply-groups LAG
set interfaces ae20 description "VCF:S1>S01-ACC"
set interfaces ae20 mtu 9192
set interfaces ae20 aggregated-ether-options lacp active
set interfaces ae20 aggregated-ether-options lacp periodic slow
set interfaces ae20 unit 0 family ethernet-switching vlan members all
set protocols rstp interface ae20 edge
set class-of-service interfaces ae20 apply-groups TRUSTED
set protocols rstp bpdu-block-on-edge

---------------------------------------------------

S01-ACC> show configuration | display set | match ae0
set interfaces xe-0/2/0 ether-options 802.3ad ae0
set interfaces xe-1/2/0 ether-options 802.3ad ae0
set interfaces ae0 apply-groups LAG
set interfaces ae0 description S01-ACC->S00-VCF
set interfaces ae0 unit 0 family ethernet-switching vlan members all
set protocols uplink-failure-detection group TRACK_UPLINK_ACC:1 link-to-monitor ae0
set protocols uplink-failure-detection group TRACK_UPLINK_ACC:2 link-to-monitor ae0
set class-of-service interfaces ae0 apply-groups TRUSTED
set protocols rstp bpdu-block-on-edge

Hello,

i want to use 2x QFX3500 as virtual chassis as my core switching and i have following featurs :

10-15gbps bps

6m pps

8-9 BGP Peers with no full tables,

10k Routes in worst case

40-50k mac address in worst case

i want to have 6-7 firewall access list to control input traffic and some traffic wchih is forward thought the switch

2-3x PBR which assign to my Vlan

700x VLAN and SVI (and each vlan has its own ip or secondary ips)

i want to know can QFX3500 handle these features perfectly with less cpu usages?

and i want to know how many SVI can i have in qfx3500 ? for example n3k-c3064pq-10gx suggested that we can have 1024 SVI

Thank you.

Hi all,

In the same mean regarding the QFX Licensing, is the "S-QFX5K-C1-A2-3" include all features of "S-QFX5K-C1-A1-3" ?

I think so but I want confirmation please.

Thx in advance,

Yes, A2 includes all features of A1 as shown on in figure 12 on the following link.

https://www.juniper.net/documentation/en_US/release-independent/licensing/topics/concept/flex-software-subscription-model-support.html#jd0e2794

Compared to previous license type from Juniper, you don't need to stack licenses - the higher tier includes the features of the lower one.

@F1ght3r: I need to correct you a bit.

QFX5120-48Y can currently be purchased in two variances: "legacy" and "flex" with different list prices.

QFX5120-48Y-AFO is the legacy SKU

QFX5120-48Y-AFO2 is the flex SKU

The flex SKU is lower priced but also comes with fewer base features. We have been used to having virtual chassis, OSPF, routing-instances and similar included in the base SKU. That is not the case with the flex model anymore... but as mentioned, the hardware list prices has been lowered accordingly.

If you buy a legacy HW SKU, you should buy the QFX5K-C1-PFL license + support

If you buy a flex HW SKU, you should buy either the 3 or 5 year subscription SKU *or* the perpetual flex SKU (S-QFX5K-C1-A2-P) + support.

Overall the Flex A2 subscription matches the features of the legacy PFL license.

Flex P1 matches legacy AFL license.

Bonus note: the legacy licenses and the perpetual flex license are non-portable where the subscriptions can be migrated between devices.

I hope this clarifies a bit 🙂

One other point for Flex Licenses. Currently there are no upgrade SKUs for A1 to A2/P or A2 to P, so best to purchase the license level you might need for the future, day 1.

Yes some compensation on next sale for all is possible (probable) but this just makes things harder for all involved on $$ side.

Just FYI

Hello,

I was wondering if there is a way to stack an EX4650 in a mixed virtual chassis with a EX4600-40F. I was reading this document where EX4650 is group with QFX. Thank you.

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/virtual-chassis-qfx-series-cli.html

Hi loba-ucb,

Please be advised that EX4650 can't be stacked with other platforms, as you can see below,

https://www.juniper.net/documentation/en_US/junos/topics/concept/virtual-chassis-ex4200-overview.html#jd0e747

"EX4650 switches can’t be combined with any other type of switches in a Virtual Chassis."

You can only stack up to 4 EX4650 after 20.1R1 code.

"Starting in Junos OS Release 19.3R1, you can interconnect up to two EX4650 switches in an EX4650 Virtual Chassis. The two member switches must be in the master and backup Routing Engine roles.

Starting in Junos OS Release 20.1R1, you can interconnect up to four EX4650 switches in an EX4650 Virtual Chassis. You should configure two member switches into the master and backup Routing Engine roles, and the remaining member switches into the linecard role."

If this worked for you please mark as "Solved" so we can help others too.

Regards,

Jeff

I am reviewing the JNCIE-ENT self study bundle and am confused by some CoS configuration. The examples given guide the user through creating both dscp and ieee802.1p classifiers. Then they are instructed to apply the dscp classifiers to all L3 interfaces and apply the ieee802.1p classifiers to all L2 interfaces. The guide then goes on to apply the ieee802.1p classifiers to several access and trunk interfaces (so as instructed, all L2 iterfaces).

But an access interface will receive only untagged traffic, that traffic will not have any 802.1q header and no PCP bits. So I don't think a classifier based on iee802.1p will actually do anything. I have tested this in a lab and as I predicted the ieee802.1p classifier applied on the access interface does nothing. It is only when you change that interface to a trunk and tagged traffic sent to the interface that the classifier starts classifying traffic to the correct Queues. If I apply a dscp classifier on the access interface, it works as expected, classifying traffic based on the inbound dscp value.

Interestingly the default classifier applied to an access interface is ieee802.1p-untrust, which basically assigns all incoming frames with a pcp 0-7 to best-effort. But this doesn't make sense to me as the incoming traffic will not contain pcp bits. Could someone please clarify if a ieee802..1p classifier applied to a access interface serves any purpose??? if not then would it make far more sense to apply a dscp classifier, where it can be configured to trust the markings coming from the end device placing traffic in appropriate FCs, or simply bleach the traffic into a single FC and rewrite the dscp or pcp on exit?

Thanks in advance.

Just asking.. The qfx acting the layer 3 "helper" for the devices connected to your system do you have a vlan option option 82 setup for it ?

I only ask as I have had things not work the way I expected as I have setup the Vlan fwd option 82 stuff but also the layer 3 fwd dhcp-relay for the same vlan being supported by the irb ..

set vlans Group4 l3-interface irb.999;

set vlans Group4 forwarding-options dhcp-security option-82 circuit-id use-vlan-id
set vlans Group4 forwarding-options dhcp-security option-82 remote-id host-name

Yours.

set forwarding-options dhcp-relay relay-option-82 remote-id
set forwarding-options dhcp-relay server-group 4-srvs 10.1.1.2
set forwarding-options dhcp-relay group 4 active-server-group 4-srvs
set forwarding-options dhcp-relay group 4 interface ge-0/0/1.0

Hello,

wrote:
The guide then goes on to apply the ieee802.1p classifiers to several access and trunk interfaces (so as instructed, all L2 iterfaces).

But an access interface will receive only untagged traffic, that traffic will not have any 802.1q header and no PCP bits.

Well, there also are "tagged access" interfaces but in general yes, 802.1ieee classifier does not work on Ethernet frames which do not have a 802.1Q VLAN tag.

wrote:

would it make far more sense to apply a dscp classifier, where it can be configured to trust the markings coming from the end device placing traffic in appropriate FCs, or simply bleach the traffic into a single FC and rewrite the dscp or pcp on exit?

dscp classifier would only work on IPv4 packets, not on ARP, not on IPv6, not on L2 control frames such as STP.

So, if You have L2 interface that receives ONLY frames without 802.1Q VLAN tag, and if You want 100% classification (no missing/incorrect FC) then You have following options:

1/ configure fixed classifier (a classifier assigned to ingress logical interface, all incoming frames will fall into single FC+LP combo)

2/ use "family bridge|ccc" (on MX) or "family ethernet-switching" (on EX|QFX) MF classifiers to match on i.e. Ethertype and classify accordingly.

Obviously, method [1] is less cumbersome than [2] but also less flexible.

HTH

Thx

Alex

Hi blackmetal,

QFX3500 in a VC should be able to handle that seemlessly. you can refer the the below doc for scaling limits of QFX3500 and your requirement falls well within the range of that.

https://www.slideshare.net/NamNguyen5/qfx3500

If this solves your problem, please mark this post as "Accepted Solution".
If you think that my answer was helpful, please spend some Kudos.

Regards,

Amit

We are currently 18.2 R3-s2, but the same message is happening.

Hi @aarseniev, many thanks for the detailed reply, it has cleared up a lot for me.

One final question you may be able to help with. Why is the default classifier on an access interface a ieee802.1p classifier (ieee 802.1untrust)? As we discussed this won't achieve anything.

Thanks in advance

Hello,

wrote:
. Why is the default classifier on an access interface a ieee802.1p classifier (ieee 802.1untrust)?

I don't see this happening (meaning default classifier is not present on L2 interfaces) in my lab with VMX and JUNOS 19.1R3. Configuration below:

set routing-instances VS1 instance-type virtual-switch
set routing-instances VS1 interface ge-0/0/9.0
set routing-instances VS1 interface ae6.0
set routing-instances VS1 interface ae7.0
set routing-instances VS1 bridge-domains BDOM vlan-id-list 100-110
set interfaces ge-0/0/9 encapsulation ethernet-bridge
set interfaces ge-0/0/9 unit 0 family bridge interface-mode access
set interfaces ge-0/0/9 unit 0 family bridge vlan-id 100
set interfaces ae6 flexible-vlan-tagging
set interfaces ae6 encapsulation extended-vlan-bridge
set interfaces ae6 aggregated-ether-options lacp active
set interfaces ae6 unit 0 family bridge interface-mode trunk
set interfaces ae6 unit 0 family bridge vlan-id-list 100-110
set interfaces ae7 encapsulation ethernet-bridge
set interfaces ae7 aggregated-ether-options lacp active
set interfaces ae7 unit 0 family bridge interface-mode access
set interfaces ae7 unit 0 family bridge vlan-id 100

Verification:

show class-of-service interface ge-0/0/9 detail 

Physical interface: ge-0/0/9, Enabled, Physical link is Up
  Link-level type: Ethernet-Bridge, MTU: 1514, MRU: 1522, LAN-PHY mode, Speed: 1000mbps, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x20004000
  Link flags     : None

Physical interface: ge-0/0/9, Index: 161
Maximum usable queues: 8, Queues in use: 4
Exclude aggregate overhead bytes: disabled
Logical interface aggregate statistics: disabled
  Scheduler map: <default>, Index: 2
  Congestion-notification: Disabled

  Logical interface ge-0/0/9.0 
    Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
    bridge
Interface       Admin Link Proto Input Filter         Output Filter
ge-0/0/9.0      up    up   bridge
Interface       Admin Link Proto Input Policer         Output Policer
ge-0/0/9.0      up    up        
                           bridge

  Logical interface: ge-0/0/9.0, Index: 381

show class-of-service interface ae6 detail
        
Physical interface: ae6, Enabled, Physical link is Up
  Link-level type: Extended-VLAN-VPLS, MTU: 9192, Speed: 1Gbps, Loopback: Disabled, Source filtering: Disabled,
  Flow control: Disabled
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x20004000

Physical interface: ae6, Index: 147
Maximum usable queues: 8, Queues in use: 4
Exclude aggregate overhead bytes: disabled
Logical interface aggregate statistics: disabled
  Scheduler map: <default>, Index: 2
  Congestion-notification: Disabled

  Logical interface ae6.0 
    Flags: Up SNMP-Traps 0x20024000 VLAN-Tag [  ]  Encapsulation: Extended-VLAN-Bridge
    bridge
Interface       Admin Link Proto Input Filter         Output Filter
ae6.0           up    up   bridge
Interface       Admin Link Proto Input Policer         Output Policer
ae6.0           up    up        
                           bridge

  Logical interface: ae6.0, Index: 364

  Logical interface ae6.32767 
    Flags: Up SNMP-Traps 0x24004000 VLAN-Tag [ 0x0000.0 ]  Encapsulation: Extended-VLAN-Bridge
    multiservice
Interface       Admin Link Proto Input Filter         Output Filter
ae6.32767       up    up   multiservice
Interface       Admin Link Proto Input Policer         Output Policer
ae6.32767       up    up        
                           multiservice __default_arp_policer__

  Logical interface: ae6.32767, Index: 365


show class-of-service interface ae7 detail   

Physical interface: ae7, Enabled, Physical link is Up
  Link-level type: Ethernet-VPLS, MTU: 9192, Speed: 1Gbps, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x20004000

Physical interface: ae7, Index: 148
Maximum usable queues: 8, Queues in use: 4
Exclude aggregate overhead bytes: disabled
Logical interface aggregate statistics: disabled
  Scheduler map: <default>, Index: 2
  Congestion-notification: Disabled

  Logical interface ae7.0 
    Flags: Up SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
    bridge
Interface       Admin Link Proto Input Filter         Output Filter
ae7.0           up    up   bridge
Interface       Admin Link Proto Input Policer         Output Policer
ae7.0           up    up        
                           bridge

  Logical interface: ae7.0, Index: 380

show bridge domain 

Routing instance        Bridge domain            VLAN ID     Interfaces
VS1                     BDOM-vlan-0100           100      
                                                             ae6.0
                                                             ae7.0
                                                             ge-0/0/9.0
VS1                     BDOM-vlan-0101           101      
                                                             ae6.0
VS1                     BDOM-vlan-0102           102      
                                                             ae6.0
VS1                     BDOM-vlan-0103           103      
                                                             ae6.0
VS1                     BDOM-vlan-0104           104      
                                                             ae6.0
VS1                     BDOM-vlan-0105           105      
                                                             ae6.0
VS1                     BDOM-vlan-0106           106      
                                                             ae6.0
VS1                     BDOM-vlan-0107           107      
                                                             ae6.0
VS1                     BDOM-vlan-0108           108      
                                                             ae6.0
VS1                     BDOM-vlan-0109           109      
                                                             ae6.0
VS1                     BDOM-vlan-0110           110      
                                                             ae6.0

Could You please share Your router/switch model, JUNOS version and exact configuration where You see "ieee8021p-untrust" classifier applied by default to L2 interfaces?

HTH

Thx

Alex

Hello.

Do you have found any solution to this issue?

We have an issue with aggregated links on a chassis (seems traffic crossing a member to another one are dropped), and we suspect the cause is this mismatch of link negotiation.

Regards

Say I wanted to tap my inet port for a firewall poc... will analyzer work for this, or do I need to use firewall filters?

Hello rfb,

Analyzer mirrors only bridged traffic. For mirroring routed traffic, use the port mirroring configuration with family as inet or inet6

Port mirror configuration is needed with the output interface with family inet.

Regards,

Hello,

I have a 2x QFX3500 in virtual chassis mode and every 1-2 month one of my Fan trays showed as failed and everything is ok , Fan trays are spining at normal speed they have 1unit free space from up and bottom of the every switch, and here is the switch output :

Class Item Status Measurement
Power FPC 0 Power Supply 0 OK
FPC 0 Power Supply 1 OK
FPC 1 Power Supply 0 OK
FPC 1 Power Supply 1 OK
Temp FPC 0 Sensor TopLeft I OK 21 degrees C / 69 degrees F
FPC 0 Sensor TopRight I OK 22 degrees C / 71 degrees F
FPC 0 Sensor TopLeft E OK 35 degrees C / 95 degrees F
FPC 0 Sensor TopRight E OK 33 degrees C / 91 degrees F
FPC 0 Sensor TopMiddle I OK 31 degrees C / 87 degrees F
FPC 0 Sensor TopMiddle E OK 31 degrees C / 87 degrees F
FPC 0 Sensor Bottom I OK 37 degrees C / 98 degrees F
FPC 0 Sensor Bottom E OK 30 degrees C / 86 degrees F
FPC 0 Sensor Die Temp OK 42 degrees C / 107 degrees F
FPC 0 Sensor Mgmnt Brd I OK 21 degrees C / 69 degrees F
FPC 0 Sensor Switch I OK 31 degrees C / 87 degrees F
FPC 1 Sensor TopLeft I OK 21 degrees C / 69 degrees F
FPC 1 Sensor TopRight I OK 20 degrees C / 68 degrees F
FPC 1 Sensor TopLeft E OK 27 degrees C / 80 degrees F
FPC 1 Sensor TopRight E OK 27 degrees C / 80 degrees F
FPC 1 Sensor TopMiddle I OK 27 degrees C / 80 degrees F
FPC 1 Sensor TopMiddle E OK 34 degrees C / 93 degrees F
FPC 1 Sensor Bottom I OK 33 degrees C / 91 degrees F
FPC 1 Sensor Bottom E OK 33 degrees C / 91 degrees F
FPC 1 Sensor Die Temp OK 41 degrees C / 105 degrees F
FPC 1 Sensor Mgmnt Brd I OK 19 degrees C / 66 degrees F
FPC 1 Sensor Switch I OK 27 degrees C / 80 degrees F
Fans FPC 0 Fan Tray 0 OK Spinning at normal speed
FPC 0 Fan Tray 1 OK Spinning at normal speed
FPC 0 Fan Tray 2 Failed
FPC 1 Fan Tray 0 OK Spinning at normal speed
FPC 1 Fan Tray 1 OK Spinning at normal speed
FPC 1 Fan Tray 2 OK Spinning at normal speed

show chassis alarms
1 alarms currently active
Alarm time Class Description
2020-11-06 04:44:17 UTC Major FPC 0 Fan 2 not spinning

the strange part is Fan Tray 2 LED is ON and its not off and when i put a little tissue paper on fan tray 2 it seems the fan tray is working but i do not know why does in qfx it shows as failed,

i have reboot whole of the switches but the issue still exists,

here is picture of the switch :

Hello,

we have 2x qfx3500 in VC and since last week it shows chassis #1 fan tray 2 (management fan) is Failed then today we replaced it with a healthy management module but it still showing it as failed,

is it possible that qfx3500 is showing false report ?

we are sure management module is healthy

can we ignore this?

we are using junos 15.1R7.8

Thanks,

Hi,

if the fan continues to spin at normal rate then it could be a false alarm and you can ignore it.

You can try to reboot the box once and see if the alarm goes away. you can also check out the below PR.

https://prsearch.juniper.net/InfoCenter/index?page=prcontent&id=PR1010342

If this solves your problem, please mark this post as "Accepted Solution".
If you think that my answer was helpful, please spend some Kudos.

Regards,

Amit Rai

Hi,

if it is happening again and again you better get the FPC0 replaced.

Regards,

Amit Rai

Hello,

last month i replaced whole of the VC member with new qfx3500 but it seems its related something tot eh software.

i have read in juniper kb that qfx5100 has same issue when the fan working outside of the range, and am i using 15.1R7.8 , is it possible this is relared to the software?

because currently i put a smal tissue paper on Fan Tray 2 (mgmt board) it seems it was working fine

The main problem has probably been that virtual chassis isn't supported on QFX5120-48Y before Junos 19.3R1. Using 18.4 with VC would have given strange issues like the one described.

Ref. https://www.juniper.net/documentation/en_US/junos/topics/concept/virtual-chassis-qfx-series-understanding.html

I would go with Junos 19.4R2-S2 for a start if VC was needed on QFX5120-48Y's

Sorry for the delayed response. all requested detail is below. Code is 18.4, but I don't think anything is wrong. According to junos documentation it is expected behaviour. It just doesn't make sense to me why they would do it.

Hi @aarseniev

Also would you know what happens when multiple BA classifiers are applied to the same interface. Which one would take priority in the case of both dscp/ieee802.1p being applied to a trunk interface? I have good reason for asking this. Screenshot attached shows the configuration takes and both classifiers are applied to the interface. Thanks in advance.