[OpenSIPS-Users] mediaproxy stops relaying packets

Jeff Pyle jpyle at fidelityvoice.com
Fri Jul 24 14:34:41 CEST 2009


Hi Ruud,

Well that was easy...  Resetting the rp_filter values to 0 fixed it.  I had
forgotten about that until I looked in the /etc/sysctl.conf on your
recommendation and noticed the change from before.

Now, everything acts as expected with the route tables while the relay is
forwarding in userspace.  All packets enter and leave through eth1.  As soon
as it flips to the conntrack rule the tables no longer apply.  Outbound,
relayed packets leave with the correct eth1 source IP address but via eth0.
Inbound packets still arrive via eth1 since that's the IP they're sent to.

I don't know enough about kernel route tables and conntrack rules to begin
to explain the odd interaction.  I suppose it doesn't matter much, now that
reverse path filtering has been disabled once again.

Ultimately I suppose it doesn't matter.  Both interfaces connect to a
layer-3 switch that doesn't know what reverse path filtering is.  Upstream
from the switch is all one IP pipe anyway.

Thanks for your help.



- Jeff


> On 7/24/09 7:02 AM, "Ruud Klaver" <ruud at ag-projects.com> wrote:
> 
>> I'm sure this is somehow related to the rather peculiar setup you
>> have, using more than one public interface. That being said, I don't
>> think it's impossible to use mediaproxy in this situation, but I
>> assume the problem and solution can be found in your Linux system setup.
>> 
>> Let's first see if I understood your setup correctly:
>> - eth0 is used for anything but RTP relaying and the system default
>> route is on the subnet attached to this interface.
> 
> Yes.
> 
>> - eth1 is used for RTP relaying and the media-relay is configured to
>> use this IP. Is it indeed configured to do that?
> 
> Yes.
> # grep relay_ip /etc/mediaproxy/config.ini
> relay_ip = [eth1 IP]  (a.k.a [Relay IP])
> 
> 
>> - The Relay IP you've mentioned thus far is the IP of eth1. In fact,
>> the IP of eth0 is not seen anywhere. Is that correct?
> 
> Yes.  The only place it shows up is in the communication between the relay
> and the dispatcher, never for RTP.
> 
>> - The only PSTN gateway to which calls are successful are on the
>> subnet that is attached to eth1.
> 
> Yes, although this wasn't always the case on this relay.  Something has
> changed.
> 
>> - Although the default gateway is behind eth0, you have set up routing
>> by using "route tables that set the next-hop of the packet based on
>> the source address". What does that mean exactly? Don't you mean
>> destination IP?
> 
> No,  source.  If the source of the outbound packet belongs to the IP of the
> eth1 interface*, it gets sent to the eth1 default gateway.  Here are
> specifics:
> 
> The /etc/iproute/rt_tables files contains this:
>   100    PROD_VOICE
> 
> In rc.local I have:
>   ip route add table PROD_VOICE default via [Voice Subnet GW]
>   ip rule add from [Voice Subnet]/28 table PROD_VOICE
>  
> * This is almost true.  Instead of the actual IP of the interface, I use the
> "if it belongs to the subnet" rule so I can copy the same rule around to
> multiple systems.  I've never had any problems with this before on CentOS
> and Ubuntu distros, running Opensips, Asterisk, and a little bit of Yate and
> Freeswitch.
> 
>> I'm starting to suspect this may have something to do with a proc
>> filesystem option called "rp_filter", but I don't know exactly what
>> yet. Please confirm what I said above and give me some more details on
>> your routing setup.
> 
> That makes sense.  I have the following lines in /etc/sysctl.conf:
>   net.ipv4.conf.default.rp_filter=0
>   net.ipv4.conf.all.rp_filter=0
> 
> When I check the current values, I see everything set to 1.  I'll do some
> testing to see if their mysterious reversal is related to the
> non-forwarding.  Maybe this answers the "what's changed" question.
> 
> 
> - Jeff




More information about the Users mailing list