so the problem is if you followed the QOS quick note
the packet coming into eth 0 is showing the state coming in to the router at this point the firewall rule would modify the packet and you would need to trace further down the route so in the QN it is doing the trace at the PPP interface and shows the packet leaving with priority.
In your case the packets are pushed into GRE and then IPSEC as they enter these the TOS of the GRE is modified and also the IPSEC so if you trace the PPP for the ESP (proto 50) you should see some with priority TOS and some with out
are you marking the packets on the cisco coming in ?
Hi James:
Ok, i think i see where you’re going here. So, if i am tracing packets on Eth 0 i won’t see any modifications done to those packets by the firewall becasue those modificatons haven’t happened yet. If i want to see the modified TOS fields, i need to look at the outgoing interface of ppp1. Do i follow you correctly?
I am doing no traffic management on the cisco, everything is default.
cheers,
john
Hi John that is correct and as you are leaving the wan interface as GRE in IPSec you should see the TOS of the IPSec as being modified.
the reasson you could see some packets out off eth being tagged is because they are a part of a stream and the firewall could have tagged them coming back in your example it was a reset om the stream
regards
James
Hi James:
Ok, this is excellent, making progress.
I changed my trace to capture packets at the ppp1 end and sent through 5 hping packets bouncing off TCP 5018 and indeed, the modified DCSP packets were there as expected so excellent.
Ech hping 2000 byte packet shows up as 6 ppp1 packets, all marked as CRITIC/ECP. It sjust hard as hell to find them in all the crud that is going over the link.
The first packet is always a GRE packet from 2.2.2.8 to 1.1.1.1 (1.1.1.1 is my GRE and IPSec loopback address in the Cisco). The second, third, forth and fifth packets are always ESP packets from the GPRS outside interface IP to my Cisco’s public IP. The sixth and last packet is again GRE from 2.2.2.8 to 1.1.1.1. This sequence repeated for each hping message I send.
Ok, that all works as it should, the FW is marking the correct traffic DONE.
Now my problem is the QoS, no matter what settings I use on PPP1, does not seem to be working.
I’m testing this by downloading, via ftp, a file on the test laptop behind the Digi while I do my hpings. If the QoS is working, the ftp should slow down, as compared to when there is no QoS, and the RTTs for the Hping should not change since I’m fixing the 5018 traffic’s BW. My problem is, I’m seeing ZERO change no matter what settings I put in for the Configuration - Network > QoS > Queue Profiles.
I’ve measured my thru-put on the link and found it to be close to 2.3Mbps.
So I set the Profile 0 min BW to 2000 and the max to 2300. Then I set the profile 4 min BW to 10 and the max to 10…and there is zero change. The FTP session swamps the link slowing down my 5018 packets.
I think I’m setting something incorrectly here.
Cheers,
john
Are you ftping the file from the laptop behind the digi or from somewhere on the internet?
if from the internet its not going to work as the ftp data would be already on the interface off PPP so you have already fludded the link. only the control channel would be slowed down.
you would need qos in to the PPP and this would have to be done by the ISP / Internet
if its from the laptop then it should work as shown in the appl;ication note
regards
james
regards
James
Hi James:
sorry, i was not clear.
the ftp server is on the laptop behind the digi. This simulates exactly the instrumentation we have on site, a device with an ftp server and a real-time stream on 5018. I need to keep the latency on the 5018 stream down even during an ftp upload.
Problem is, its not working. The ftp upload speed is completely consistant regardless of the QoS values i select and the latency jump on the 5018 data goes from ~40ms to 400ms. I’ve done this before on Debian based routers and use the HTB qdisc and it works perfectly. This should accomplish the same thing, its just not working. The packets are marked correctly, its like the QoS is just not doing anything.
Scratching my head here.
cheers,
john
Hi try reducing the
Queue profiles are:
0 1800 2000 50 25 50 10 1
4 1000 2000 50 25 50 10 1
so q4 has a smaller max value 1000
this should just cam the q4
regards
ok, will try that in the morning.
any other suggestion in case that one doesn’t work?
cheers,
john
ok, will try that in the morning.
any other suggestion in case that one doesn’t work?
Might the router require a reboot before the settings take effect?
cheers,
john
James!!!
The reboot fixed it.
It works like magic, lovely.
I guess when I change something on ppp1 I need to cycle the interface.
Cheers,
john
Hi John.
i never remember which options on PPP need to have the interface reloaded (ppp 1 deact_rq) to take effect.
clad you got it working
regards
James