Many apologies for disturbing you experts with this issue again, but I am having real problems even getting the basic working:
So, I have the following as a test:
BGP Router --> Core1 --> LNS1
I am simply running an extended ping from the BGP Cisco Router to the LNS interface address. I am classifying at the Core1 Interface facing the BGP Router. Here is my configuration:
set interfaces ge-1/0/1 unit 0 family inet filter input mf-classifierset interfaces ge-1/0/1 unit 0 family inet address 192.168.100.2/30set interfaces ge-1/0/1 unit 0 family iso
set class-of-service classifiers dscp v4-ba-classifier forwarding-class voice loss-priority low code-points 101110set class-of-service forwarding-classes queue 0 BE-dataset class-of-service forwarding-classes queue 1 Premium-dataset class-of-service forwarding-classes queue 2 voiceset class-of-service forwarding-classes queue 3 NCset class-of-service interfaces ge-1/0/1 unit 0 classifiers dscp v4-ba-classifierset firewall family inet filter mf-classifier term priority from source-address 192.168.100.1/32set firewall family inet filter mf-classifier term priority then count voiceset firewall family inet filter mf-classifier term priority then forwarding-class voiceset firewall family inet filter mf-classifier term priority then acceptset firewall family inet filter mf-classifier term all-else then accept
Now, I clear the interface stats and send an Extended ping test with the following settings:
Target IP address: 172.16.16.33Repeat count : 500Datagram size :Timeout in seconds :Extended commands [n]: ySource address or interface: Type of service : 184 --->dscp is efSet DF bit in IP header? [no]:Validate reply data? [no]:Data pattern [0xABCD]:Loose, Strict, Record, Timestamp, Verbose[none]:Sweep range of sizes [n]:Type escape sequence to abort.
And the results from the "show interface ge-1/0/1 extensive" command show the following:
Queue counters: Queued packets Transmitted packets Dropped packets 0 503 503 0 1 0 0 0 2 0 0 0 3 13 13 0 Queue number: Mapped forwarding classes 0 BE-data 1 Premium-data 2 voice 3 NC
I expected to see the packets go into the Voice queue (number 2) and not into the Best Effort queue. Does not matter what I do I cannot get this marked traffic into the right queue
Any help please
Is it possible that the following is occuring:
Juniper sees the Voice traffic as "46" DSCP - 101110 because it only reads the leading 6 bits...... However, when an extended ping is completed from a Cisco device it sends all 8 bits, hence the 2 extra zero's on the end and therefore changing the marking requirement to 184. I have tried 46 and 184 and neither makes any difference. But as mentioned, that could be because of a ping compatibility issue with the way Cisco sends and what Juniper is expecting to receive.
If I needed to check what was happening here, what is the best way to achieve this please?
Okay, so I made a couple of changes as I realised that the firewall filter for the Classifier appears to be for unmarked traffic that can be marked upon Egress.... so, I just left in the DSCP command and pointed it to the voice queue. Again, no difference. So I tried with a VoIP phone sending SIP traffic unmarked and used a firewall filter and classifier. I got really weird results with this....
1: It made no difference to the traffic. It still ended up in the Best Effort Queue.
2: When the Classifier was applied to the ingress interface, I lost the eBGP peering..... When I removed the classifier the BGP peering became "Established" again. ---- That's weird.
So, does anyone have any idea why the eBGP peering relationship would be affected by the classifier?
Ignore the Classifier part. I have now got that working.
I still have the issue where the traffic is being sent to the BE-Data queue (Best Effort) and not the voice queue.... I am looking at a different program that will allow me to ping test on certain ports....
Okay, I now have it working. The data is going to the correct queue.
Just for peoples information... Cisco do indeed add the 2 bits to the CoS type of service... so, normally SIP VoIP would look like the following:
32 16 8 4 2 1
1 0 1 1 1 0 = 46
So, normally we would look for dscp 46 in ToS field, but because of the added 2 zero's we get the following:
128 64 32 16 8 4 2 1
1 0 1 1 1 0 0 0 = 184
So, when running the extended ping, make sure in the ToS field you type 184 if you are expecting dscp 101110.
Anyway, hope that helps someone