Marking Local switch traffic upstream and trusting traffic marked at edge

Answered Question
May 17th, 2010

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

I have this problem too.
0 votes
Correct Answer by Edison Ortiz about 6 years 6 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Jon Marshall Mon, 05/17/2010 - 08:50

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

rhodrijenkins Tue, 05/18/2010 - 08:02

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

Jon Marshall Tue, 05/18/2010 - 08:50

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 etc. in the same policy map as one that actually marks the traffic. Would be useful to know the device type ?

Jon

rhodrijenkins Tue, 05/18/2010 - 09:28

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

Jon Marshall Tue, 05/18/2010 - 10:01

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

Edison Ortiz Tue, 05/18/2010 - 12:28

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

Jon Marshall Tue, 05/18/2010 - 12:35

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

Edison Ortiz Tue, 05/18/2010 - 13:16

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.

Jon Marshall Tue, 05/18/2010 - 13:38

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 -

Step 5

trust [cos | dscp | ip-precedence]

Configure the trust state, which QoS uses to generate a CoS-based or DSCP-based QoS label.

Note This command is mutually exclusive with the set command within the same policy map. If you enter the trust command, go to Step 6.

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

Correct Answer
Edison Ortiz Tue, 05/18/2010 - 14:03

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

rhodrijenkins Wed, 05/19/2010 - 08:27

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

Actions

This Discussion