Original scenario:
The configuration of Cisco CUBE is attached.
As you can see, on CUBE there are two IP connections (practically two VoIP trunks, one for each customer).
Incoming and outgoing calls to/from customer A are OK. SIP signalling is OK and the RTP flows are OK.
Incoming and outgoing calls to/from customer B are not OK. SIP signalling is OK, RTP flow from the softswitch to the customer B is OK, RTP flow from the CUBE to the softswitch is not OK.
My goal is:
- send the VoIP packets (SIP+RTP) of customerA using the interface F0/0 of the CUBE using the next-hop 172.16.16.21
- send the VoIP packets (SIP+RTP) of customerB using the interface F0/1 of the CUBE using the next-hop 172.16.16.25
To do it, I configured a "route-map" and I applied the route-map to the traffic self-generated by the router using the command "ip local policy".
This is OK for SIP signalling traffic.
The RTP traffic is not handled by the "route-map".
After a lot of debug I've understood that the RTP packets are forwarded in CEF using the global routing table where I configured only one static route to reach the softswitch.
If I change the static route and I use the other next-hop of CUBE (172.16.16.25 instead of 172.16.16.21) the problem passes from customerB to customerA.
SOLUTION: a U-Turn loop
The PBR can be applied only on the ingress traffic.
I fixed my issue using a trick. I've created a U-Turn loop using Loopback and Tunnel interfaces in order to apply the PBR to the incoming RTP traffic on the Tunnel 2 interface.
config added:
interface Loopback1
description U-Turn Loop IN interface to handle RTP traffic
ip address 10.0.1.1 255.255.255.252
!
interface Loopback2
description U-Turn Loop OUT interface to handle RTP traffic
ip address 10.0.1.5 255.255.255.252
!
interface Tunnel1
description U-Turn Loop IN interface to handle RTP traffic
ip unnumbered Loopback1
tunnel source Loopback1
tunnel destination 10.0.1.5
!
interface Tunnel2
description U-Turn Loop OUT interface to handle RTP traffic
ip unnumbered Loopback2
ip policy route-map out_policy_base_routing
tunnel source Loopback2
tunnel destination 10.0.1.1
ip route 0.0.0.0 0.0.0.0 Tunnel1 permanent !-- remove the previous one route
new scheme:
Now the call flow is ok for both customers.
