[OpenSIPS-Users] mediaproxy stops relaying packets

[Jeff Pyle]

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