cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
964
Views
8
Helpful
8
Replies

Two WAN uplinks, need to route based on protocol (not port based)

bbobbo177
Level 1
Level 1

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.

2 Accepted Solutions

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

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

View solution in original post

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.

View solution in original post

8 Replies 8

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

I've been looking into NBAR, and would like to use it with PBR if that's possible.

Peter Paluch
Cisco Employee
Cisco Employee

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

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?

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

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.

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

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

Getting Started

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: