First time I've ever posted a topic but I was hoping someone might help me with an issue I'm having carrying out RFC testing across a Juniper EX4200 (running version 10.0S6.1).
The basic set up is an RFC tester connected to the EX4200 testing to a loopback. The RFC test is failing on throughput as I'm actually seeing extra packets being delivered back to the tester. The test traffic is in the priority queue and what's I'm seeing is 2 extra packets in the best-effort queue being sent back to the tester, but also 1 extra packet being sent back to the tester in the priority queue. This seems to be related to packets being recevied and transmitted in the logical interface (unit 0). For example if 2 packets are transmitted on the logical interface, I also see 2 packets output on the physical interface (but in the best-effort queue). The tester should deal wih this as it's set to filter packets not in the same queue as the test traffic.
However, at the same time I see two packets transmitted on the logical interface, I also see one packet received. When this happens I'm pretty sure an extra packet is being sent back tot he tester, but in the same priority queue. I can't say for sure but for every extra packet I recevieve on the logical interface, I see an extra packet out to the tester when I stop the test. The tester does not seem to be filtering this, causing the test to fail.
There doesn't seem to be a pattern to when I receive/transmit packets, but it seems to occur most for packets sizes of 64 and 128 bytes.
set interfaces ge-0/0/2 description "Gig Headend Tester" set interfaces ge-0/0/2 mtu 2000 set interfaces ge-0/0/2 ether-options no-auto-negotiation set interfaces ge-0/0/2 ether-options no-flow-control set interfaces ge-0/0/2 ether-options link-mode full-duplex set interfaces ge-0/0/2 ether-options speed 100m set interfaces ge-0/0/2 unit 0 family ethernet-switching port-mode trunk set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members TestVLAN
set vlans TestVLAN description "22Mbps test traffic" set vlansTestVLAN vlan-id x set vlans TestVLAN filter input 50mBand
set firewall family ethernet-switching filter 50mBand term 50mBand then forwarding-class priority set firewall family ethernet-switching filter 50mBand term 50mBand then loss-priority low set firewall family ethernet-switching filter 50mBand term 50mBand then count packet-count
set class-of-service forwarding-classes class priority queue-num 6
set class-of-service scheduler-maps Airspeed-cos-map forwarding-class priority scheduler priority-sched
set class-of-service schedulers priority-sched buffer-size percent 10 set class-of-service schedulers priority-sched priority strict-high
Not this one (a VeEX MPX100+)! It may be an optional extra on this unit but it's not enabled on the one I am using. I've tried port mirroring and looking a the packets being output using wireshark, but the amount of packets just crashes the application on my laptop. I've also tried running at a lower throughput rate but I just don't see the issue then.
Just an added note to this, I'm not running any protocols on the EX4200 (LLDP, LLDP-MED, RSTP, etc...). Also, the packets I see on the logical interface are always the same size as the packet sizes being used during the RFC testing, e.g. (64 or 128bytes).
Check that the tester isn't sending traffic to an IP address that is valid - you may be receiving RST or ICMP Unreachable messages back from the destination host, which will most likely be un-marked and fall into the Best-Effort queue.
Hope this helps.
Ben Dale JNCIP-ENT, JNCIP-SP, JNCIP-DC, JNCIE-SEC #63 Juniper Ambassador Follow me @labelswitcher
The test is a layer 2 rfc2544 test to a loopback at the far side, so there shouldn't be any other traffic being sent back out to the tester, e.g. icmp messagase or otherwise.
It's not a regular occurence either. The test can sometimes run clean for 5 minutes at 64 bytes (i.e. no extra packets seen), sometimes not. However, tests at 256byte and above have nearly always been ok, and it's only when testing at 64 and 128 bytes that I see the problem.
As we weren't dropping packets we've passed the circuit being tested, but it took up a few days of my time trying to track down what these packets were and where they were coming from. Very frustrating!