[SR-Users] Having kamailio bind to a VRF device
George Diamantopoulos
georgediam at gmail.com
Thu Oct 12 16:56:47 CEST 2017
Hello,
That seems strange... What kind of device is that VPN device? Like a ppp0
interface? What is the output of "netstat -plunt | grep kamailio"? Are you
using a "private" IP for the VPN interface and what's your main routing
table like?
Also what if you omit the "listen" directive in kamailio configuration?
Does it listen on the VPN interface then? Kamailio will bind by default to
all interfaces if no "listen" directive is used...
On 12 October 2017 at 00:26, Mark Boyce <mark at darkorigins.com> wrote:
> Hi All
>
> Just to dive in here with something which may be related. I was about to
> do a post with a much simpler problem where I have one real NIC and one VPN
> created NIC. If I listen to the public IP all’s well. If I listen to the
> IP of the VPN NIC Kamailio doesn’t see any traffic. I can tcpdump on
> either NIC and see the traffic arriving.
>
> Anyone seen / solved this before?
>
> Cheers
> Mark
>
> On 11 Oct 2017, at 22:07, George Diamantopoulos <georgediam at gmail.com>
> wrote:
>
> Hello Daniel,
>
> I'm including the original sketch for clarity:
>
> +----------+ +-------------------+
> | eth0 | | vrf-green |
> | 1.1.1.1 | | 127.0.0.1 |
> +----------+ +-------------------+
> |
> +----------+
> | eth1 |
> | 2.2.2.2 |
> +----------+
>
> Thanks for the reply. Indeed, using the advertise option for the "listen"
> directive will result in kamaiio no longer failing to start when using
> force_send_socket(2.2.2.2:5060) with 2.2.2.2 being used in the
> "advertise" option.
>
> However, this doesn't make much of a difference in that kamailio still
> won't process IP packets arriving on eth1 at IP 2.2.2.2... I can see
> OPTIONS coming with sngrep, but nothing in the logs, no replies, only
> retransmissions from the originator.
> In addition, while without VRF kamailio will select the right interface
> with mhomed=1, this is no longer the case.
> Also, If I try to send something to a host with force_send_socket, the
> transaction fails with 477 Unfortunately error on sending to next hop
> occurred. In the log, kamailio prints something along the lines of:
> udp_send(): sendto(sock,0x7f5c4f937d08,1888,0,9.9.9.9:5060,16): Invalid
> argument(22)
> udp_send(): invalid sendtoparameters
> msg_send_buffer(): udp_send failed
> where 9.9.9.9 is the $dd and presumably force_send_socket(2.2.2.2:5060)
> has been called before t_relay()
>
> Also, I additionally found out that if the networking configuration is as
> follows:
>
> +----------+ +-------------------+ +-------------------+
> | eth0 | | vrf-green | | vrf-red |
> | 1.1.1.1 | | 127.0.0.1 | | 127.0.0.1 |
> +----------+ +-------------------+ +-------------------+
> | |
> +----------+ +----------+
> | eth1 | | eth2 |
> | 2.2.2.2 | | 3.3.3.3 |
> +----------+ +----------+
>
> Then this won't work for vrf-red:
> listen=vrf-green:5060 advertise 2.2.2.2:5060
> listen=vrf-red:5060 advertise 3.3.3.3:5060
> One needs to use different IPs for the MASTER devices (say 127.0.0.1 and
> 127.0.0.2) for kamailio to startup with the above listen directives.
>
> It's a bit surprising it doesn't work. According to a user on cumulus
> slack channel (cumulus contributed the VRF code to the linux kernel): "any
> app that has a command line or option switch to call SO_BINDTODEVICE on the
> sockets can be configured to use any VRF".
>
> I guess the problem lies in that kamailio binds to several sockets and
> there are multiple routing tables to consult, so mhomed doesn't work as
> expected (if every table has a default route and nothing more specific than
> that). But still, this doesn't really explain why binding to the VRF master
> net devices doesn't work (I mean, "ping -I vrf-green" works just fine for
> ping)...
>
> I don't think VRF support is very useful for most users though, I just had
> one corner case I needed to tackle and VRF seemed like an easy fix. I'll
> think of an alternative at some point, I guess.
>
> On 26 September 2017 at 09:52, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
> >
> > Hello,
> >
> > I haven't worked with vrf here, so no first hand experience ...
> >
> > What happens if you try with next option?
> >
> > listen=vrf-green:5060 advertise 2.2.2.2:5060
> >
> > Cheers,
> > Daniel
> >
> >
> > On 25.09.17 19:10, George Diamantopoulos wrote:
> >
> > Sorry to bump this, but it would be very useful if I knew whether
> there's any point in pursuing this or not. Any hints?
> >
> > On 21 September 2017 at 14:06, George Diamantopoulos <
> georgediam at gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> I have a use case where I need to have kamailio bind to a VRF device.
> The configuration in question is similar to the example below, where eth1
> is a slave to the VRF-lite device:
> >>
> >> +----------+ +-------------------+
> >> | eth0 | | vrf-green |
> >> | 1.1.1.1 | | 127.0.0.1 |
> >> +----------+ +-------------------+
> >> |
> >> +----------+
> >> | eth1 |
> >> | 2.2.2.2 |
> >> +----------+
> >>
> >> Both the main routing table and "vrf-green" routing table have a
> default route.
> >>
> >> What I need to be able to do is have kamailio bind to both interfaces:
> >>
> >> listen=eth0:5060
> >> listen=vrf-green:5060
> >>
> >> And additionally be able to use force_send_socket to select an
> interface, for example:
> >>
> >> force_send_socket(udp:2.2.2.2:5060);
> >>
> >> However, I can't get this to work. The above configuration fails
> because there is no listen directive for 2.2.2.2. Also, kamailio doesn't
> process packets received on the VRF with the above listen directives, it
> behaves as if it doesn't listen on 2.2.2.2 indeed.
> >>
> >> In addition using either of the below:
> >>
> >> listen=udp:2.2.2.2:5060
> >> or
> >> listen=eth1:5060
> >>
> >> fails with an error upon starting kamailio.
> >>
> >> According to the kernel documentation:
> >>
> >> Applications that are to work within a VRF need to bind their socket to
> the
> >> VRF device:
> >>
> >> setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
> >>
> >> or to specify the output device using cmsg and IP_PKTINFO.
> >>
> >> The question is, is VRF useable with kamailio right now? Or is
> development needed? Thanks!
> >>
> >> BR,
> >>
> >> George
> >
> >
> >
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > --
> > Daniel-Constantin Mierla
> > www.twitter.com/miconda -- www.linkedin.com/in/miconda
> > Kamailio Advanced Training - www.asipto.com
> > Kamailio World Conference - www.kamailioworld.com
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171012/e41c7142/attachment.html>
More information about the sr-users
mailing list