[LARTC] Problem with Julian Anastasov's routing patches

2007-10-01 Thread François Delawarde

Hello,

I wanted to try some multipath setup with Julian's patches, and when 
rebooting on the newly patched kernel, without any multipath routes 
(only one interface up and one default gateway), my SSH connections to 
the server freeze after a few seconds. I tried with and without bridges 
(I sometimes have a bridge between a tap device and my eth0) with the 
same results.


When I close and try to reconnect, sometimes it works, sometimes it 
doesn't, but when it does the client (on my laptop) always stops 
receiving data from the server after a random time, between 1 and 60 
seconds approximately. Also HTTP connections to the server's apache 
daemon seem to suffer from this problem, and I usually have to reload 
the page from my browser several times in order to have a complete page 
(it usually stops in the middle of the page loading).


Tracing with tcpdump on the laptop, the connections seem still up (the 
server sends ACK packets, and when closing the console on the laptop, I 
can see the FIN stuff closing TCP connection successfully), but the ssh 
console is frozen on the laptop (no real replies from server apart from 
ACK).


I tested several times with and without the patches, and it strongly 
appears to be related to Julian's patches.

- Is it a known issue for these kernels (2.6.21)?
- Is there a way to repair that in order to be able to use these patches?

I'm using a vanilla kernel 2.6.21.7 with the following patches:
- IMQ
- Layer 7
- Julian's route patches (version for kernel 2.6.21)

relevant parts of .config:
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
...
# CONFIG_BRIDGE_NETFILTER is not set
# CONFIG_BRIDGE_NF_EBTABLES is not set
CONFIG_BRIDGE=m

Thanks for any help,
François.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] incoming traffic + iptable

2007-03-01 Thread François Delawarde

Hello,
I would need to be able to do that, as I think that iptables is more 
powerful for classifying traffic you want to police/shape. I don't 
really know tc yet, so could you tell if it has the possibility of 
detecting:


- mac addresses
- ip tos/ttl values
- icmp types
- tcp/udp flags/ports or port ranges
- layer 7 protocols

Thanks for help,
François.


Nikolay Kichukov wrote:

Hello there,
Why would you want to mark the packets with iptables in the first place for
ingress shaping?
Why don't use the tc functionality to specify source and destination
addresses and protocol types?

I would suggest to leave iptables alone and get your hand on TC for doing
traffic control ;-)

So in your example:

  tc qdisc add dev eth0 handle : ingress
  tc filter add dev eth0 parent : protocol ip prio 1 u32 match ip src
172.28.54.41/32 police rate 1kbit burst 1kbit mtu 1500k drop flowid
:

Thats an elegant way to achieve what you want.

HTH,
-nik

p.s. Mind the burst parameter, seems huge value to me.


- Original Message - 
From: mohican 542003

To: lartc@mailman.ds9a.nl
Sent: Wednesday, February 28, 2007 4:39 PM
Subject: [LARTC] incoming traffic + iptable


Hello,

i try to use iptables to mark packet and then to filter them with tc. Here
is my script:
  iptables -t mangle -A PREROUTING -s 172.28.54.41/32 -p tcp -j
MARK --set-mark 1
  tc qdisc add dev eth0 handle : ingress
  tc filter add dev eth0 parent : protocol ip prio 1 handle 1 fw police
rate 1kbit burst 1kbit mtu 1500k drop flowid :1

I can not use u32 because i have several filter with more than one IP
address in each.

Packets seem to be well marked (command:  iptables -t mangle -L -vnx)
but packets are not filtered with tc.

Can someone help me ?

Thanks,

Olivier.




___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  

___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] SIP, NAT, and load balancing problems

2006-12-14 Thread François Delawarde
I unfortunately think that I can't use that solution (if I understood it 
well).


My box actually has two functions, it's an Asterisk box and a load 
balancing router.


For LAN clients, as this box represents their default gateway, there 
would be no problem in implementing a pure routing solution. I could 
create a new subnet on a dummy interface, and reconfigure all LAN SIP 
phones to point to that IP, the box itself would route packets to its 
dummy interface.


For WAN clients, what I need is to have a unique interface (a unique 
public IP) accepting SIP connections, and outgoing traffic always 
passing by this interface. My current issue is with outgoing SIP/RTP 
traffic that sometimes gets load-balanced and uses the other public IP, 
which i have to force to the other interface, with lots of 
NATing/Re-Routing problems, as a single call can have multiple UDP flows 
(SIP and RTPs).


My main problem with the DummyNet solution on the WAN side is that I 
cannot access to the internet routers behind this box, so I can't add 
routes to reach a new subnet. This means that I'm back with the same 
type of problem trying to NAT, but this time not only the box's outgoing 
traffic, but also the clients incoming traffic, for them to reach the 
dummy0 interface.


Tell me if i'm wrong, but that solutions appears to me as more 
complicated in my particular case. Aouch, that's much harder than I 
thought it would be. :-(


François.


Grant Taylor wrote:

François Delawarde wrote:
What i meant is that people (in #asterisk on freenode) told me that 
Asterisk could be bound to a unique IP, or to all IPs (binding it to 
0.0.0.0). But if you know a way to bind it to only some IPs, then 
yeah! I need your help :-) I guess we need to put something in the 
bindaddr parameter of sip.conf. Right now I have:


[general]
bindaddr=0.0.0.0

I have 3 IPs in 3 interfaces:
eth0 (LAN): 192.168.10.1
eth1 (WAN): 192.168.1.2 (gw 192.168.1.1)
eth2 (WAN): 192.168.2.2 (gw 192.168.2.1)

How can I bind Asterisk SIP to 192.168.10.1 and 192.168.2.2 only, to 
work around my load balancing problem?


I'll email you off the mailing list as this does not pertain to LARTC.

If Asterisk is only listening to one IP and you are routing to get 
to your other network, you could end up with some really weird 
issues that will be very difficult to over come, probably MUCH 
harder than resolving the issue with Asterisk only binding to one 
interface.


I don't really understand what you mean, but that's right, i have 
really weird issues.


What I was saying is that if Asterisk is only bound to one IP address,
be it loopback, eth0, eth1, or even a dummy0 interface, you will have to
route traffic to that address.

If you can indeed only bind Asterisk to only one IP address or all IP
addresses on the system, I would recommend that you use DummyNet to bind
Asterisk to.  However this may be a problem down when NATing comes in to
play.  (More on this later.)

Supposing that you bind Asterisk to the dummy0 interface, either all
equipment will need to its self know how, or the default router for the
equipment will need to know how to reach the subnet on the dummy0
interface.  This usually means that you will have to have the default
gateway for all client systems / phones know how to reach the subnet on
the dummy0 interface.  I.e. the default gateway will have to have a
route to the subnet on the dummy0 interface via the interface on the
Asterisk box facing the router(s).

Consider:
   +--+
   | Asterisk Box |
   | [A.B.C.D/NM]-|---(INet)
(192.168.0.0/24)---|-[192.168.0.254/24]   |
   |   [192.2.0.254/24]   |
   |  |   |
   +--+
  |
   [dummy0]

In this case, 192.168.0.254/24 is the LAN, the internet is it's own 
IP, and 192.2.0.254/24 is assigned to the dummy0 interface.  If you 
bind Asterisk to the 192.2.0.254 IP on the dummy0 interface, you will 
have to route all traffic that is to or from Asterisk in to and out of 
the dummy0 network.


Now that you can easily see that you would have to route traffic in to 
and out of the dummy0 interface, I can probably better explain the 
weird routing issue that you have.  You are binding Asterisk to an IP 
on your system.  No matter what IP you bind Asterisk to, traffic from 
any other subnet will have to be routed to that subnet to reach Asterisk.


With this in mind, now consider if you bind Asterisk to one WAN 
interface, traffic to / from your LAN or the other WAN interface will 
have to be routed to be able to reach Asterisk.  If you bind Asterisk 
to the LAN interface, traffic to / from either WAN will have to be 
routed to be able to reach Asterisk.


Usually routing traffic is not an issue.  However, as you have pointed 
out, when you MASQUERADE traffic as it leaves either of your WAN

Re: [LARTC] SIP, NAT, and load balancing problems

2006-12-14 Thread François Delawarde
I have ip_nat_sip compiled in the kernel (and not as a module). Is that 
an issue?


Could you give me an example of how I could do using CONNMARK and fwmark 
based routing if I have an outgoing RTP flow bound to the wrong interface?


Thanks a lot,
François.

Patrick McHardy wrote:

François Delawarde wrote:

I was thinking of trying that along with the netfilter SIP helper, but I
don't even understand how helpers work yet. If you have an idea of how i
could use those things, it would also be worth trying.


Just load ip_nat_sip, it should adjust the SDP information according to
the NATing done on the connection. You need to make sure though that
the RTP stream really does use the same connection (and NAT) as the
SIP connection, which is best done by using CONNMARK and fwmark based
routing.



___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] SIP, NAT, and load balancing problems

2006-12-13 Thread François Delawarde

Thank you for suggestions, below are my comments:

Grant Taylor wrote:
The redirection is working, but the source port is changed by the 
MASQUERADE, and this doesn't work with SIP/RTP, which contain reply 
information (ip/port) inside its packets.


If Asterisk is running directly on the firewall box, why are you even 
MASQUERADEing or SNATing the packets?  Why not have Asterisk bind 
directly to the external IP?  This way MASQUERADE will not get in your 
way as far as changing the ports on you.
It's actually the first thing i tried, but as I need to offer service to 
both WAN and LAN, and the Asterisk SIP cannot bind to multiple IPs. It 
only offers to bind it to a unique IP or 0.0.0.0 (and from the feedback 
i got, they don't intend to implement that any time soon). I could 
probably run multiple instances or implement this myself, but I don't 
have that much talent and time to do those complicated things. :-)


Below you can find my network configuration (rules, routes and 
addresses). Anyone has an idea of how i could resolve this problem?


I'm looking, but for some reason I can not find it.  ;)

Some things to consider:
 - Set up a routing table just for Asterisk.
 - Identify Asterisk traffic via MARKed packets.
 - MARK the packets based on the OWNER match extension.  To do this 
Asterisk would need to run as it's own user, which should not be a 
problem.
I tried the owner match thing, maybe I did it wrong, but I end up with 
the same type of problems. When Asterisk needs to send traffic to WAN, 
it seem to bind to one of the two WAN IPs at random, and I end up with 
the same NATing problems when it chooses the wrong interface/IP. I also 
tried to inverse that: MARK all packets that are not Asterisk, put a 
special rule/table for that traffic and configure default (from all) 
routing table to only one WAN interface. I'm not 100% sure if i did it 
correctly, but do you think it's worth trying again?


Maybe this could be the type of solution I'm looking for if only i knew 
a little more about that. Do you know how a process chooses an IP when 
binding to 0.0.0.0? Is the kernel doing this, and how/when? Maybe I 
could cheat in that case, and make Asterisk or the kernel or whichever 
does the binding think that there is only one WAN interface.


Also do you think that I could use some help from the netfilter SIP 
helper? I didn't try but I think it would probably do the same.



Grant. . . .
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc



Thanks a lot for your time,
François
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] SIP, NAT, and load balancing problems

2006-12-13 Thread François Delawarde

Andrew McGill wrote:

On Tuesday Dec 12, 2006 around 3:44pm, François Delawarde wrote,


Hello all,

I have a linux machine with a SIP server (Asterisk) and 2 WAN 
interfaces (NATed) configured to do load balancing. I experienced 
problems with the SIP/RTP protocols and load balancing, because when 
initiating a call to an external SIP Host, a new RTP flow starts from 
the server to the Host, that sometimes uses another default route 
(due to the nexthop configuration). As i have two different public 
IPs, the external host gets confused while receiving flows from 
different IPs, and doesn't work (or sometimes we only have one-way 
communication).


There is a similar problem with openvpn which the --multihome patch in 
2.1_rc* solves (SOL_IP / IP_PKTINFO option on the socket).  Unless the 
application (asterisk in your case) chooses to bind a UDP socket to a 
particular IP address, the routing subsystem will assign the IP 
address.  Since UDP is connectionless, there is no reason to use the 
same IP address as the incoming 'connection'.  (ip_conntrack doesn't 
count.)


I cannot bind Asterisk to a particular IP address, as I need to use it 
for both LAN and WAN, but if the routing subsystem assigns the IP, does 
it take into account netfilter MARK and special rules, or do you know a 
way to force this routing subsystem into assigning an IP address?


I'm trying to understand when and how this IP address is chosen, and see 
if I can act at that level (doing NAT and ROUTE things doesn't seem to 
work a lot, and it's probably too late to work the problem.





*You* may be able to solve the problem with some creative use of the 
CONNMARK target (I didn't succeed). The best solution, in the absence 
of a kernel hack to treat UDP as a connection-oriented protocol, is to 
fix asterisk (IMHO, IANAKH).


:-)


I was thinking of trying that along with the netfilter SIP helper, but I 
don't even understand how helpers work yet. If you have an idea of how i 
could use those things, it would also be worth trying.



Thank you very much,
François.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc