05-17-2010 06:43 AM - edited 03-06-2019 11:07 AM
Hi there,
I currently mark traffic on my access layer edge switches then trust this traffic on the ingress interface on the distribution switch.
However, I also want to mark radius traffic being generated by the access layer switch. As far as I can tell I cannot mark this on the access layer switch itself so must do this on the dist layer.
So my question is this... If I apply a policy to mark radius ingress traffic on the distribution layer switch, how do I ensure that all other existing DSCP markings from the edge switch remain intact and do not get remarked to DSCP 0 by class-default on the dist switch?
Rhodri
Solved! Go to Solution.
05-18-2010 02:03 PM
Perhaps the documentation is referring of using set and trust within the same class under a policy-map.
It isn't the first time the documentation can be misleading.
As for using a local policy-map, while you can't set the dscp value you can use TOS.
Here is a sample for telnet:
ip local policy route-map TEST
!
access-list 101 permit tcp any any eq telnet
access-list 101 permit tcp any eq telnet any
!
route-map TEST permit 10
match ip address 101
set ip tos 6
Then telnet from SW1 to R1
Rack1R1>sh policy-map int
FastEthernet0/0
Service-policy input: SWITCH
Class-map: SWITCH (match-all)
16 packets, 1168 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs6 (48)
police:
cir 200000000 bps, bc 6250000 bytes
conformed 16 packets, 1168 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: class-default (match-any)
42 packets, 2799 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
05-17-2010 08:50 AM
rhodrijenkins wrote:
Hi there,
I currently mark traffic on my access layer edge switches then trust this traffic on the ingress interface on the distribution switch.
However, I also want to mark radius traffic being generated by the access layer switch. As far as I can tell I cannot mark this on the access layer switch itself so must do this on the dist layer.
So my question is this... If I apply a policy to mark radius ingress traffic on the distribution layer switch, how do I ensure that all other existing DSCP markings from the edge switch remain intact and do not get remarked to DSCP 0 by class-default on the dist switch?
Rhodri
Rhodri
If you are marking other traffic on your access-layer switches what makes you think you can't mark radius traffic on that switch ?
What switch is it ?
Jon
05-18-2010 08:02 AM
Hi Jon,
It's a 3750. Basically the switch is acting as an 802.1x NAS so the switch itself is the source of the radius traffic. I'm under the impression that one cannot mark traffic that's been locally generated. A prime example would be syslog messages or in this case radius traffic. I thought I could only mark this traffic upstream? If I can mark this traffic locally even better but I can't find a way of doing it.
Thanks Jon
Rhodri
05-18-2010 08:50 AM
Rhodri
Okay that makes sense. On routers you can use "ip policy route-map" under the interface to mark traffic but this is not supported on the 3750.
What is your distribution switch ? The issue is, as you are probably aware, that you cannot use trust
Jon
05-18-2010 09:28 AM
Hi Jon,
The Dist switch is a 3750-E.
FYI the IOS is 12.2(53)SE2 on the edge 3750's and currently 12.2(44)SE1 on the dist 3750-E
Cheers
Rhodri
05-18-2010 10:01 AM
Rhodri
The traffic you do mark on the access-layer switch, do you do any queueing for it on the access-layer switch or are you simply marking it ?
Jon
05-18-2010 12:28 PM
At the distribution, you can create a class-map that matches the RADIUS packet while trusting the class class-default.
!
access-list 101 permit udp any any eq 1646
access-list 101 permit udp any any eq 1645
!
class-map RADIUS
match access-group 101
!
policy-map QoS_RADIUS
class RADIUS
set dscp cs6
class class-default
trust dscp
!
int g0/1
service-policy input QoS_RADIUS
Regards
Edison
05-18-2010 12:35 PM
Edison
Can you actually do this because the 3750 QOS config doc says you cannot mix set and trust commands in the same policy-map.
I was thinking if there was only marking on the access-layer switch and nothing else then it would be simpler to move all the marking to the distribution switch.
Jon
05-18-2010 01:16 PM
Jon,
The config I posted was taken from a 3750 switch and I didn't receive any error while applying on the interface.
The problem is the OP wants to mark RADIUS traffic originated from the access-layer switch.
He could do it with ip local policy-map at the access-layer itself or inbound service-policy at the distro switch.
Both solutions are doable though I did not test for the local policy-map.
The solution you presented now is also doable but he can be trusting voice at the access layer... moving this service to the distribution layer would require an ACL.
05-18-2010 01:38 PM
ediortiz wrote:
Jon,
The config I posted was taken from a 3750 switch and I didn't receive any error while applying on the interface.
The problem is the OP wants to mark RADIUS traffic originated from the access-layer switch.
He could do it with ip local policy-map at the access-layer itself or inbound service-policy at the distro switch.
Both solutions are doable though I did not test for the local policy-map.
The solution you presented now is also doable but he can be trusting voice at the access layer... moving this service to the distribution layer would require an ACL.
Edison
I don't have a 3750 to test with so i just went off the documentation ie. from the 12.2(50) config guide -
Also a lot of the set commands under route-maps are not supported on the 3750 so i didn't think you could apply QOS to locally generated traffic as you can on a router.
I appreciate the OP wants to mark all traffic on the access-layer but with the above restrictions i didn't think it could be done. However if you have tested and it works it looks like the documentation is misleading.
Jon
05-18-2010 02:03 PM
Perhaps the documentation is referring of using set and trust within the same class under a policy-map.
It isn't the first time the documentation can be misleading.
As for using a local policy-map, while you can't set the dscp value you can use TOS.
Here is a sample for telnet:
ip local policy route-map TEST
!
access-list 101 permit tcp any any eq telnet
access-list 101 permit tcp any eq telnet any
!
route-map TEST permit 10
match ip address 101
set ip tos 6
Then telnet from SW1 to R1
Rack1R1>sh policy-map int
FastEthernet0/0
Service-policy input: SWITCH
Class-map: SWITCH (match-all)
16 packets, 1168 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs6 (48)
police:
cir 200000000 bps, bc 6250000 bytes
conformed 16 packets, 1168 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps
Class-map: class-default (match-any)
42 packets, 2799 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
05-18-2010 02:10 PM
Edison
As always, thanks for the clarification.
Jon
05-19-2010 08:27 AM
Hi gentlemen,
This afternoon I tested this in our lab using the route map solution and it works perfectly. I even sniffed the traffic arriving up stream and the tos markings were present.
This is the solution I will go with as I'm keen on keeping all the marking as close to the edge as possible. This will also mean that the model will remain constant at all sites regardless of whether there is a dist layer or not.
Thanks again both for your input here.
Regards
Rhodri
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide