02-12-2014 05:05 PM - edited 03-04-2019 10:19 PM
Hi,
I have a cisco router that has two WAN uplinks. I was looking to see if it were possible to route only some traffic for Voice over the secondary WAN, while it will not be used as a failover. Also, if I can specify SIP, RTP traffic only and not port based traffic to route over same LAN.
Cable WAN: Internet traffic
T1: Phone traffic only for SIP & RTP,
LAN: 192.168.0.1
This scenario is similar, https://supportforums.cisco.com/thread/2266476, but it looks to be ip based rather than protocol based.
Thanks for any help.
Solved! Go to Solution.
02-13-2014 05:58 AM
Hi Robert,
Unfortunately, PBR route-maps can not directly refer to class-maps, so they can not directly use NBAR. What you can do, however, is to first classify and mark ingress packets using NBAR, and then configure the PBR to act upon DSCP markings instead of just IP addresses.
We have been discussing this scenario quite recently here:
https://supportforums.cisco.com/message/4160940#4160940
Best regards,
Peter
02-16-2014 04:59 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Thanks Peter. On rare occasion, I'm found Cisco documentation inaccurate. It's nice to know it works as it's documented.
To OP, Peter's suggestion answers your question, although I would still lean toward using both links with QoS, if possible. PBR is a pain to maintain and it can get messy when you start dealing with failure. For example, if you have your special traffic take the second link, you'll want it to move back to the primary link if the secondary fails. If you get that right, then you might have to deal with your special traffic's performance suffering if you don't have QoS. But if you have QoS, either link should be able to provide redundancy for the other and/or both could be used.
02-13-2014 04:22 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I don't recall whether NBAR can be used as part of PBR. If it can, the answer should be yes.
PS:
Perhaps a better solution would be to use both links with QoS.
02-13-2014 05:42 AM
I've been looking into NBAR, and would like to use it with PBR if that's possible.
02-13-2014 05:58 AM
Hi Robert,
Unfortunately, PBR route-maps can not directly refer to class-maps, so they can not directly use NBAR. What you can do, however, is to first classify and mark ingress packets using NBAR, and then configure the PBR to act upon DSCP markings instead of just IP addresses.
We have been discussing this scenario quite recently here:
https://supportforums.cisco.com/message/4160940#4160940
Best regards,
Peter
02-13-2014 09:15 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Unfortunately, PBR route-maps can not directly refer to class-maps, so they can not directly use NBAR.
Yea, that's the part I couldn't recall. Not surprised it's not.
What you can do, however, is to first classify and mark ingress packets using NBAR, and then configure the PBR to act upon DSCP markings instead of just IP addresses.
I had thought of that, but also wasn't sure PBR could "see" the ingress policy map set markings in its PBR policy (on the same box). The key is, as you note in your reference, "On ingress, QoS marking is performed before PBR." Peter, have you actually tried this?
02-16-2014 04:20 AM
Hi Joe,
Sorry for responding lately.
The key is, as you note in your reference, "On ingress, QoS marking is performed before PBR." Peter, have you actually tried this?
Yes, I did test it when I first wrote my reply in the other thread. It worked.
Best regards,
Peter
02-16-2014 04:59 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Thanks Peter. On rare occasion, I'm found Cisco documentation inaccurate. It's nice to know it works as it's documented.
To OP, Peter's suggestion answers your question, although I would still lean toward using both links with QoS, if possible. PBR is a pain to maintain and it can get messy when you start dealing with failure. For example, if you have your special traffic take the second link, you'll want it to move back to the primary link if the secondary fails. If you get that right, then you might have to deal with your special traffic's performance suffering if you don't have QoS. But if you have QoS, either link should be able to provide redundancy for the other and/or both could be used.
02-13-2014 01:48 PM
I appreciate all the help so far here, it has been a good learning experience. Here is the current configuration, but it is mapping all traffic to the next hop (T1 gateway), instead of the default gateway which is set for the ip route statement.
---------------------------------------------------------------------------------------
class-map match-all SIP
match protocol sip
class-map match-all RTP
match protocol rtp
class-map match-all TFTP
match protocol TFTP
policy-map For-PBR
class SIP
set dscp af13
class RTP
set dscp af13
class TFTP
set dscp af13
ip access-list extended AF13
permit ip any any dscp af13
route-map PBR-NBAR
match policy-list For-PBR
set ip next-hop T1GatewayIP
ip route 0.0.0.0 0.0.0.0 DefaultGatewayIP(Not T1)
int gig0/1
ip address 192.168.0.1 255.255.255.0
ip policy route-map PBR-NBAR
service-policy input For-PBR
02-13-2014 02:34 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
You could simplify that a bit.
class-map match-any forAF13
match protocol sip
match protocol rtp
match protocol TFTP
policy-map For-PBR
class forAF13
set dscp af13
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: