Does any one know how do we debug of dscp traffic? I want to troubleshoot whether the phone system really tagging sip traffic with dscp value of 26 and rtp traffic with dscp value of 46.
I've created a standard access list for 1 ip address
I've ran the command - debug ip packet DEBUG detail (note DEBUG is the name of the access list).
IP: UDP: src=2088, dst=2088
IP: s=10.10.150.240 (vlan 1) d=10.10.150.255 (Loopback), rcvd, size = 56(36)
IP: UDP: src=2088, dst=2088
IP: s=10.10.150.240 (vlan 1) d=10.10.150.255, entering FW, size = 52(32)
IP: UDP: src=2088, dst=2088
IP: s=10.10.150.240 (vlan 1) d=10.10.150.255 (Loopback), rcvd, size = 52(32)
Here are some samples, but it does not output DSCP value anywhere
When i ran the command show qos map interface ether 0/1
map entry 10
match IP packets with a DSCP value of 46
priority bandwidth: unlimited
note: since unlimited, other qos bandwidths cannot be assured
packets matched: 1290616, bytes matched: 348217200
map entry 20
match IP packets with a DSCP value of 26
priority bandwidth: unlimited
note: since unlimited, other qos bandwidths cannot be assured
packets matched: 0, bytes matched: 0 *********************************NOTICE - Phone System manufacture does insist that they mark sip traffic as DSCP 26 though.
map entry default
packets matched: 33391299, bytes matched: 2691661703
packets dropped: 0, bytes dropped: 0
5 minute offered rate 1016 bits/sec, drop rate 0 bits/sec
Input QoS Map not assigned for this interface
@touristsis -
On an AOS device, you can set up a QoS map to match traffic tagged with what you suspect the DSCP value is and apply that map inbound on the incoming interface. From there, you can issue the "show qos map <NAME> interface <interface slot/port>" command and see if you notice any matches counting up.
Other than that, the only way you will be able to verify that the DSCP value is being tagged correctly by the phone system is to get a packet capture. A "debug ip packet" output will only provide information regarding source and destination ports, the interface the traffic was received on, the interface the traffic departs from, and the source and destination IP addresses.
It would also be important to check that the AOS device is not overwriting the DSCP value based on its configuration. I would be more than happy to review your configuration for you to confirm that is not the case. Please be sure to remove any information that may be sensitive to your network or company.
Thanks,
Noor
@touristsis -
On an AOS device, you can set up a QoS map to match traffic tagged with what you suspect the DSCP value is and apply that map inbound on the incoming interface. From there, you can issue the "show qos map <NAME> interface <interface slot/port>" command and see if you notice any matches counting up.
Other than that, the only way you will be able to verify that the DSCP value is being tagged correctly by the phone system is to get a packet capture. A "debug ip packet" output will only provide information regarding source and destination ports, the interface the traffic was received on, the interface the traffic departs from, and the source and destination IP addresses.
It would also be important to check that the AOS device is not overwriting the DSCP value based on its configuration. I would be more than happy to review your configuration for you to confirm that is not the case. Please be sure to remove any information that may be sensitive to your network or company.
Thanks,
Noor
@touristsis - I marked this as "assumed answered," but if you have further questions on this topic do not hesitate to reply. I will be happy to help.
Thanks,
Noor
I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons. If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.
Thanks,
Noor