Is there any way to direct traffic through a second / dedicated WAN interface based on the protocol?
See, we have coax and fiber, but we would prefer to have all VoIP travel via our fiber, and any other traffic over the coax. The coax, of course, has bigger bandwidth and can handle the data traffic, but the fiber would be preferable for voice application. I was looking at one of the vyatta documents and it showed a way to use WAN2 as a failover for voice only, but I have not run across anything that tells me if we can dedicate the second WAN for voice only, without redirecting an entire subnet or specific machines. One of the problems I would have redirecting a subnet is that our VoIP will be coming out of the computers, as they are going to be using USB headsets. I know that we can prioritize the RTP/RTCP and SIP protocols, but if I can completely separate them, that would make it better.
If this is possible, please point me in the right direction.
Well, I currently have an SF200 Cisco switch, but will be using SG200 switches by the time we move to five9 cloud VoIP.
For a moment I thought ‘Natting’ would be the way to go, but I could not find RTP/RTCP or SIP in the list of protocols under /etc/protocols. I did not find DSCP, either. I know that VoIP makes use of UDP, but so do other applications, so I don’t want to direct traffic for all UDP to the second WAN. I could try port source and/or destination, but not sure if that is the best option.
I think you could use a static route and masquerade. Though, the fiber interface would have to be physically down to fail-over, logical or upstream physical problems would not be detected.
Do you guys know what happened to the qos-policy command? what replaced it? I found a guide on how to setup QoS with DSCP in Vyatta, but when I tried to do “set qos-policy traffic-shaper DSCP” as the guide says, I get [qos-policy] is not valid.
As for that 510 Software Group config, I am not knowledgeable in the VyOS command lines, to be able to replicate that policy. I might have to read up a lot more to understand it.
I found an old post by you in which you were looking for the same solution… did you resolve your problem by using natting? Or were you able to use policy routing?
My main concern is that I do want to make use of load-balancing failover, which it seems disables natting, so I am thinking that a policy based routing would be better than a basic nat setup. But if all else fails, I guess I would have to use whatever is available.
which documents my quick test of PBR using latest Lithium nightly build. Using Carl’s PBR doco, I was able to get it working quite easily. Hopefully you can achieve the same…
