Re: [LARTC] Rout looping through local host.
Hello, On Tue, 21 Aug 2007, Grant Taylor wrote: > I want to be able to take traffic in from a local LAN on eth0 and route > it out eth1 to a default gateway with a static IP. I want said default > gateway with the static IP to be assigned to eth2. I then want to route > and masquerade traffic that came in eth2 out eth3. > > (Enter ASCII art) > > --+ >Context 0 | > +--+ +---+ > +---+ eth0 |--+ Local LAN | > | +--+ +---+ > | | > | +--+ > +---+ eth1 +---+ > +--+ | >| | > ==|===|=== >Context 1 | | > +--+ | > +---+ eth2 +---+ > | +--+ > | | > | +--+ +--+ > +---+ eth3 +--+ Internet | > +--+ +--+ >| > --+ > > I want the ""router in context 0 to effectively (for the sake of > discussion) do basic static NAT routing for the local LAN. This router > will have two static IP addresses, LAN facing and upstream router facing. > > I want the ""router in context 1 to effectively (for the sake of > discussion) do basic MASQUERADing for the equipment behind it. This > router will have one static IP facing the LAN and one dynamic IP facing > its upstream provider. > > I have followed Julian Anastasov's directions > (http://www.ssi.bg/~ja/send-to-self.txt) and applied his Send-to-Self > patch (http://www.ssi.bg/~ja/send-to-self-2.6.22-1.diff) to a stock > 2.6.22 kernel and I am able to ping the IP address assigned to eth2 from > eth1 with out any problems. However I don't think Julian's patch covers > routing traffic through (not terminating at or originating locally) the > cross over cable. Yes, patch works for output routes only. May be you can try to forward traffic with ip rules with iif parameter. Make sure you have rules and routes for both directions. Of course, there must be some IP addresses because routes work only for devices with IPs. SNAT should be able to assign non-local external IP address, not possible for MASQUERADE, you have to use SNAT everywhere. That is, don't configure the SNAT addresses. Then you should not see local IPs in the traffic. Not sure for other pitfalls. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Using Julian Anastasov's 'routes' patches on 2.4 kernel in conjunction with IPSec
Hello, On Thu, 28 Jun 2007, Seba Tiponut wrote: > The _updown script is only called when a tunnel is brough up or down, but the > problem I am having is not related to a tunnel, but to routing before any > tunnel gets established. > I mean that even a configuration with only one tunnel that is listening is > creating problems because both StrongSWAN and OpenSWAN add IP addresses on > the ipsecN interface that are identical to the ones on the real interface > (ethN). I think the problem is related to the presence of the ipsecN > interface in KLIPS (linux-2.4). On 2.6 kernels there is no such interface and > consequently there is no "conflict". Is there any real solution to this > problem? Long time ago it was in _startklips. I used something like this: ip link set ipsec0 down ip addr flush dev ipsec0 # It is safe to add all local GW IPs here, always with /32 ip addr add LOCAL_GW_IP/32 dev ipsec0 scope host label ipsecXXX ip link set ipsec0 up or ifconfig ipsec0 0.0.0.0 up should be enough. I.e. you still need some IP on ipsec devices but don't duplicate eth networks there. > On the other hand, my understanding of the solution you gave me (inserting a > rule "from LNET to RNET") is that it can be applied once the tunnel is up. > However, would you care to elaborate more on this case as well? Well, I found something in my sent-mail archives: You need 2 ip rules and one routing table for all ipsec devices, eg: # The traffic between gateways is not via ipsec device, i.e. # NORMAL_TABLE can be "main" ip rule add prio 100 from LOCAL_GW to REMOTE_GW1 table NORMAL_TABLE # Negotiated lnet-rnet goes via ipsec device ip rule add prio 200 from LNET1 to RNET1 table IPSEC_TABLE ip route add RNET1 dev ipsec0 table IPSEC_TABLE # There is no "via LOCAL_GW" in the route # Another tunnel: ip rule add prio 100 from LOCAL_GW to REMOTE_GW2 table NORMAL_TABLE ip rule add prio 200 from LNET2 to RNET2 table IPSEC_TABLE ip route add RNET2 dev ipsec1 table IPSEC_TABLE So, you have: - exception rules that route the ESP traffic via its normal routing table (ethXXX) - negotiated nets go via ipsec devices where we do not have gateways, plain device route - all routes to RNETs can be in same table where all ipsec devices are used in routes but it can be changed to have different tables per each ipsec device (in case same RNET is negotiated via different ipsec devices) There is a benefit: if the LGW box has local IP from LNET then it can reach the RNET via ipsec device. You do this by specifying "src LNET_IP" for all routes via ipsec devices if you really have local IP from this lnet (which is common), so it is better to always have "src lnet_IP" in all routes in table IPSEC_TABLE. As result, you have all possible data to give the right information to the routing: - LGW are not routed via ipsec devices - RNET sees valid lnet_IP when your gateway talks to RNET via ipsec (allowing even masquerade for LNET boxes to be used when talking with RNET). Hope that helps! > Cheers, > Seba. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Using Julian Anastasov's 'routes' patches on 2.4 kernel in conjunction with IPSec
Hello, On Mon, 25 Jun 2007, Seba Tiponut wrote: > I use Julian Anastasov 'routes' (to be more specific: static_routes, > alt_routes and nf_reroute) patches on a 2.4.32 kernel. On the same host I run > IPSec. I have discovered after a few hours of networking problems that, > when IPSec is enabled on that patched kernel, inspecting packets with tcpdump > while arping-ing a host from a network physically connected to this machine, > the arp requests show up on the ipsecX interface instead of the ethX > interface. When IPSec isn't running, Julian's code works fine. I suspect it > has something to do with having two interfaces with the same data (ipsecX > mirroring the configuration from ethX). > Can anyone give me a hint on how could I solve this problem? I've googled a > long time to no avail and I don't have the necessary skills to debug the > networking code from kernel. May be you have to replace your _updown script with one that supports "ip route" and "ip rule" commands instead of the old "route" tool. By this way you can use "ip rule ... from LNET to RNET" to properly route traffic for the negotiated subnets. If I remember correctly, the default _updown script does not consider negotiated LNET at all. As for routes patch, it will prefer NOARP devices when the neighbours on ARP device are not marked as reachable in ARP cache. So, it is risky to rely on wrong routes, especially after routes patch is applied. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: "dst cache overflow" messages and crash
Hello,
On Fri, 23 Mar 2007, Frédéric Massot wrote:
> >>>> I regularly have errors (kernel: dst cache overflow) and crash of a
> >>>> firewall under Linux 2.6.17 and the route patch from Julian Anastasov.
> >
> > I assume IP_ROUTE_MULTIPATH_CACHED is disabled. Do you have
> > BRIDGE_NETFILTER enabled/used?
>
> - IP_ROUTE_MULTIPATH_CACHED is not set
> - BRIDGE_NETFILTER is set, but I do not use it.
ok, then can you try the attached patch, it solves dst cache
problem for another user, may be it will help you too. This patch can
be used with or without routes patches. It makes sure we don't leak
dst entry in bridge-netfilter. If the patch does not help let me know
and we can add some printks to catch the problem.
Regards
--
Julian Anastasov <[EMAIL PROTECTED]>Bridge-Netfilter should be gentle when calling ip_route_input,
skb->dst can be already set.
diff -urp v2.6.20/linux/net/bridge/br_netfilter.c
linux/net/bridge/br_netfilter.c
--- v2.6.20/linux/net/bridge/br_netfilter.c 2007-02-11 01:06:29.0
+0200
+++ linux/net/bridge/br_netfilter.c 2007-03-23 01:07:40.0 +0200
@@ -269,6 +269,10 @@ static int br_nf_pre_routing_finish(stru
struct nf_bridge_info *nf_bridge = skb->nf_bridge;
int err;
+ /* Old skb->dst is not expected, it is lost in all cases */
+ dst_release(skb->dst);
+ skb->dst = NULL;
+
if (nf_bridge->mask & BRNF_PKT_TYPE) {
skb->pkt_type = PACKET_OTHERHOST;
nf_bridge->mask ^= BRNF_PKT_TYPE;
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: "dst cache overflow" messages and crash
Hello, On Thu, 22 Mar 2007, [ISO-8859-15] Frédéric Massot wrote: > >> I regularly have errors (kernel: dst cache overflow) and crash of a > >> firewall under Linux 2.6.17 and the route patch from Julian Anastasov. I assume IP_ROUTE_MULTIPATH_CACHED is disabled. Do you have BRIDGE_NETFILTER enabled/used? > I use the Linux kernel 2.6.17 and the route patch from Julian Anastasov. > > - The bug comes from the kernel or the patch? > > - Do you know if this bug were corrected in the new versions of the kernel? It should be the patch that triggers the problem. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] routing patches seem to break output nat
Hello, On Tue, 23 Jan 2007, Tim Haak wrote: > We have applied the routing patches from > http://www.ssi.bg/%7Eja/#routes. To 2.6.15 this seems to have broken our > output natting. Has anyone else experienced this or any advice on how to > fix. Is this working on the newer kernel i.e. 2.6.19 ? Any help would be > appreciated. Month ago Bart Duchesne found a problem with the routes patch for 2.6 where reply packet for -j DNAT connections initiated in OUTPUT are dropped in pre-routing. I now updated the patches and if you have the same problem you can try the new diffs from today, eg. http://www.ssi.bg/~ja/routes-2.6.19-13.diff The fix for old patches is to remove the following extra check (2 lines from net/ipv4/route.c) which obviously aborts ip_route_input() with EINVAL for RTN_LOCAL when replies from remote host are destined to our local IP: + if (lsrc && res.type != RTN_UNICAST && res.type != RTN_NAT) + goto e_inval; Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Multi-path routing only using last nexthop in default route.
Hello,
On Mon, 16 Jan 2006, Jody Shumaker wrote:
> ${IP} route add default table 221 proto static \
> nexthop via ${EXTGW2} dev ${EXTIF2} weight 1\
> nexthop via ${EXTGW1} dev ${EXTIF1} weight 5
>
> With this command, connections going out from my network always seem to use
> the GW1 route. I if I reverse the order of the nexthop's to list GW1 first
> and GW2 second, then the reverse happens and all outgoign connections use
> GW2. I'm going to attempt to test this better by attempting a large number
> of connections to a large list of ip's, but in running this setup I've never
> seen it use both gateway's.
Do you have script to ping/arping the gateways on eth device(s)?
The NOARP devices are always preferred if the GWs on ARP devices are
not marked reachable in ARP cache.
Regards
--
Julian Anastasov <[EMAIL PROTECTED]>
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ip route add default mpath (rr| drr|random|wrandom)...
Hello, On Mon, 26 Sep 2005, Krzysiek wrote: > Anyone using it? I've tried but after about 5 min I always get kernel panic. > My setup is based on nano.txt. I works well but only if > CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. I just wanted to play with the new mpath > feature of ip. But enabling CONFIG_IP_ROUTE_MULTIPATH_CACHED always resuts in > kernel panic. I'm not using any kernel patches from http://www.ssi.bg/~ja/ - > are they needed at all? - They do not apply cean. The kernel is 2.6.13. > This configuration does not work: 2.6.14-rc2 comes with fixes for CONFIG_IP_ROUTE_MULTIPATH_CACHED, but i declare that my routing patches are not compatible with this feature, until someone proves that both features work together. > CONFIG_IP_ROUTE_MULTIPATH=y > CONFIG_IP_ROUTE_MULTIPATH_CACHED=y > CONFIG_IP_ROUTE_MULTIPATH_RR=m > CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m > CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m > CONFIG_IP_ROUTE_MULTIPATH_DRR=m Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Load Balancer setting for Public Servers
Hello, On Thu, 17 Feb 2005, Sureerat P. (EQHO) wrote: > Regarding Julian's suggestion, do you mean that CONNMARK is not necessary > for this scenario? And also I don't have idea about lsrc and maddr you are connmark should work, you just need to set it up. > mentioning. Could you please provide me the reference site so I can get more > details about it. http://www.ssi.bg/~ja/dgd.txt http://www.ssi.bg/~ja/dgd-usage.txt > To tell you the truth, even I'm confused but more knowledges I get from > here. And I want to say "Thank you" for your all kindness. Tonight I will > study deeper about your guideline and do more testing. Any progress, I'll > update you via this mailing group. Yes, it is not easy, there is no complete solution for such setups as the details can be very different, you have to combine lots of scripts :) Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Load Balancer setting for Public Servers
Hello, On Thu, 17 Feb 2005, Nguyen Dinh Nam wrote: > Not enough, my tutorial only discuss about CONNMARK outgoing NEW packets > in POSTROUTING, if you want to DNAT connections from internet to some > computers in your LAN, you must also CONNMARK incoming NEW packets in > PREROUTING too. I want to keep the tutorial short and simple so I don't > write about it, you can consult CONNMARK in PREROUTING in RoutesKeeper's > source code. > Lacking CONNMARK in PREROUTING, some of your SYN/ACK packets may be > DROPed by ISPs. That problem should be solved with the "routes" patch, may be you know for some issue with this? First packet comes, DNAT selects manipulations for both directions, packet is routed to internal host, reply comes, we route by lsrc (maddr), one of the valid links for maddr is selected, it can be different if routing allows input and output routes to use diffrent interfaces (you don't know always the incoming gateway that remote hosts are using to reach maddr). What "routes" gives you is correct routing usage for NAT which is expected from all NAT users in multipath setups. > From kernel 2.6.10, CONNMARK is included already, you don't have to > patch anything. I'm happy with that, i just don't see the problems you see with "routes". Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Load Balancer setting for Public Servers
Hello, On Wed, 16 Feb 2005, Nguyen Dinh Nam wrote: > Although I don't agree with the approach of using JA's patch, I still > admit that nano-howto is a good howto, many people are using it > successfully. > > But nano-howto doesn't tell you to bind each connection to only one link > (internet connection), so some packets get dropped when get routed to > the wrong link. You can read about using CONNMARK here: > http://selab.edu.ms/twiki/bin/view/Networking/MultihomedLinuxNetworking It is controlled by correct routes. NAT connections are bound to masquerade IP (done in netfilter) but the patches guarantee this is propagated to the routing usage, look for lsrc in patch. It works for DNAT too. IOW, in some cases you can use more ISPs for maddr, for example, ISP1 for maddr_X->dest1 and ISP2 for maddr_X->dest2. Once maddr is selected for connection (from first packet), this maddr can be routed to one ISP (if the ISPs do spoofing checks) or to many ISPs, you can even use multipath route for 'from maddr to all'. So, for packets from single connection all requirements are met, traffic from maddr can use any/many alive links but only one at a time for specific maddr->dest path. When two NAT connections are related CONNMARK can solve the problem to route both of them to same path, sometimes this is done from the application modules, they select same maddr for related connections. Of course, other high level dependencies can be solved with CONNMARK, eg. web session persistence, may be with help from application modules. The problem here is that "routes" works only at routing level while CONNMARK work can be helped from other modules. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] problems with 2.4.28 + Julian's patch
Hello, On Wed, 9 Feb 2005, fun wrote: > I am using kernel 2.6.9 (gentoo,AMD64 version) + routes-2.6.9-11.diff > If compile kernel with gcc 3.4.3, then the similar error comes out: > > -- > net/ipv4/fib_frontend.c: In function `fib_validate_source': > include/net/ip_fib.h:181: sorry, unimplemented: inlining failed in call to > 'fib_result_table': function body not > available > net/ipv4/fib_frontend.c:204: sorry, unimplemented: called from here > include/net/ip_fib.h:181: sorry, unimplemented: inlining failed in call to > 'fib_result_table': function body not > available > net/ipv4/fib_frontend.c:214: sorry, unimplemented: called from here > make[2]: *** [net/ipv4/fib_frontend.o] Error 1 > make[1]: *** [net/ipv4] Error 2 > make: *** [net] Error 2 > --- > > Anyway, it will be OK if use gcc 3.3.5 to compile. Can Julian check that? > Thanks! It should be fixed month ago but you need routes-2.6.10-12.diff. Another option is to remove the fib_result_table "__inline__" from include/net/ip_fib.h > BR, > Dominic Lu Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] problems with 2.4.28 + Julian's patch
Hello, On Sat, 8 Jan 2005, Brad Barnett wrote: > With 2.4.28 and Julian Anastasov's > > http://www.ssi.bg/~ja/routes-2.4.27-9.diff > > patch, I get the following when I attempt to build my kernel. Any ideas? Can you try routes-2.4.28-9.diff, i just uploaded it after removing __inline__. > Thanks! > > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer > -pipe -mpreferred-stack-boundary=2 -march=i686 -fno-unit-at-a-time > -nostdinc -iwithprefix include -DKBUILD_BASENAME=fib_frontend -c -o > fib_frontend.o fib_frontend.c > fib_frontend.c: In function `fib_validate_source': > /usr/src/linux/include/net/ip_fib.h:178: sorry, unimplemented: inlining > failed in call to 'fib_result_table': function body not available > fib_frontend.c:253: sorry, unimplemented: called from here > /usr/src/linux/include/net/ip_fib.h:178: sorry, unimplemented: inlining > failed in call to 'fib_result_table': function body not available > fib_frontend.c:263: sorry, unimplemented: called from here > make[3]: *** [fib_frontend.o] Error 1 > make[3]: Leaving directory `/usr/src/linux/net/ipv4' > make[2]: *** [first_rule] Error 2 > make[2]: Leaving directory `/usr/src/linux/net/ipv4' > make[1]: *** [_subdir_ipv4] Error 2 > make[1]: Leaving directory `/usr/src/linux/net' > make: *** [_dir_net] Error 2 Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] RE: [LARTC] Load Balance simply doesn´t work...
Hello, On Fri, 27 Aug 2004, [EMAIL PROTECTED] wrote: > You mean that using NAT its impossible to do load balance or > this is the worng command? If its the wrong command, what´s > the right one? Don't disappoint, you can check the following patches and howtos: http://www.ssi.bg/~ja/#routes > Tks A LOT for the response! > Fernando Favero Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] trouble with nexthop when I try to load balance
Hello, On Fri, 20 Aug 2004 [EMAIL PROTECTED] wrote: > I have two internet lines and I want to do equal cost loadbalancing on the two > uplinks to the internet. This is what I do: You need to add ip rules for all tables, before they are used from other gateways in other routes. Then the kernel will see the routes in your tables, the gateways will become reachable and visible for all other routes you are adding. The difference is that you do not add the link routes in table main, for some reason you decided to add them in unused tables and the following command can not see the GWs. > ip route add default scope global nexthop via 100.100.100.254 \ > nexthop via 200.200.200.254 > > The last command fails with the message:"RTNETLINK answers: Invalid argument". > I found a posts that says to fix the iproute2/ip/iproute.c:parse_nexthops() > with change like this: > rtnh->rtnh_ifindex = 0; > + rtnh->rtnh_flags = 0; > + rtnh->rtnh_hops = 0; > rta->rta_len += rtnh->rtnh_len; > > I fixed the file, but get the same error "Invalid argument". > I don't know why it fails. I have a 2.4.20 kernel with Julian Anastasov's > patches. iproute2 version ss010824. Better use latest versions of iproute2. > I really need the solution to this issue. Please help me :( > Thanks in advance Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] rp_filter and fib_validate_source sequence in KPTD
Hello, On Mon, 9 Aug 2004, Martin A. Brown wrote: > Does it happen before NF_IP_PRE_ROUTING (PREROUTING) or not? After > Does it only happen at route selection time? Yes, input route only > If I understand the path correctly, the functions are traversed in this > order (from most deeply nested first): > > fib_validate_source() > ip_route_input_slow() > ip_route_input() > > ip_rcv_finish() > ip_rcv() The above is correct > It seems that ip_rcv() (in ip_input.c) calls the following, and I simply > do not understand what this means: > >return NF_HOOK(PF_INET, NF_IP_PRE_ROUTING, skb, dev, NULL, > ip_rcv_finish); > > I'm guessing that NF_IP_PRE_ROUTING (the PREROUTING hooks) are called > before ip_rcv_finish is called, which means that the rp_filter action > doesn't occur until after the PREROUTING hooks. Yes, routing happens after DNAT (prerouting), so rp_filter works with translated addresses. > Is this accurate? Can anybody shed some light? Is my interpretation > accurate? Yes, > Thank you very much, > > -Martin > > [0] http://www.ussg.iu.edu/hypermail/linux/kernel/0002.1/1522.html > [1] http://open-source.arkoon.net/kernel/kernel_net.png Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Syntax for u32 match of src mac at offset -8
Hello, On Wed, 14 Jul 2004, Gerry Weaver wrote: > I've been trying to figure out how to do bandwidth limiting by mac > address. There are several posts on this subject, but nothing concrete. > My question concerns the proper tc filter syntax to do a u32 match at a > negative offset of -8 that should based on what I've read be the source > mac address. I've been plating around with it, but no success yet. > > Any help would be much appreciated. http://mailman.ds9a.nl/pipermail/lartc/2003q1/006663.html > Thanks, > Gerry Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] tutorial for Julian Anastasov's patches
Hello, On Fri, 9 Jul 2004, Mohammad Reza wrote: > If one link is down, I except that routing will flush automatically > after 60 second. But this not happened. Keeping them alive with pinging > trick don't make any changes. The 'ping' trick works for gateways which become unreachable in the ARP cache when their link is down (which does not happen in all setups) or when the devices are marked down. In all other cases you have to recreate your multipath routes with script on fatal events such as "link" failed, indirect gateways are failed, device is registered/unregisterd, etc. > Regards, > Reza Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tutorial for Julian Anastasov's patches
Hello, On Wed, 7 Jul 2004, Glen Mabey wrote: > I'm sure that I had found (and printed out ...) a really good tutorial > that explain how to use Julian Anastasov's routing patch, but I can't > seem to find it now. > > Any pointers? http://www.ssi.bg/~ja/ Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: Load Balancing 4 cable modems, followed nano.txt
Hello, On Wed, 19 May 2004, Charles-Etienne.Dube wrote: > Hi, thank you for the fast answer > >Monday I configured the system again with multiple cable modems, > but only 2 that time. Until now, one modem transfered 2 gig and the > second one 1 gig. No complaints that time, so i'll leave it that way > till the end of the week to see if that setup is stable, but i still > need to add at least a third modem to obtain more troughput for peak hours. More internal users -> better sharing according to the weights :) >About the masquerade thing you said : > > -j MASQUERADE works for dynamic IPs and is recommended > for complex routing situations when using the "routes-*" patches > --- > > I'll stick with that, but a question about dynamic ip, the > documentation in nano.txt seems to be a setup for static ip. The cable > modem modem I use will change ip about 2-3 times a year so no big deal > for this. Right now I hardcoded their ip in my script, but please > confirm this : > > If I want everything to work with no maintenance (almost) If those > cable modems change ip, i'll need a script that detects it and then > dynamically change the routing table, because I can't do that kind of > routing with only interface names. I created a script that can manage addresses, ip rules, routing tables and next hops. It reads arrays with data from config file. It appears to work in initial tests for static addresses and routes but I understand that it would be good to modify the next hop definitions, eg. when ppp device names change or the IP addresses are dynamic. So far, I have written a little bit of the documentation but now I'll upload the current stuff here: http://www.ssi.bg/~ja/#routes If you are looking for something new for testing you can look for mpath/ and mpath-X.Y.tar.gz. It now contains settings for my tests. We should find a way to propagate next hops changes (and may be changes for ip rules). For now, it can be done by regenerating the config based on ip-up/ip-down scripts and notifying mpath.sh about this next hop event. I'm publishing it now just to see more ideas how the users actually prefer to manage their setup. > - > > Each modems are connected to their own network card on the server, so > yes they each have different interface. Is it possible to have it > working with for example, GWE1 & GWE2 be the same ip adresse ? Yes, the kernel normally lookups by output device but the patched kernel will match next hops by gateway too. In fact, MASQUERADE wins for setups that have two nexthops with same output device but different gateway IP because IIRC -j SNAT can not match gateway IP. > ip rule : > > 0: from all lookup local > 50: from all lookup main > 201:from 24.201.150.0/24 lookup 201 > 202:from 24.200.191.0/24 lookup 202 > 222:from all lookup 222 > 32766: from all lookup main > 32767: from all lookup 253 May be your ip rules need more work. I want to see what IP addresses are allowed for each uplink. You can follow such rules: - specify correct "from" and "to" in all ip rules and use only default routes in all tables when the routes are via gateway. - put in same routing table all next hops that can serve same source addresses, for example, can you put nexthops for eth1 and eth4 in a multipath route in same table and for which addresses? - provide different table for each uplink which is distinct from all others and provides internet for different subnet So, I'm not sure whether you need 3 or 4 tables for public IPs/subnets. The default table remains, of course. > So there if you check eth1 and eth4 are on the same network and share > the same gateway, could this be a problem ? Sort of. You must know what traffic you can send via each uplink and to explain it with ip rules and tables. The patched NAT strictly follows these rules. So, it is more correct when you use NAT to strictly define correct rules. For example: - know which IP or subnet can use particular uplink. I do not see specific 'from' ip rules for sources such as 24.201.150.222 and 24.201.150.250. May be each of them can use only its modem? You must know which table will be used for each source address and to tell it to the routing. > Thank You > > Charles-Etienne Dube Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: Load Balancing 4 cable modems, followed nano.txt
Hello, On Mon, 17 May 2004, Charles-Etienne.Dube wrote: > I did some tests with 2 cable modems, but now it is installed in a production > environment with 4 cable modems. At first, everything seemed to work fine.. > But now I had a couple of users tell me that some web pages were > not available while others were, and it semms to be a masquerading problem > since when I downgraded the system to one cable modem and normal routing > table with only one default gateway everything started working fine again (like > before). I am sure that the non-working URLs were valid sites that were available > at the time (ex: www.yahoo.com; www.google.com; www.hotmail.com). > > > Here are my questions : > > > 1 - Did I use to right patch ? I used "routes-2.4.20-9.diff" It is the right one > I tried to apply "05_nf_reroute-2.4.20-9.diff" Even if I'm used to > patching kernels, I don't understand that much about this process, and > the patch programm was giving error messages, while the one I use was applying > without any error messages. Stick with "routes-*.diff" because it is not enough to apply 05_nf* patch, there are two diffs to apply before it. > 2- Should I use : > > iptables -t nat -A POSTROUTING -o IFE1 -s NWI/NMI -j SNAT --to IPE1 > iptables -t nat -A POSTROUTING -o IFE2 -s NWI/NMI -j SNAT --to IPE2 > > instead of : > > iptables --table nat --append POSTROUTING --out-interface eth1 -j MASQUERADE -j MASQUERADE works for dynamic IPs and is recommended for complex routing situations when using the "routes-*" patches > Can anybody elaborate on the difference between these 2 commands. > > 3 - The 4 cable modems have a different IP, but two of them obtained an > ip in the same address class so they both have the same gateway. In my > script I treated them as if they were each on different gateways and I see > traffic going on the 4 modems so I don't think this is an issue but I'd > like to have some advice about this. What happens if all the IPs > are renewed at the same time and all 4 modems obtain an IP in the same > class with same gateway... will it still work ? If the gateways are same I assume they are on different interfaces. > 4 - do you think 4 cable modems is too much, has it been tested ? I do not remember how many nexthops allows the ip utility for multipath routes but 16 should be possible. > Help with this case would really be appreaciated, I am ready to give > any details that would be necessary for you to guide me further.. ip addr ip rule ip route list table all > Thank You > > Charles-Etienne Dube Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re[2]: [LARTC] Multipath Connection problem on RH-8.0
Hello, On Thu, 13 May 2004, Robert Kurjata wrote: > JA> To all: do you have some working script(s) that we can > JA> recommend for setups with 2 or 3 uplinks in multipath route? Then we > JA> can link them to the web page as reference. > [cut] > I've posted one in 2 links version. Now I'm using slightly extended > version for 4 links with policy routing :) Thank you, it is now linked. May be in the following days I'll try to create advanced version. > http://mailman.ds9a.nl/pipermail/lartc/2003q4/010372.html Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multipath Connection problem on RH-8.0
Hello, To all: do you have some working script(s) that we can recommend for setups with 2 or 3 uplinks in multipath route? Then we can link them to the web page as reference. On Thu, 13 May 2004, Muhammad Reza wrote: > now i downgrade to rh-7.2 (2.4.20-w/ julian patch)and iproute version > iproute2-ss010824. > but still cant do multipath routing. Then can you explain what you learned from "2.4 Keeping them alive" and what you have to keep the state for each GW from the multipath route valid? > this is my trace with ip route get; > [EMAIL PROTECTED] root]# ip route get 202.138.253.17 > 202.138.253.17 via 172.16.0.1 dev eth0 src 172.16.0.232 > cache mtu 1500 advmss 1460 > [EMAIL PROTECTED] root]# ip route get 202.138.253.17 from 192.168.0.2 > 202.138.253.17 from 192.168.0.2 via 192.168.0.1 dev eth1 > cache mtu 1500 advmss 1460 > [EMAIL PROTECTED] root]# ip route get 202.138.253.17 from 172.16.0.232 > 202.138.253.17 from 172.16.0.232 via 172.16.0.1 dev eth0 > cache mtu 1500 advmss 1460 > [EMAIL PROTECTED] root]# ip route list table main > 192.168.0.0/30 dev eth1 proto kernel scope link src 192.168.0.2 This is strange: > 172.16.0.0/24 dev eth0 scope link > 10.10.10.0/24 dev eth2 scope link It means your settings are not created from script. Also, the script does not bring dev eth0 up, there is a missing "up". > 127.0.0.0/8 dev lo scope link > [EMAIL PROTECTED] root]# ip route list table MRA > default via 172.16.0.1 dev eth0 proto static src 172.16.0.232 > prohibit default proto static metric 1 What do you have in table ADSL? Can you provide output from: ip addr ip rule ip route list table all > [EMAIL PROTECTED] root]# ip route list table DEF > default proto static > nexthop via 172.16.0.1 dev eth0 weight 1 > nexthop via 192.168.0.1 dev eth1 weight 1 > > with this configuration i still couldn connect to internet From where? What shows tcpdump -ln ... ? > regards > reza Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multipath Connection problem on RH-8.0
Hello, On Wed, 12 May 2004, Muhammad Reza wrote: > default proto static > nexthop via 172.16.0.1 dev eth0 weight 256 dead onlink pervasive > nexthop via 192.168.0.1 dev eth1 weight 1 > I search the list about this error, and found that i shall use the > upgrade version of iproute2, and i compile that too. > but with same config, and new iproute2 i can't connect to internet now. > please be advice, what wrong with my config (attach), and what version > of linux should work ? Can you check the example 'ip route get' commands and "2.4 Keeping them alive" from nano.txt. Make sure after upgrading iproute2 that your nexthops are not dead. Also, list you rules and routes and make sure they are valid, I see your commands but I do not know which of them are accepted from the kernel. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] arp src ip trouble
Hello, On Thu, 18 Mar 2004, Alexander Trotsai wrote: > Could I change src selection algoritm (or may be patches) In 2.4.26-pre2 you can try changing /proc/sys/net/ipv4/conf/DEV/arp_announce to 1 or 2. > I have linux kernel version 2.4.26-pre2 but I got the same > result with early versions of linux kernel Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multiple uplinks - load balancing
Hello, On Fri, 6 Feb 2004, Rokas wrote: > have their own SMTP servers. I have to use only one SMTP server to > send e-mail, so I set up SMTP server of ISP1 in my e-mail client > program. But because of load balancing, SMTP traffic sometimes go > through the second line ISP2, and then the SMTP server of ISP1 refuses > to accept my message. > > So I would like to "tie" SMTP traffic to ISP1 line. What rules should What about /sbin/ip rule add prio 80 to $SMTP_IP table 201 Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Two routing cache entries with different interface
Hello, On Sat, 10 Jan 2004, Tushar Thakker wrote: > hi all, > i am setting up a load balancing netwrok with failover, > i have applied julian patch, > but whenever i try to traceroute from any client node, it gives me two entries for > that destination, but i get different interface for that entries, > so it doesn't forward my requests, > i have done masquerading for client nodes, > > the ip rule/route are as follows, > > ip rule add prio 222 table 222 > ip route add default table 222 proto static \ > nexthop via $GWE1 dev $IFE1 weight 1\ > nexthop via $GWE2 dev $IFE2 weight 1 > > Now after traceroute failure, if i see the routing cache for that ip, it shows > following, output route, probably created from -j MASQUERADE?: > 205.158.62.141 via 203.88.135.213 dev eth1 src 203.88.135.212 > cache mtu 1500 advmss 1460 input route: > 205.158.62.141 from 192.168.1.51 via 203.88.135.205 dev eth2 src 192.168.1.242 > cache mtu 1500 advmss 1460 iif eth0 > > please see eth1 and eth2 in both entries, Nothing strange so far, may be they are created from different connections. In fact, there should be more cache entries. > now it does not forward this request, Can you provide more information, in private mail if you prefer so, including: - tcpdump output(s) for all interfaces during the traceroute - topology: are eth1 and eth2 connected to same hub? - ip rules and routes I hope you really have the "routes" patch applied and running. > what can be the reason behind this and please can anyone suggest me the solution, > thanx in advance, > Regards, > > -------- > Tushar Thakker > Elitecore Technologies Ltd. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multihome- routes patch problem
Hello, On Thu, 8 Jan 2004, hare ram wrote: > [EMAIL PROTECTED] patch -p1 < > /root/update/update/routes-2.4.20-9.diff What happens with routes-2.4.22-9.diff ? Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] simpler version, How to bypass the local routing table?
Hello, On Fri, 12 Dec 2003, Antony Lesuisse wrote: > So the problem is how to bypass the lookup in the table shown by: > ip route show table local http://www.ssi.bg/~ja/#loop Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: dead onlink
Hello, On Wed, 5 Nov 2003, Marcelo wrote: > default > nexthop via 192.168.0.126 dev eth2 weight 1 dead onlink > nexthop via 192.168.0.61 dev eth0 weight 1 > - > > Is normal the part of "dead onlink" ? No, you need the latest 'ip' utility from iproute2: ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz > This message is always there but the 192.168.0.126 gateway is online. > Do I need the Julian's dead gateway detection patch?. Not for this problem > Thanks in advance. > > Marcelo. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re[2]: local address routeable?
Hello, On Thu, 17 Jul 2003, Christian Stuellenberg wrote: > If traffic from zone MASQ is addressed to one of the external internet > addresses of one of the zone GOOD or DMZ, then it will currently get > routed directly at HOST. It is intended, that this direct routing is > not done, but instead ALL traffic from zone MASQ becomes masqueraded > out over the dynamic PPP connection to the internet, comes back over > the CISCO line to HOST, then gets routed to the extern destination IP > (in zone GOOD or DMZ) and when the reply from there comes back again > to HOST, it should get routed over the CISCO internet connection and > then back over the dynamic PPP connection, demasqueraded, and at last > delivered to the original source in zone MASQ. > > This works up to the point, where the reply comes back to HOST. Now > I'm not able to tell HOST, that this reply should again routed out > to the internet over the CISCO line and only demasqueraded if it comes > in over the PPP connection (btw. the demasquerading does also not > occur if the reply gets not routed; I assume, this is because the > masquerding tables are waiting for a packet that comes in over the PPP > connection and not on IF0 or IF1). I think, I understand the setup. I'm still wondering what is the end goal. I can only speculate: Assumption 1. Hosts from GOOD want to see client from DynIP, not from a.b.c.62. The solution: use SNAT with saddr=DynIP when talking to GOOD because the default masquerade action is to use a.b.c.62 which is recommended from the routing. I assume GOOD and DMZ do not care how the packet with saddr=DynIP appeared as long as it looks as expected? 2. For some reason (even by introducing security problems) you want packets with saddr=DynIP to walk the external path and to reach GOOD. Is it needed? Is there a problem with the above solution in #1? > Regards, > Christian Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] local address routeable?
Hello, On Mon, 7 Jul 2003, Christian Stuellenberg wrote: > I've got a problem to set up a configuration that shoud allow to route > packets that come in over a certain interface(s) IF1 that then should > go out to another interface IF2 but are addressed to the local address > of interface IF3. So only if packets for the address of interface IF3 > come in over interface IF3 they should be locally accepted. Yes, you have a big problem. Starting from kernels 2.4 and above the routing requires valid source IPs for output routes. Even if you deliver locally the incoming traffic your servers can not generate reply if the src IP is not local IP. What I do not understand from your posts is what is the main goal? Also, what means "..."? Please, draw picture with all wires and all kinds of hardware involved: hubs, routers, subnets. > +--+ > +---IF2/IP2-| HOST |-IF1/IP1---...LAN > . +--+ > . | > . IF3/IP3 > | | > | | > | | > +-Internet--...+ > If I'm right, this should tell me, that the kernel now no longer can > recognize its IP3?! Yes, the routing code does additionally lookup for IPs configured on interfaces (yet). The routing decisions are based on: - routing table lookups - IP lookups and checks > So, is it possible to do what I wanted to do or did I did something > not the right way? I'm not sure there is a right way. The task is not trivial. May be in some next kernel that allows the admin to create any route and not to apply any IP checks. You now do not have the full right to add any routes, that is the problem. You can not control the spoofing checks when saddr=local_IP, the preferred src IP must be local IP. > I'm sorry if this question has been asked over and over again, but I > have googled and looked into the archives but haven't found a solution > that fits my needs. > > Best regards, > Christian Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] two upstreams without nat
Hello, On Wed, 25 Jun 2003, Tomas Bonnedahl wrote: > im in the process of configurating our network to have two upstream > providers, it will be loadbalanced > under normal operation and a complete failover if one of the lines would > fail. > > internet internet > | | > borderborder > | | > |- core router - | >| > lan The problem is that the multipath route assumes one packet can go through any of the defined nexthops. This is valid for setups with many ISPs allowing spoofing, you can safely send packet with saddr=IP1 via ISP2 and this works as long as ISP1 is UP to receive the replies from remote hosts. But for your setup there is one requirement: once one connection is routed via Border X all its packets should go via the same border router for NAT purposes. Even the related ICMP traffic. And this works ... for some time until the routing cache is flushed and different Border router is selected from the multipath route. The connection usually dies. > the "problem" im having is that i will not do nat on the core router, but on the > border routers. > the multipath default route is on the core router. from what i understand, could be > totally wrong, > you have to have nat, at least connection tracking on the core to make the multipath > route per > flow and not per packet. I'm not sure the Linux conntracking has such feature. IIRC, the netfilter follows the routing decision, i.e. nobody guarantees that packets from one connection will continue to use same nexthop while it is alive. Considering the fact that all cache entries expire (on user request or on timeout) the current implementation can not guarantee such persistence for the forwarded connections that have multiple possible paths. This works only if the core router performs NAT and when the NAT implementation does not blindly follow the multipath route decision. The problem can be solved in this way: the NAT connection requests route with saddr=the external IP address attached for this connection. As result, the multipath route is avoided and the traffic for one connection is bound to one ISP (usually): http://www.ssi.bg/~ja/#routes > any insight of this? > > > -tomas bonnedahl Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] modifying ethernet header dst mac with ebtables?
Hello, On Fri, 4 Apr 2003, Martin A. Brown wrote: > : I´m working in a briding enviroment and i want to be sure that my arp > : requests outgoing a bridge interface will be hear by only one specific > : device (because of security reason) Victor, what about trying something similar to the example in the ebtables docs: ebtables -t nat -A PREROUTING -d ff:ff:ff:ff:ff:ff -i eth0 -j dnat --to-destination 54:44:33:22:11:00 > : are there any way to re-write the ff:ff:ff:ff:ff:ff on this arp request > : so they appears like a unicast? > > I imagine that Julian will jump in here and reply to you, but I thought > I'd point you to ip arp, an add-on tool Julian has written for iproute2. > > http://www.ssi.bg/~ja/#iparp iparp can not see these packets (layer 2) but for other purposes probes can be originated with unicast dst MAC in this way: ip arp add table output to 1.2.3.4 lldst 00:11:22:33:44:55 > : Do de ip stack understand this "unicast" arp request? Yes but at MAC level the ARP code cares only for unicast/broadcast, no matter the actual dst MAC of the received packet. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multiple Uplinks with the same gateway ip?!
Hello, On Thu, 3 Apr 2003, Michael Schoen wrote: > Due to the fact, I have the same gateway, I used the iif parameter for > policy routing -> is that the problem?? Try without using iif, just "dev pppXXX", without "via GWIP", i.e. check what happens when using only "nexthop dev pppX" This command should return error, missing "via" before GWIP: > ip route add default table 222 proto static \ > nexthop via 217.5.98.12 dev ppp0 weight 1\ > nexthop 217.5.98.12 dev ppp1 weight 1 Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] What's wrong with this loadbalancing ?
Hello, On Thu, 3 Apr 2003, Sjaak Nabuurs wrote: > iproute2 version ss001007 is running a newer version gives deadlink on > pervasive (whatever it means) !!! This version fixes the problem: ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 2.2.x crash after patching (Was: Prioritising IngressTraffic)
Hello, On Sat, 22 Mar 2003, Gordan Bobic wrote: > I seem to be having a problem with the newly applied patches, though. After > 6-8 hours, I get a kernel crash. Black screen od death, hex dumps, Aiee, > killing interrupt handler, trying to kill idle task, etc. This happened > twice, so it seems unlikely to be a coincidence, as the only patches applied > were the DS9, rtree, HTB3 and routes. It used to be stable before. I am > hoping that it is ingress related stuff that kills it, so I have turned that > off (everything to do with ingress). We'll see if I get another crash now. If > not, than it would appear that it is ingress policing that kills it after a > while. > > I will report back on this when I know more. ok, it is interesting where is the oops exactly (may be by avoiding modules and compiling qos in kernel). In any case, I created patch to upgrade to HTB 3.10 > Regards. > > Gordan Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Prioritising Ingress Traffic
Hello, On Thu, 20 Mar 2003, Gordan Bobic wrote: > Provided the DS9 patch works for me, is it possible to somehow prioritize what > is dropped first and what is dropped last? Something like attaching a > prio/cbq to the ingress qdisc? For example, I want SSH/POP3/IMAP4 traffic to > be dropped last, and FTP/SMTP traffic to be dropped first. Can ingress > support in DS9 do this, or is it limited to indiscriminately dropping > traffic? Except if someone has another idea, may be only dropping. I'm not sure there is IMQ for 2.2 :) May be you can look at Edge31-ca-u32 from the iproute2 examples, there are some ideas about using policers. As for DS9, it tries to provide the same interface to all qos objects as in 2.4, so it is possible to do the same things as in 2.4, of course, there is one problem, nobody wants to support new features in 2.2 :) Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Routing/forwarding/shaping problems in v2.2.x (Long -sorry)
Hello, On Thu, 20 Mar 2003, Gordan Bobic wrote: > > The only problem is that I still didn't upgraded the patches to > > 2.2.25, may be in the next days I'll find time to do so. > > It all patched cleanly anyway, don't worry about it. I patched 2.2.24 and then > patched that to 2.2.25. I haven't compiled it yet because I am not in front OK, I see that skb_padto is used only from the net drivers, so it is not fatal that skb_copy_grow will not copy skb->tc_index, so I hope DS9 will work > Excellent. Note that I also use policy routing so that the sessions started to > ethX will always be reponded to on ethX. I think that is fairly standard > (things break horribly otherwise). However, what happens when a host randomly > alternates between IP addresses it is starting sessions to/from? This sort of > worked before, but it quickly started to break. I take it that with the > routes patch things will not fall apart like before? Yes, the patch keeps each NAT connection bound to the masquerade address and correctly uses the routing, usually for multipath routes. Of course, in 2.2 a route cache flush leads to much more problems (CPU cycles for rerouting) compared to 2.4. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Routing/forwarding/shaping problems in v2.2.x (Long -sorry)
Hello, On Thu, 20 Mar 2003, Gordan Bobic wrote: > The setup: > > "Home brewed" v2.2.24 (will patch to v2.2.25 later today) with the DS8 patch > applied. Currently downloading the DS9/rbtree/htb3 patches to be applied > later (obviously, unpatching the old DS8 first), and see if at least some of > my problems go away. Yes, DS-8 has many problems including security ones. The only problem is that I still didn't upgraded the patches to 2.2.25, may be in the next days I'll find time to do so. > Multiple cable/DSL lines with multiple default routes and equal cost > multipath. I strongly recommend the route patches in such case: http://www.ssi.bg/~ja/#routes-2.2 http://www.ssi.bg/~ja/routes-2.2.20-7.diff > When applying ingres shaping (policing filter) all executes fine without > reporting any errors, but > > tc -s -d qdisc show dev eth1 > and > tc -s -d filter show dev eth1 DS9 has fixes for the ingress stats > Can anyone hazard a guess as to why this is not doing what it should be? Is > this a know bug in DS8 and DS9 will fix it? I will try it anyway, just to > make sure, but some encouraging news would be nice. :-) Yes, yes, I'll add it to the changelog > 2) ipmasqadm portfw unstable/unreliable > > I have tried to use this approach to forward ports from the firewall to an > internal server. It works OK initially, but within minutes, things start > going wrong. Some connections get through on one interface but not the other. > Later, connections from the same host will work on a different interface, but > not the one it worked on initially. Such problems should be solved from the "routes" patches, they will keep each traffic through its ISP. Read nano.txt from http://www.ssi.bg/~ja/#routes It is for 2.4 but the concept and the routing rules are same. > TIA. > > Gordan Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multiple internet providers
Hello, On Tue, 18 Mar 2003, Martin A. Brown wrote: > that is your intended goal, you'll need to check out the Nano-HOWTO (Hey > Julian--this appears to be missing right now): > > http://www.linuxvirtualserver.org/~julian/nano.txt The source site is: http://www.ssi.bg/~ja/ The old URL is still maintained but as mirror, not under my control, may be it is now back as redirect (http://www.linuxvirtualserver.org/~julian/) to the primary site. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Incorrect source address in ARP request. Anyone seen
Hello, On Tue, 18 Mar 2003, Arno Griffioen wrote: > > requests with src 17.70.0.1? Linux ARP follows the routing and will > > reply in this case (when used in place of the router). > > Yes that's true. Unfortunately it seems that Linux is one of the few > who implement this behaviour. Others seem to hold the view that > ARP is a link-level protocol and as such only has any relevance for > the scope defined on the interface itself. Hm, may be yes > So even though it's technically possible and legal to do so according > to the RFC, it's unfortunately not often used in practice.. The RFC does not recommend when to reply and it allows implementations with different behavior. > > to handle such case. The problem comes only if "router decides not > > to accept ARP from valid source IP from valid input device". > > Which seems to cover almost all dedicated routers (eg. Cisco) and probably > quite a few other OS'es too. Argh, I didn't tried with other OSes. The replies are unicast at link layer so I wonder why one should care what is the src IP if it passes the source address validation. > > Take a look at arp_solicit() > > Saw that.. I'll mangle it a bit so it will only send out the > link address. That way it's compatible with what other devices expect. If you like the idea of patching I have the exact patch for you: http://www.ssi.bg/~ja/01_arp_prefsrc-2.4.12-5.diff from http://www.ssi.bg/~ja/#routes Note that arp_prefsrc will work for your setup but it is not entirely correct for all users, the plain kernel has the correct behavior. Then playing with iparp can give you the desired behavior for the interfaces and gateways you want: http://www.ssi.bg/~ja/#iparp ip arp add table output from 17.70.0.1 src 0 Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Incorrect source address in ARP request. Anyone seenthis?
Hello, On Mon, 17 Mar 2003, Arno Griffioen wrote: > There seems to be one snag: Incorrect ARP source address. > > If there is no ARP entry for the gateway yet (no traffic has gone out, routes > learned from another BGP peer) and I try to reach a remote address immediately > then the ARP request that goes out on the 10.0.0.0 network for the > correct gateway does *not* contain the 10.0.0.2 source address, but > instead 17.70.0.1. > > Well.. That obviously does not work as this IP address does not occur on > this LAN and as a reasult most other routers will (correctly) ignore this. No, the router should answer this request because it knows where 17.70.0.1 is: it is on the LAN or at least reachable via gateway on this LAN. So, what is the good reason to ignore ARP requests with src 17.70.0.1? Linux ARP follows the routing and will reply in this case (when used in place of the router). > If I try to connect to the correct gateway on a 10.0.0.x adress directly > then it does work as it will use the correct 10.0.0.2 source for it's > ARP request. Correct > It seems that the ARP code also chooses the 'global' scope address for the > ARP request, while it should really always choose the 'link' address > of this interface as the source of the broadcast. No, the check is: is the source address in the IP packet local? If yes, use it as src for ARP - classic case where ARP must be accepted in router if the IP packets are accepted: if you have the right to send IP packets with src=17.70.0.1 is there a reason to ignore ARP with same src? In your case there is no reason, of course, there are other cases where tuning the ARP protocol is needed. > I have now temporarily fixed this by either adding some static ARP entries > or ARP-table filtering using iptables, but I feel that's only a temporary > measure. You are in the right direction, there are no many solutions to handle such case. The problem comes only if "router decides not to accept ARP from valid source IP from valid input device". > Have I overlooked something in my setup or should I start poking in the > kernel ARP code? Take a look at arp_solicit() Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: bug after new patches where applyed
Hello, On 7 Mar 2003, Esteban Ribicic wrote: > ive got some strange error: (after ip route patches where applyed) > > [EMAIL PROTECTED]:~# ip route get 172.0.0.2 > Truncated message Even after kernel is fully recompiled? The patches change headers, so make is not enough. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ip rule nat Pathces!?
Hello, On 5 Mar 2003, Esteban Ribicic wrote: > julian, > the patch stuff is making me crazy (i have four servers running > iproute2).. > > i tryed to apply pathces on 2.4.20 in the following order so multipath, > nat, fwmark works: > > routes-2.4.20-9.diff > rtmasq-2.4.20-2.diff Use rtmasq-2.4.20-routes9-2.diff instead, I just uploaded it. Apply it after routes-2.4.20-9.diff and let me know offline if it compiles and works. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ip rule nat
Hello, On 4 Mar 2003, Esteban Ribicic wrote: > when doing somehitng like > ip rule add fwmark 3 nat 200.42.75.183 table ppp0 prio 1 > (the idea is that packets that match the fwmark 3 change their source > address to 200.42.75.183)..it first apply the nat and then routes to > table ppp0 right? > in such case the, nat, why may be nat not being applyed? > cause it doesnt work at all..it goes to that interface but does not nat > the src address of the package. > any idea? It is not supported but there is a patch: http://www.ssi.bg/~ja/#rtmasq Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] NAT: multiple route lookups; local use of NAT IP
Hello, On Sun, 2 Mar 2003, Martin A. Brown wrote: > Part I > - - - - - - > I am using a stateless (iproute2) NAT installation here as a concrete > example around which to ask my question about cases where route lookups > are required. > > I do not understand the entire sequence of route lookups required. > Intuition and observation suggest to me that there have to be two separate > route lookups. I would like confirmation and/or further explanation, if Yes, the source code shows more lookups :) > Here's my current understanding: > > 1 packet arrives from 192.168.14.2 on eth2 bound for 10.17.254.1 > 2 route exists in local routing table; rewrite packet for 172.17.254.1 > 3 ?? > 4 rewritten packet is transmitted on eth3 to 172.31.254.1 > > It seems that there must be a route lookup for 172.17.254.1 at step 3. > How does the kernel know to perform a second lookup? Currently, the kernel performs 2nd fib_lookup into the only ip_route_input call when the resulting route is from type NAT. Its goal is to find a real unicast route (route to the internal host) with valid outdev and gw because the NAT route contains only the NAT and the internal network (encoded in nh_gw). The 2nd lookup when SNAT is performed is avoided because the NAT/MASQ address is present in the ip rule. I assume, you know that Netfilter does not support anymore local address or 0.0.0.0 in ip rule nat. > Under what other situations would there be multiple route lookups for the > same packet? As for any other lookups during the packet traversal, Netfilter uses ip_route_output at many places with the goal to find nexthop when route key parameters are changed: addresses, fwmark, etc. > Part II > - - - - - - > Of less importance to me, but a peculiar side effect of the stateless NAT, > I find that I can never connect to IPs configured for NAT on the box in > question. The NAT addresses are not local ones. They can be used only from other hosts. This is one of the drawbacks. Also, playing with NAT addresses for servers introduces many problems when internal hosts talk to them after DNS name lookups. It is questionable whether using dumb NAT routes resolves the complexity in the routing rules. But there are cases where using stateless NAT is useful for the higer layers. > These commands were run on the NAT router in the above diagram. > > # ping -n 10.17.254.1 > connect: Invalid argument > # ping -I 192.168.0.13 -n 10.17.254.1 > PING 10.17.254.1 (10.17.254.1) from 192.168.0.13 : 56(84) bytes of data. > ping: sendto: Invalid argument > ping: sendto: Invalid argument > > --- 10.17.254.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100% packet loss > > Is this a side effect of the NAT entry in the local routing table? Talking to NAT addresses is prohibited for output routes (originating traffic). "Invalid argument" is a good indication for this :) This is one of the drawbacks I already mentioned. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re[2]: [LARTC] Policy routing and strange packets traversing.
Hello, On Sun, 2 Mar 2003, Tomasz Wrona wrote: > BTW. I also used patch for 2.4.x kernel to enable "equalize" > parameter [witch parameter doesnt work at all] but this patch and "routes" patch > from Your websitee do not apply together.. only one of them > works. May be there are some collisions. But if "equalize" works for balancing your ISPs then you don't need the "routes" patches. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Policy routing and strange packets traversing.
Hello, On Sun, 2 Mar 2003, Tomasz Wrona wrote: > > This looks a bit strange, it is not needed: > > > > > # To be sure that traffic goes to proper gateway > > > 22: from 1.1.1.30 lookup 1 > > > 22: from 2.2.2.66 lookup 2 > > Why, It's the same what You pointed me below... ? OK, I overlooked it > > > 30: from all to 1.1.1.29 lookup 1 > > > 30: from all to 2.2.2.65 lookup 2 > > OK, but I process main table after all manual typed rules... but never > mind its not issue ;) It is not good to put table main after other rules, it can be used only to override route in table main. For example, why traffic from 1.1.1.29 to some internal IP should go to the ISP gateway (table 1)? > > Don't expect from Netfilter to use correctly the routing, > > you have to avoid using "iif" when playing with Netfilter. Just > > use "from XXX". > > Hmmm... I cant understand what has netfilter to do with "iif" parameter ? > What I want to achieve is to catch all incoming traffic on eth1.. There are some places that can use output rerouting where the iif parameter is ignored. And second, the normal kernel relies on the routing cache to keep persistence for each NAT connection to its selected nexthop. There is no guarantee that it will work for the whole connection life. > > but you will need rules "from all to all" for > > proper default route selelection and source IP autoselection for > > the masquerading. > > > Balance table catches all traffic from LAN to inet.Thats all what I need. It does not work all the time. > > http://www.ssi.bg/~ja/#routes > > > > dgd-usage.txt contains example for rules and routes you can use. > > Hmm... Maybe I am wrong but It's related to NAT multiple gateways on > single interface not on different what I have... Not exactly true, it is related to making sure each NAT conn is bound to its allowed path(s), no matter how many interfaces are used. Selecting different nexthop should be allowed only if it is alternative allowed from the routing rules. > There shouldn't be problem what I read in this article. Then why you see traffic to the wrong gateway? Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Policy routing and strange packets traversing.
Hello, On Sat, 1 Mar 2003, Tomasz Wrona wrote: > Rules related for this interfaces and traffic: This looks a bit strange, it is not needed: > # To be sure that traffic goes to proper gateway > 22: from 1.1.1.30 lookup 1 > 22: from 2.2.2.66 lookup 2 You already have link routes to these IPs in table main > ... > # This rules are unnecessary I think but used for diagnostics gateways > #by me. Yes, you don't need them: > 30: from all to 1.1.1.29 lookup 1 > 30: from all to 2.2.2.65 lookup 2 > > #Balance tables distributes traffic from LAN. Don't expect from Netfilter to use correctly the routing, you have to avoid using "iif" when playing with Netfilter. Just use "from XXX". > 70: from all iif eth1 lookup balance > > > # ip r l ta 1 > default via 1.1.1.29 dev eth2 > # ip r l ta 2 > default via 2.2.2.65 dev eth4 > # ip r l ta balance > default > nexthop via 1.1.1.29 dev eth2 weight 2 > nexthop via 2.2.2.65 dev eth4 weight 3 > > So. Everything works but I have observed some behaviour what > I can't understand.. I don't know what works but in theory it should not work, you don't have routes that restrict each ISP traffic through its gateway. May be in your case each of the ISPs allow spoofing. > What I expected was that trafic nated to 1.1.1.30 goes throught eth2 > and traffic nated to 2.2.2.66 goes throught eth4. Then specify it to be so: ip rule add prio 20 from 1.1.1.30/30 table 1 ip rule add prio 20 from 2.2.2.66/27 table 2 but you will need rules "from all to all" for proper default route selelection and source IP autoselection for the masquerading. The normal kernel can not give you this, you need other solutions, eg: http://www.ssi.bg/~ja/#routes dgd-usage.txt contains example for rules and routes you can use. > Unfortunatelly when become listening on eth4 with following command: > tcpdump -n -i eth4 src 1.1.1.30 > I can see trafiic which I am not expecting on this interface: > 1.1.1.30.3145 > 217.98.144.187.20: P 1608:2144(536) ack 1 win 16616 (DF) > 1.1.1.30.4282 > 212.77.100.17.: . ack 1889 win 17520 (DF) > > The simmilar is on eth2: > tcpdump -n -i eth2 src 2.2.2.66 > 2.2.2.66.6114 > 217.17.41.85.8074: P 58257:58281(24) ack 530714947 win 7506 (DF) > > Of course more packets have correct sources [1.1.1.30 for eth2 and > 2.2.2.66 on eth4] but I cant see the reason there are some missed > packets... > I did experiment and attached iptables DROP rule on POSTROUTING on > eth2 and eth4 interfaces to catch bad sourced packets but they didnt > catch anything what says for me this "bad" traffic didnt really go > through incorrect interfaces. May be it is the POST_ROUTING who is guilty for selecting wrong nexthop and you can not notice it, this mistake is visible on device output. > So that I am confused on this packet traversing.. Could someone explain > this behaviour ? Is it OK or I have missed something ? You can read about such issues, use the above URL > Regards, > tw > -- > > --- > ck.eter.tym.pl Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] A small correction to LARTC (fwd)
Hello, On Thu, 16 Jan 2003, Dragan Simic wrote: > I had 2.4.x in mind when I wrote this about rp_filter values. In any case, > in the LARTC should be cleared out what applies to 2.2 branch, and what to > 2.4 branch. It's true, in 2.2.23, there are three options (0,1,2); and > there are two options (0,1) in 2.4.20. This is wrong, all kernels (2.2, 2.4, 2.5) treat 2 as 1, i.e. only 1 and 0 are enough to distinguish the two possible states: enable/disable source address validation. As for all/rp_filter, it is only a flag that says "0 disables the spoofing check for all interfaces". include/linux/inetdevice.h is a good source for information about whether 0 or 1 as value for all/XXX changes globally the feature for all interfaces. For rp_filter it is 0, for send_redirects it is 1. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Is negative offset possible in u32 ?
Hello,
On 14 Jan 2003, Eric Leblond wrote:
> I look at the kernel code, I'm almost a real beginner here so I could
> wrote stupid things :
>
> I saw that in the file cls_u32.c we work with skb and use only
> skb->nh.raw. That's the network header, so we don't have any information
> about Ethernet header (it's in skb->mac.raw that we have the ethernet
> header and that the protocol is given).
Everything starts from the net drivers (drivers/net/*.c):
- dev_alloc_skb() is used to reserve skb head space for the eth hdr
and data space for the packet
- NIC stores ethhdr and packet there
- eth_type_trans() is called to set skb->mac.raw and to skip
the eth header by incrementing skb->data with skb_pull()
- net/core/dev.c sets skb->nh.raw = skb->data and packet is
passed to upper layers where tc ingress works
> Furthermore (maybe i'm wrong cause of inverted stockage in memory) in
> the skbuf struct the ethernet header union follow the network header
> union so we should read something else.
tc sees:
skb:
+---+ head
| | before ofs=-14: more reserved bytes
| | ofs=-14: dst mac
| | ofs=-8: src mac
|ethhdr | ofs=-2: eth proto
+---+ dataofs=+0, same as nh.raw
|packet |
| |
+---+ tail
| |
+---+ end
As for u32_classify, nh.ptr is used as base offset, later the 'ptr'
is adjusted by signed int offsets, so it can touch lower addresses.
> Thus we can at least say that negative offset in u32 are really "tricky"
> and really non clean and as seems to show experiment that they don't
> work (?)
This is a hack, of course (may be designed so). But
it works for me (tm)
Regards
--
Julian Anastasov <[EMAIL PROTECTED]>
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB and ARP
Hello, On 14 Jan 2003, Eric Leblond wrote: > I did not manage to push arp packet in the wanted queue. I use the > following syntax : > > tc class add dev eth0 parent 1:1 classid 1:4 htb \\ > rate 512.0Kbit ceil 512.0Kbit burst 1.28Kbit prio 0 > tc filter add dev eth0 protocol ip u32 \\ > match u16 0x0806 0x at -2 flowid 1:4 > > Do I need special options in the qos code (special modules ...) No, no more hacks, just use "protocol arp" instead of "protocol ip". Then you can avoid matching the eth proto code at -2. The filter's "protocol XXX" uses skb->protocol which is built from the eth proto code for eth devices (returned from eth_type_trans). So, "protocol ip" is ETH_P_IP, "protocol arp" is ETH_P_ARP and so on. See the "llproto_names" array in iproute2 (lib/ll_proto.c) and ll_proto_a2n() used from tc/tc_filter.c Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can I Classify Non-IP Traffic?
Hello, On Thu, 2 Jan 2003, Martin A. Brown wrote: > : > Decimal Ofs Description > : > --- > : > -14: DST MAC, 6 bytes > : > -8: SRC MAC, 6 bytes > : > -2: Eth PROTO, 2 bytes, eg. ETH_P_IP > : > 0: Protocol header (IP Header) Yes, I'm using sort of: Egress (match Dst MAC): ... match u16 0x 0x at -2 match u32 0xM2M3M4M5 0x at -12 match u16 0xM0M1 0x at -14 Ingress (match Src MAC): ... match u16 0x 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3 0x at -8 Where is the Eth Proto Code (from linux/include/linux/if_ether.h): 0800ETH_P_IP and M0..M5 are the 6 bytes of the MAC address Example for matching ETH_P_IP for MAC 00:11:22:33:44:55 Egress: ... match u16 0x0800 0x at -2 match u32 0x22334455 0x at -12 match u16 0x0011 0x at -14 Ingress: ... match u16 0x0800 0x at -2 match u16 0x4455 0x at -4 match u32 0x00112233 0xFFFF at -8 Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Problem With Load Balancing the Links
Hello,
On Mon, 23 Dec 2002, hare ram wrote:
> as you have mentioned in the documents, the last time should be default, but
> why iam getting 253 here
Table "default" (253) is always there but we don't use it
because we want table "main" before 201 and 202.
> 0: from all lookup local
> 50: from all lookup main
> 201:from 202.63.96.0/24 lookup 201
> 202:from 202.63.111.150/24 lookup 202
> 222:from all lookup 222
> 32766: from all lookup main
> 32767: from all lookup 253
>
> and iam not able to Ping or go out from My gateway IP
> i can only Ping my Gateway IP's
Check the settings again.
> thanks
> hare
Regards
--
Julian Anastasov <[EMAIL PROTECTED]>
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Problem With Load Balancing the Links
Hello, On Mon, 23 Dec 2002, hare ram wrote: > iam using redhat 8.0 with Latest Kernel > 2.4.18-18.0 > with iproute > [root@pdn root]# rpm -q iproute > iproute-2.4.7-5 I'm not sure if 2.4.7-5 covers the desired version but here it is: ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss020116-try.tar.gz > is this Corect or i need to still upgrade > if so, i did not find latest than this You can always list the above directory for latest tarballs > thanks > hare Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Problem With Load Balancing the Links
Hello, On Sun, 22 Dec 2002, hare ram wrote: > iam following the Julian Nano.txt, iam able to setup all > but when i check the following command > > [root@pdn root]# ip route list table 222 > default proto static > nexthop via 202.x.x.254 dev eth0 weight 256 dead onlink pervasive > nexthop via 203.x.x.17 dev eth1 weight 1 This smells like one iproute utility bug, just upgrade to iproute2 from Year 2002 which fixes similar problem. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Filter MAC address
Hello, On Sun, 22 Dec 2002, Nickola Kolev wrote: > > I need to classified the traffic by looking at the packet destination > > and source MAC address. Can anyone here suggest ways to do this. > > > > I have read through the HOWTO documentation, from there I know that > > U32 filter can only filter out IP or higher layer. May I know why U32 > > filter did not support datalink layer (MAC address)? Is it that when This is a lie. > > packet entering TC, the datalink layer no longer there? Are there any > > filter which can filter the MAC address? You can filter with U32 by src/dst MAC on ingress and by dst MAC on egress. On egress the src MAC is replaced with new one and there is no good reason to apply U32 filters for sender's MAC. > > Before this, I have successfully implement QoS through source and > > destination IP address using CBQ. Here I would like to thanks LARTC > > for the help. > > > > Yes, you can do this, but using fw marking, not u32 classifier. Just Why not, just use negative offsets with U32 to access the 14-byte eth frame header before the IP header: Decimal Ofs Description --- -14:DST MAC, 6 bytes -8: SRC MAC, 6 bytes -2: Eth PROTO, 2 bytes, eg. ETH_P_IP 0: Protocol header (IP Header) > search through the various > netfilter extensions - you really can do miracles with them :)) > > E-gards, > Nickola Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] routing problem AAAAAHH!!
Hello, On Tue, 10 Dec 2002, Luis Miguel Cruz Miranda wrote: > My main table is: > # ip ro ls > 194.149.216.0/24 dev vlan2 scope link > 10.1.0.0/24 dev eth0 scope link > 127.0.0.0/8 dev lo scope link > default via 10.1.0.254 dev eth0 > > I have also these routes and rules: > # ip ru ls > 0: from all lookup local > 32757: from all to 10.2.0.1 lookup 101 > 32758: from all to 194.149.216.3 lookup 21 > 32759: from all to 194.149.216.2 lookup 21 > 32760: from all to 194.149.216.1 lookup 21 > 32761: from all to 10.10.10.0/24 lookup main prohibit > 32762: from 10.2.0.1 lookup 100 > 32763: from 194.149.216.3 lookup 20 > 32764: from 194.149.216.2 lookup 20 > 32765: from 194.149.216.1 lookup 20 > 32766: from all lookup main > 32767: from all lookup 253 > > #ip ro ls table 20 && ip ro ls table 21 > default via 10.1.0.254 dev eth0 > 194.149.216.2 dev vlan2 scope link > 194.149.216.3 dev vlan2 scope link > 194.149.216.1 dev vlan2 scope link > > Why 194.149.216.5 is reachable from internet? Yes, it is reachable: from 1.2.3.4 to 194.149.216.6 hits rule 32766, table main: 194.149.216.0/24 dev vlan2 scope link > Luis Miguel Cruz Miranda. > CCNA - Systems Administrator Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Weird problems with source-based routing, proxy_arp andthe mediu m_id feature
Hello, On Fri, 29 Nov 2002, Janssen Alexander wrote: > ip route add 10.1.56.222 dev eth1 # Router1 > ip route add 10.1.56.193 dev eth0 # Workstation1 > # every Workstation has it's own table > ip rule add from 10.1.56.193 table 193 > ip route add default via 10.1.56.222 dev eth1 table 193 > > In my understanding the firewall should not answer to > arp-whois requests for IP 10.1.56.193 on interface eth0. > Or did i get it wrong? Yes May be only one missing line to be happy with medium_id: ip rule add prio 100 table main Explanation: I see only the table for .193 but I assume there are other similar tables, you have asymmetric routing configured when it should not be in this way. What happens: A and B are on same LAN, Host A resolves B: who-has B tell A firewall: Q: I see probe "who-has B tell A" on dev X. Where points the route from A to B? A: There is route "from A to 0/0 => Forward via DEV Y". Well, X != Y, they have different medium_id values => answer this ARP probe on DEV X. The problem is that you have routes in this order (ip rule show): from A to 0/0 => DEV Y (table A) from 0/0 to B => DEV X (table main) You need to inspect the main table first. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] transparent PAT
Hello, On Wed, 27 Nov 2002, Nickola Kolev wrote: > So, given I'm running kernel 2.4.19 and using ipchains (don't > ask me why, but I'm bounded to this config), I would like to > reroute everything that's passing thru eth1 on machine A > from the internal lan and has dport to the same port > on machine B. The hole thing has to be completely transparent. > I tried some "advanced routing" stuff, like marking those packets > with fwmark and building a separate routing table for them, > but alas. Notice that the two machines are on the same LAN segment. Yes, marking the packets for routing purposes is a solution, sort of: # Mark XXX traffic ipchains -A input -p TCP -s CLIENT_NET/24 -d 0.0.0.0/0 PORT_XXX -m 1 -j ACCEPT # Check first for routes to directly attached networks ip rule add prio 50 table main # Port XXX to universe is rerouted to host B ip rule add prio 100 fwmark 1 table 100 ip route add default via HOST_B dev eth1 table 100 May be the problem is that host B can not accept this traffic? You need some measures: 1. In host A stop ICMP redirects generated for routes on shared meduims: echo 0 > /proc/sys/net/ipv4/conf/*/send_redirects Without such settings, host A will redirect clients directly to host B, for any traffic 2. Add Transparent Proxy support in box B to accept locally the client's traffic. You can look how the Squid tproxy works: each packet is delivered to the configured local IP:PORT but this service can obtain the original DADDR:DPORT of the packet. > Nickola Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multipath Routing Question with Public networks
Hello, On 18 Nov 2002, Vincent Jaussaud wrote: > Right. And disabling rp_filter might open a security hole; so I'll For internal interfaces rp_filter is optional. > ensure traffic always go through the right interface. > > - TCP connect() for unbound socket uses saddr=0.0.0.0 daddr=REMOTE_IP. > > The routing then returns the best source IP to use for this connection > > after creating a connected route in the routing cache. > What do you mean by "unbound socket" ? socket(), connect(), i.e. when there is no bind() to local addr. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multipath Routing Question with Public networks
Hello, On Sun, 17 Nov 2002, Vincent Jaussaud Mailing Listes wrote: > On top of this, defaults gateways for internal servers are unlikely to become > unreachable, since they are on the firewall itself. > Gateways which are likely to colapse, are the ones used by the firewall, eg > ISP1 & ISP2 routers, and this will never be noticed by the internal servers > since they are not directly connected to them. Am I wrong ? Yes, this is a problem, job for user space tools to change the routing settings on failure. > > The server uses the 10.0.0.1 as source when resolving > > route for the reply. Then it depends on the routing rules. > That's good news. So it means that if my routing rules are setup correctly, it > will work. I was afraid of having some packets sent back using a wrong SRC IP :) > > I assume however that this will work only for usual protocol such as http, > smtp, ssh... I'll have to find a workaround for protocols like FTP, if any. > Any idea ? Should not happen for TCP servers but sometimes the UDP servers are not smart enough when used on multihomed servers. See below. > But, just beeing curious, why would rp_filter drop such packets ? Firewall with rp_filter set on internal interfaces expects the traffic to come from the right internal interface (I assume you have the two pubnets configured on different internal interfaces). There is no such problem if the internal interfaces do not use rp_filter. > I mean, we don't really care what link is beeing used for a reply, as soon as > the SRC IP & DST IP are correct. It's likely that ISP1 & ISP2 router won't do > source address validation anyway. Am I wrong ? If the ISPs allow spoofing then while the links are alive there is no problem, it comes when some ISP fails. We should stop using its addresses in this case. > > The transport and the application decide what source IP > > to put in the reply. Then they decide how to call the routing. > > The right thing to do when addresses to both ends are known is > > to feed the routing with saddr and daddr. If callers use 0.0.0.0 > > as saddr when resolving routes, they will hit the multipath > > route which is bad. > > > I'm not sure to understand this point, especially "to feed the routing with > saddr and daddr." > I know we can instruct the routing to use a specific saddr, but what about daddr ? daddr is always used. Some examples (of course, there are other route keys used, not shown here): - TCP connect() for unbound socket uses saddr=0.0.0.0 daddr=REMOTE_IP. The routing then returns the best source IP to use for this connection after creating a connected route in the routing cache. - TCP connect() after bind() uses saddr=LOCAL_IP daddr=REMOTE_IP - TCP listener uses saddr=LOCAL_IP daddr=REMOTE_IP when replying to SYN - UDP can also avoid using 0.0.0.0 as saddr if the socket is bound or when IP_PKTINFO contains local IP information. If the app does not take steps to inform the kernel that this socket is bound to some local IP when sending the packet then 0.0.0.0 is used as src IP for the route lookup (ignoring the fact that this UDP packet has known saddr in iphdr). So, it depends both on transport and on app to feed the routing with the right keys. > Vincent. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multipath Routing Question with Public networks
Hello,
On Sat, 16 Nov 2002, Vincent Jaussaud wrote:
> On All servers, we setup multipath default route, so that they can use both link as
>well.
That means they know which link is alive or it does not
matter? :)
> Let's say we have Server A in our internal public network, with 2 network adapters,
>one
> using 10.0.0.1 (routed through ISP1), other using 172.16.0.1 (routed through ISP2)
>
> Assuming that rp_filter is configured correctly on our firewall, what happens when a
> client want to reach Server A using 10.0.0.1 ? What path will be used for the
>replies,
> with what source IP ?
The server uses the 10.0.0.1 as source when resolving
route for the reply. Then it depends on the routing rules.
> I assume that if rp_filter is configured correctly, return path do not matter (since
>we
> don't do NAT), but I'm worried about the SRC IP beeing choosed for the reply.
>Because, if
> the kernel choose the src IP according to the output default route beeing choosed,
>then
> half clients<->servers sessions will just break.
I'm sure you need correct routes on firewall and all internal
hosts, for example:
ip rule add prio ... from pubnet_X to 0/0 table table_for_ISP_X
ip rule add prio ... from pubnet_Y to 0/0 table table_for_ISP_Y
ip rule add prio ... from 0/0 to 0/0 table your_multipath_route
Of course, the internal hosts use the proper firewall
IP as gateway.
That is all, traffic from specific pub IP should use only
its gateway. You can expect rp_filter drops in firewall if
the internal servers select wrong NIC by using multipath
route for all route resolutions. The multipath route should be
used only for source address autoselection:
- originating connections without bind()
- selecting masquerade address (for NAT)
- etc
I.e. it is a bad idea to use only multipath route.
Internal servers creating outgoing connections after
using bind() to specific pubip should not reach the multipath route.
> So, basically my question is, what rules decide of the SRC IP to be used in a reply
> packet on a system with several default route through different network interfaces ?
The transport and the application decide what source IP
to put in the reply. Then they decide how to call the routing.
The right thing to do when addresses to both ends are known is
to feed the routing with saddr and daddr. If callers use 0.0.0.0
as saddr when resolving routes, they will hit the multipath
route which is bad.
> Has anyone already experiencing such setup ?
Not exactly, but everything is in the details :)
> Vincent.
Regards
--
Julian Anastasov <[EMAIL PROTECTED]>
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
Hello, On 29 Oct 2002, Vincent Jaussaud wrote: > I was thinking about using the metric value for this. > > Let's say: > > ip route add table dual-gw proto static 192.168.0.0/24 via GW1 dev eth1 > metric 1 > ip route add table dual-gw proto static 192.168.0.0/24 via GW2 dev eth1 > metric 2 No, the metrics work only if the routes disappear. This usually happens when device goes down (for example, ppp). For gateways reachable via ARP it can't work. You need to define alternative routes (ip route append), see my docs about alt routes that use same metric. > I assume the kernel will always use the best route, that is the one with > best metric. So that all packets will use the same route. > If GW1 breaks, patched kernel should mark first route as dead, and force > all further packets to use GW2 instead. No, dead gateway detection currently works for routes with same metric. But even then the detection is passive and needs help from user space. Without such checks you can expect almost random results. OTOH, you can run your own checks and to keep only the alive routes. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] the routing cache and route selection; is this correct?
Hello, On Mon, 28 Oct 2002, Martin A. Brown wrote: > - If there is no routing cache entry, we continue with route selection > by consulting the RPDB and routing tables. > > 1 start traversing the RPDB at the highest priority > 2 keep traversing the RPDB for the next matching entry Lookup the list with ip rules and match by using the following keys: - dest - src - tos (optional) - fwmark (optional) - iif (optional) > 3 when a match is found, try to find a match for the destination > in the designated table In the designated table lookup for routes by using the following keys: - dest - tos - scope - oif (optional) > So, my question: > > Is the routing cache actually keyed on the above items? If I understand > Arthur's post of last Friday properly Yes, you listed the cache keys correctly. > (http://mailman.ds9a.nl/pipermail/lartc/2002q4/005641.html), he's > suggesting that the keys in the routing cache are src, dest, and tos. > My empirical evidence: I know I'm using fwmark routing on a particular > host, and packets are transmitted out the "correct" interfaces when I > generate traffic for all of the fwmark'd routes. What confuses me is the > output of "ip route show cache ip.ad.dr.es". There is no reference > whatsoever to fwmark in this output. May be for compatibility reasons the fwmark is not listed in the route cache entries. > Can somebody confirm (as the evidence suggests) that the routing cache is > keyed on the above five elements? Yes, this is my understanding reading the sources > -Martin Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
Hello, On 28 Oct 2002, Vincent Jaussaud wrote: > My question is, if we ensure that EVERY packets, whatever path they use > to arrive, finally pass through a single peer doing NAT, is this suppose > to work around my TOS problem ? Sounds correct. The requirement is each packet from one connection to be NAT-ed only from one NAT router and to same masquerade address and port. The routing cache can not guarantee that. It can be done only from the patched masquerade. > What about the rp_filter kernel value ? Could it be a problem in such > setup ? The patches are designed to work with rp_filter enabled. You can safely use it, it is changed to work only with the defined paths. > Thanks again. > Vincent. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
Hello, On 25 Oct 2002, Vincent Jaussaud wrote: > > 2.4 mask 0x1C, inverted 0xE3 > > 2.2 mask 0x1E, inverted 0xE1 > > > > So, for 2.2 may be: > > > > ipchains -I input -d 0.0.0.0/0 22 -t 0xE3 0x00 > Just tried. Now SSH connections don't break anymore !!! :) Thanks ! > Am I suppose to do this on both side, or doing this on the firewall > itself is enough ? I now see that my example ipchains command is wrong, use 0xE1 for 2.2 as the above table. > The only problem with this, is that I will need to do this trick for any > applications changing it's TOS during the session. It seems that FTP > behaves exactly the same way as SSH, regarding the TOS field. It seems you can safely alter the TOS for all packets entering your box/site. > Do you guys know if many applications do this ? Or is this just > particular to SSH & FTP ? The TOS is usually used for routing between routers in your site, then the border gateways can assign different priorities based on the TOS values, for traffic control purposes. > Anyway, I really would like to understand why it doesn't work when doing > NAT. May be you can hunt it with tcpdump. I assume your are using the patches because the plain kernel has the same problem for NAT. > A big thanks to both of you. I've learned a lot today :) > > Thanks again. > Regards, > Vincent. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
Hello, On Fri, 25 Oct 2002, Arthur van Leeuwen wrote: > > Now I see, then the TOS is a big problem for you. May > > be your problem will be solved if TOS is not a routing key but > > it does not sound as a thing that is easy to fix in kernel. > > Actually, you can simply play whack-a-mole with the TOS value, using > ipchains (or iptables), killing all TOS values present on the packets. > Ofcourse, this is not very *nice*, but it'll work. This is a good idea. Vincent, may be you can play with ipchains -t AND XOR in the input chain to see what happens. Just make sure you don't touch bits 0, 1, 5, 6, 7. It seems the routing uses only bits 2, 3 and 4 for routing key (if I'm not overlooking something). This is for kernel 2.4. For kernel 2.2 it seems bit 1 is also included in the routing key. 2.4 mask 0x1C, inverted 0xE3 2.2 mask 0x1E, inverted 0xE1 So, for 2.2 may be: ipchains -I input -d 0.0.0.0/0 22 -t 0xE3 0x00 What are the TOS values used during the SSH session? Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
Hello, On 25 Oct 2002, Vincent Jaussaud wrote: > But traffic is NAT-ed after multipath routing occurs ! > Eg, the box which do multipath routing do not NAT traffic; traffic get > NAT-ed when leaving the gateways: > > LAN --> FW w/ multipath-routing > || > Gateway1 Gateway2 > | (NAT) | (NAT) > || > Remote Network > > Packets reach the Remote Network using one of the Gateway NAT-ed IP, so > that when packets come back they should use the proper return path. Am I > wrong ? Now I see, then the TOS is a big problem for you. May be your problem will be solved if TOS is not a routing key but it does not sound as a thing that is easy to fix in kernel. > Hmmm... Then this is where the problem is. So, if I understand > correctly, packets coming from a single TCP connections will use any of > the multipath route _if_ they are not NAT-ed ? Isn't the routing cache Yes, traffic A->B with TOS=XXX will use one path, traffic A->B with TOS=YYY can use different path. > suppose to ensure that every packets coming from a single connection use > the same path ? The routing does not cache connections but route resolutions keyed by saddr, daddr, tos, etc. Even there are no TCP/UDP ports (yet?). > Now, If I understand the whole topic, in order to fix my problem, I need > to: > > - NAT everything on the FW itself This is a solution > - or disable NAT on both gateways, and ensure that routing is done > properly Not sure what you mean. But you can run multipath routes on the both gateways. Then the internal hosts can select any of the gateways as default (or to use alternative default gateways). Another solution is your apps not to change the TOS, it can be changed at the border gateways (if useful at all). > Am I right ? I'm becomming a bit lost, here :-\ > > Many Thanks for your time. > Vincent. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: Re: [LARTC] multipath routing problem [Shorter version] - Helpstill needed :-)
Hello, On 25 Oct 2002, Vincent Jaussaud wrote: > > ssh tends to play with TOS fields (and rightly so). Routing is keyed to the > > *triple* (src, dst, tos), something that most people (including me) normally > > forget. However, in this particular case that may be the reason for your > > ssh's breaking. > > > Hmm... that's really interesting. Thanks for the pointer. I remember now > that I've read something regarding SSH & TOS field some days ago. If I'm > right, it use the Minimum Delay TOS value. > > Now, how am I suppose to deal with this TOS issue ? What TOS value > should do the trick ? In theory, you should not reach multipath route for traffic that is already NAT-ed. May be you have to fix your routes. The TOS field plays in the input routing performed on forwarding and traffic between two public IP addresses can select different nexthop if the TOS is different or if the routing cache is somehow flushed (on route/address add/del, expiration). > I'm using a 2.2 kernel with ipchains. > > > The reason for FTP breaking possibly has to do with packets for > > the control connection going out the one gateway and for the data going > > out the other... but this is speculation on my part. > > That sounds wise. However, routes are suppose to be cached using the src > IP field as well (If I'm not mistaken), so that every packets coming > from a particular IP are likely to take the same route than the others. > Am I wrong ? Yes, TOS is a routing key just like SADDR and DADDR. By using multipath route between 2 IP addresses you agree that the packets can _safely_ choose any of the paths. When using two or more ISPs you simply can't do this if the ISPs have source spoofing disabled. In such cases only the traffic that is NAT-ed from your box has the right to use the multipath route. This is a key requirement for the patches you are using. Once the NAT connections are established they don't hit multipath route. > A BIG Thanks for your reply :-) > Cheers, > Vincent. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: Re: Re: Re: [LARTC] help, a children can not borrow from aparent?
Hello, On Wed, 23 Oct 2002 [EMAIL PROTECTED] wrote: Ops, is that correct?: > ipchains -A fw -s 0.0.0.0 -d 0.0.0.0 -j ACCEPT it should be ipchains -A fw -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: Re: Re: Re: [LARTC] help, a children can not borrow from aparent?
Hello, On Wed, 23 Oct 2002 [EMAIL PROTECTED] wrote: > >The ceil parameter always worked for me. What version of tc/htb/kernel > are > >you using? > > TC from htb3.6-020525.zip > kernel 2.2.21 and patch ds9-2.2.21-2.diff rbtree-2.2.21-1.diff > ds9-htb3-2.2.21-1.diff > from http://www.ssi.bg/~ja/ds9/ I just upgraded to HTB 3.7 from 2.4.20pre11: ds9-htb3-2.2.21-2.diff I can't comment the HTB behavior, my tests with HTB were very simple. In production I'm using this backport only for CBQ, U32, SFQ, Ingress, policers. I have never observed deviations from the 2.4 behavior. It would be good if you can compare the same settings on 2.4.20pre. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: 答复: Re: 答复: [LARTC] Announce: BackportQoS from 2.4 to 2.2
Hello, On Tue, 15 Oct 2002 [EMAIL PROTECTED] wrote: > OUTPUT : " HTB: need tc/htb version 3 (minor is 6). you have 10. My mistake, what about trying the 3.6 code: http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: 答复: [LARTC] Announce: Backport QoS from 2.4to 2.2
Hello, On Tue, 15 Oct 2002 [EMAIL PROTECTED] wrote: > HTB3 backport from 2.4 to 2.2 > we have to use new tc tool for htb3 of 2.2 You can use any tool with HTB support (2.2 or 2.4). You can build it yourself or to use the supplied binary: http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_tc.diff http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz Everything is on the HTB site: http://luxik.cdi.cz/~devik/qos/htb/ just look for "diff against iproute2 rel 991023 and tc binary" > Where can i get the new iproute2 for 2.2 ? There is no new iproute2 for 2.2, use one of the above two methods. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] owner based policy routing
Hello, On Mon, 14 Oct 2002, Arindam Haldar wrote: > ok, i have tried applying the ip rule fwmark in hex but dont see any > difference !.. It is already in hex, use something like: ip rule ... fwmark 50 iptables ... --set-mark 0x50 > The routing decission is take be4 the packets comes to OUTPUT table, if Right > thats true then it will be not possible to route **owner** as per policy > routing--am i right ?? The sockets select route and when localout selects different ISP may be the source should be changed too. > if ys then how can one achieve **owner** based policy routing in linux > box ?? This is something that others should comment. NF is supposed to do everything :) Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] owner based policy routing
Hello, On Fri, 11 Oct 2002, Arindam Haldar wrote: > 50: from all fwmark 50 lookup ispA fwmark in ip rule is 0x50 (it is defined and printed in hex) > iptables -I OUTPUT -t mangle -m owner --uid-owner -d 202.0.0.0/8 > -j MARK --set-mark 50 and here 50 is 0x32 (not 0x50). Is that the problem? Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ip rule and traceroute
Hello, On Thu, 3 Oct 2002, Jacob Teplitsky wrote: > I'm trying to force traceroute to use non default (not main) routing table, but it >doesn't work. > Anyclues are appriciated. > # traceroute -s 10.10.10.13 192.168.2.1 > traceroute to 192.168.2.1 (192.168.2.1) from 10.10.10.13, 30 hops max, 40 byte >packets > 1 sendto: Network is unreachable > traceroute: wrote 192.168.2.1 40 chars, ret=-1 I noticed this problem some time ago: http://marc.theaimsgroup.com/?l=netfilter&m=101087206922268&w=2 But I don't know if recent traceroute versions have this problem fixed. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] two internet connections + filter?
Hello, On 30 Sep 2002, William L. Thomson Jr. wrote: > I will go in order and below are the values I last tested, and the > default values. > # Default Values > #echo 256 > /proc/sys/net/ipv4/route/gc_elasticity # 8 gc_elasticity can be 1..16, gc_elasticity*gc_thresh is the desired number of entries we can live with, after that point we start to worry about filling the cache. > #echo 1 > /proc/sys/net/ipv4/route/gc_interval # 60 > #echo 0 > /proc/sys/net/ipv4/route/gc_timeout # 300 On each interval (gc_interval) up to gc_interval/gc_timeout entries are checked for expiration. With the default parameters, 1/5 of the table on each 60sec, each cache entry lives up to 300sec by default. > #echo 0 > /proc/sys/net/ipv4/route/gc_min_interval # 5 gc_min_interval 0 means no restrictions for running GC, may be it is good on load. > #echo 128 > /proc/sys/net/ipv4/route/gc_thresh # 256 > #echo 1 > /proc/sys/net/ipv4/route/max_delay# 10 > #echo 1 > /proc/sys/net/ipv4/route/min_delay# 2 > #echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter# 1 > #echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter# 1 > The gc_timeout seems to be a timeout between gc's? this is gc_interval Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Iptables, SNAT/MASQ, Multiple gateways
Hello, On Mon, 30 Sep 2002, Michael T. Babcock wrote: > Don Cohen wrote: > > >I actually sent a proposal to this list that I think provides a good > >solution to the general problem: an extension to TCP (possibly even > >IP) that supports multiple addresses/ports. This would even allow you > >to switch addresses in the middle of a connection. I think what I Yes, we can implement it as separate IP protocol :) Of course, at the beginning the idea may sound too stupid, we have to change that. May be there is already solution for that? A "simple" tunnel without encryption that will support failover and balancing of the negotiated traffic, ability to negotiate multiple IPs for each endpoint. Of course, there should be some problems with the proper tunneling of this traffic in each end, see how difficult is routed the IPSec traffic. Each endpoint will do failover detection of all negotiated links and will do balancing (if desired) over these links, based on relative ratio. This tunnel should be transparent to the upper layers (TCP/UDP/ICMP/SCTP). > SCTP actually supports this already; look it up -- its quite a bit > different from TCP but allows you to do all the same types of things, > with more options. But this feature is only for SCTP. We want the traffic from one multihomed router to use multiple links when talking to another router, both understanding this "our new" IP tunneling protocol. I see it in this way: when such packet is received, we decapsulate it and place it on the expected interface. As result, the upper layers will see the packet on the right input interface even if it is received on another input interface (for example, if it is the only alive). Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ipmode compile error
Hello, On Fri, 27 Sep 2002, [gb2312] hanhbnetfilter wrote: > imq and htb are used to control traffic. > When I create a bridge with the bridge-utils, I get a > new device : br0. I can shape traffic on this > device, but I can not use iptables to mark packets. > I used ipmode > http://www.linuxvirtualserver.org/~julian/#bridging > my kernel is 2.4.19 > when i compile kernel I get the following error: > br_forward.o error 1 > first_rule error 2 What errors? Do you have plain kernel patched with the ipmode kernel patch? > if I used ipmode, then I can set imq as this: > /usr/local/sbin/iptables -t mangle -A PREROUTING -i > br0 -j IMQ --todev 0 > is this right ? Bridge in IP MODE enabled receives IP traffic on the slave eth* ports, not on the br0 interface. Only ARP can be received on br0 if you are using routes through br0. The goal is to receive IP on the slave ports, though. The asymmetry in the route settings is not a problem if you handle it correctly as mentioned in the docs, then you can use routes on slave or on bridge interface according to your needs. Else, there is no reason to use ipmode, you can play with br0 if ipmode is off. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Problems compiling patched bridge-utils
Hello, On 17 Sep 2002, Esteban Maringolo wrote: > I've applied ``bridge-utils-0.9.5-ipmode-1.diff'' to be able to use my > shaper as bridge and don't lose the netfilter capabilities, the patch > applies with no error messages, which makes me supose everything is > working fine. > > But when i try to recompile the bridge-utils utilities i get the > message transcript below: > > esteban@inercia:~/devel/nexusbm/bridge-utils-0.9.5$ make > make -C libbridge > make[1]: Entering directory > `/home/esteban/devel/bridge-shaper/bridge-utils-0.9.5/libbridge' > gcc -Wall -g -c libbridge_devif.c > libbridge_devif.c: In function `br_set_bridge_ip_mode': > libbridge_devif.c:151: `BRCTL_SET_BRIDGE_IP_MODE' undeclared (first use > in this function) May be you need 2.4.19 kernel in /usr/src/linux patched with bridge-ipmode-2.4.19-2.diff, the user-space stuff is not enough. > Any Clue? Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] 4 nic advanced routing question
Hello, On Tue, 10 Sep 2002, Thad Marsh wrote: > Can some one point me to a reference for how to route two wan nics and > two internal nics on the same box. Here you can find some documents and patches on this issue: http://www.ssi.bg/~ja/#routes Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Problem with nexthop and gets dead
Hello, On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote: > default proto static > nexthop via 80.25.175.1 dev eth0 weight 1 dead > nexthop via 212.170.14.1 dev eth1 weight 1 > Have any idea? Why said dead if the ip's responds to the ping You have to upgrade to iproute2 package released this year. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] uplink with multiple lines
Hello, On Tue, 20 Aug 2002, Calvin Dodge wrote: > Two of the modems _do_ have private IP addresses (192.168.x.1) - could > that be confusing the kernel? If so, do I need to get public IP > addresses for those modems? AFAIK, there is not flag "public" for the IP addresses in Linux, at least, not in IPv4. The kernel does not know anything about private/reserved IP ranges. > Do I HAVE to create a patched kernel (ala Anastasov)? May be not. But you can try to understand the settings provided in the docs. The essential thing to understand is how the ip rules and routes are ordered, how the NAT uses the routing, why the NAT in plain kernels sometimes breaks with multipath routes, what kind of nexthops the kernel can live with, can you live without dead gateway detection, if not, how it works (in kernel? help from user space?), etc. > May I post the script I used to try this out? Or if possible to provide reference to it after the 5th reading of all docs :) > Thanks, folks! > > Calvin Dodge > Certified Linux Bigot (tm) > http://www.caldodge.fpcc.net Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multi Routing Problem.
Hello, On Mon, 19 Aug 2002, Arindam Haldar wrote: > & applied julian's patch to kernel 2.4.19 & have gone thru the docs at > the site... i have defined basically 3 groups for clients--> cache, > cisco, balance.. the name specifies the importance.. this is the details > of what i did--> Carefully analyze the docs... > [root@Lr1 root]# ip rule ls > 0: from all lookup local # direct communications are first priority ip rule add prio 5 table main > 10: from EXTnA.124/25 lookup ONE > 20: from EXTnB.106/26 lookup TWO > 100:from 192.168.1.10 lookup CACHE > 101:from 192.168.1.20 lookup CISCO > 150:from 192.168.1.30 lookup BALANCE > 200:from all lookup ME > 32766: from all lookup main > 32767: from all lookup 253 > BUT am **NOT** able to surf at all from internal network... not even > able to ping eth2 !!!.. default INPUT & OUTPUT are set to ACCEPT while > FORWARD is DROP.. First try with all ACCEPT. > whats missing there ?.. after trying all day i want guidance now... > awaiting a reply very anxiously Your setup is a bit strange: internal hosts use some gateways, the external addresses use different gateways. The problem is that if you are using NAT and for example 192.168.1.10 is SNAT-ed the packet will leave with new saddr (the masquerade address). Looking in your rules there is different gateway for the masquerade address. This can't work. The current framework requires that: - if one internal IP is masqueraded to a specific address, you need the 2 routes to be similar, i.e.: from INT_IP to TARGET and from MASQ_IP to TARGET to use same gateway and device. This is even mandatory for the patches. Currently, the first packet for one connection is routed via the route "from INT_IP to TARGET", the SNAT rules assign masquerade address at postrouting and then all next packets are routed via the 2nd route - 1 route per forwarded packet. It is a bit strange these two routes to use different gateways. Do you have a good reason for this? Also note that rules in the form "from 0/0 to ANY_TARGET" where ANY_TARGET can be any subnet including 0/0 are used for source address autoselection - the resulting preferred source IP is used as saddr. It is not used only as "default" rule. So, playing tricks with different gateways is not possible. The setup is ambiguous if NAT is involved. > A.H Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Announce: Backport QoS from 2.4 to 2.2
Hello, I'm happy to announce a QoS Backport from 2.4 to 2.2. This is unofficial DiffServ v9 release (a.k.a DS-9). This beta release includes some bugfixes after the last 2.2 release, known as DS-8, many files copied from 2.4.19, some definitions and functions useful for keeping the interface for schedulers and classifiers similar to the 2.4 one. I'm planning to apply all 2.4/2.5 QoS fixes to this DS-9 tree, so the result should be fully functional net schedulers for 2.2. As there are still some 2.2 specific parts, any kind of reports are useful (even the good ones :)). Any bugfixes and comments can be posted directly to me or to the LARTC and/or DiffServ mailing lists. Have fun! DS-9 - QoS Backport from 2.4.19 to 2.2.21: http://www.ssi.bg/~ja/ds9/ Changes between DS-8 and DS-9: http://www.ssi.bg/~ja/ds9/Changelog.ds9 Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB3 port for 2.2.18?
Hello, On Fri, 16 Aug 2002, Amit Kucheria wrote: > Is there an HTB3 port for 2.2.18? Yes, I have backported the net/sched from 2.4.20pre1 to 2.2.21, including HTB3. The simple tests look good, the problem is that I still have problems updating/accessing my site. I can provide my "DS-9" tree to anyone interested in testing and hosting the files. > Regards, > Amit Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Advance Routing Guidance
Hello, On Thu, 15 Aug 2002, Arindam Haldar wrote: > after going thru the docs i find that with julians patch one needs to > **MASQUERADE** to the links... we dont want that !.. we want our real ip > to flow in these 2 links(real ip already being broadcasted on provider's > network).. > so my Question is-->possible without **MASQUERADE** ??.. will the > setup(as shown in docs) loadbalance for our real ip's ?? .. Of course, it is possible ... and depends on how restrictive are your providers. But if one link fails you can have the problem of using sources for the failed link, then the replies from world will hit the failed provider and will not reach you. As result, your internal servers should know which source addresses to use according to the link state. The masquerade simply guarantees that one link is used only from addresses that are reachable from this link. > what other things i have to consider ?.. As for applying the patches you need to download them correctly. More likely you have white space problem (try with patch -l). > Awaiting a reply very very anxiously.. > A.H Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: Dead gateway detection
Hello, On Fri, 9 Aug 2002, Laurens van Alphen wrote: > Q1: In the Nano-HOWTO on your site, it says to include these statements: > "ip route append prohibit default table metric 1 proto > static" > Why? What does it do? If I use these I can't connect to the Internet, > without them I can. The reason can be that you have other rule/route settings. The purpose is: traffic using source addresses from failed links should not try to use another alive link (some ISPs do not allow spoofing from our side). Such prohibit rules avoid using less-specific routes from other tables if the previous route is deleted (metric 0). > Q2: I have the following multipath route to the Internet: > "default proto static > nexthop via GW1 dev eth1 weight 1 > nexthop via GW2 dev eth2 weight 1" > If I unplug eth2 the second route is never marked as 'dead', why? > Only if I 'ifconfig eth2 down' the second route is marked dead. I > thought the patches would detect this? Linux detects failed gateways and does not use them but the nexthops remain alive. Dead are only the routes administratively marked as such. This is the current way. > Thanks, > > -- > Laurens van Alphen > Keen on dots Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multipath route problem
Hello, On 31 Jul 2002, William L. Thomson Jr. wrote: > two things. The first is patches made by Julian Anastasov, > I had a link but it does not seem to work. Julian subscribes to this > list so maybe he will post an updated link to where they can be found. The box that hosts the patches is down. I can't provide another link, I don't know whether it is mirrored with wget somewhere by someone. When the site is ok I'll upload the files. Until then, I still can use email, just let me know what files you like to see. I simply didn't started to think for another place for this page, I hope the issue will be resolved in days. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] failover problems
Hello, On Wed, 24 Jul 2002, Tobias Geiger wrote: > Yes. i used 2.4.19pre-10 kernel. > This behaviour affects only ppp-devices (never tried ippp but i guess it's > the same) > > i also wondered, why failover doesn't work when using different > route-entries for each nexthop... Hm, the kernel can not perform failover for NOARP devices that are always in UP state. It is possible only for ARP devices and for default routes with same metric. But if the first route is automatically deleted from kernel the 2nd one will be used. No? > another confusing thing: using "nexthop via dev ppp0" in a table made me > think that i don't need a gateway address at all... but unfortunatly > that's no the case :(seems that ip searches the gateway address itself so > that after appp-reconnect (where i get another gateway address) the table-entries > aren't valid anymore. The "via GW" syntax is not mandatory for ppp devices, you can use only "nexthop dev ppp0", just remove this "via", you have syntax error. As for ppp devices, it is recommended your scripts to recreate the multipath routes to contain nexthops only for valid ppp devices (for which you have established link). As you see, the new kernels delete the multipath route for you, so you can't rely on permanent multipath route (I assume the ppp devices really pass unregistration). Even in the old kernels you have to recreate the route because when one ppp devices is registered again its nexthop status does not change, it remains dead. > Thanks > > Tobias Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] failover problems
Hello, On Tue, 23 Jul 2002, Tobias Geiger wrote: > to be precisly: the problem is i have several nexthops (e.g. ppp0 +eth1 > +eth2) for the same route and this WHOLE Route is deleted, although only > the ppp0-device dissapears... > and i cannot add several entries in different tables, cause this seems not > to do failover Yes, similar behavior appeared in latest 2.4.19pre kernels, it looks like a recommendation the users to recreate their routes because a device in nexthop was unregistsred. Is this true for your setup? Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 withds8 patch
Hello, On Fri, 12 Jul 2002, jamal wrote: > If you look at the old postings on the diffserv mailing list youll see > about 70% of the questions were related to "my patch failed" etc (people > patching in the wrong directory etc). Believe it or not a _lot_ of Linux > users still hate patching (I have matured to accept it) or are not > very skilled or bothered to learn; they just install connectiva 8 and are > off to cook: i.e they just want things to work. > Now unlike MS, we have the code! infact Werner has clearly documented what > the changes from 2.2->2.4 are in his doc. I know the only time i have > lately is for breathing (hopefully fresh air at work) and this backporting > requires abuse of the brain cells more than thinking i.e its mechanical > and therefore requires concentration/focus; > > so if someone could submit a backport patch i think we would > put it up the website. I believe we could even push it into the 2.2 next > release since this stuff is pretty much stable right now. At least, we need valid patch with the most needed fixes. I think, I can walk the both trees and to fix the obvious bugs that are fixed in 2.4. At first look, the changes are not too much, so we will be back soon with the most needed fixes. I can report that the small part of the code I'm using looks stable enough. > > > BTW, what is the motivatein behind: > > > http://www.linuxvirtualserver.org/~julian/01_ingress-breaks-fw-1.diff > > > > At least, FW_REDIRECT, not sure for any others > > > > I am trying to think of some way to probably do this from ingress instead > since some people actually want that overwrite. ok :) But then you have to add ipchains support for tc in addition to the iptables' one. My wish was to have only the needed bugfixes :) > cheers, > jamal Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [Linux Diffserv] Re: [LARTC] ingress qdisc on kernel 2.2.21 withds8 patch
Hello, On Fri, 12 Jul 2002, jamal wrote: > Werner and I did announce (about 2 years ago if i am not mistaken) that > we will not be backporting features fixes etc to 2.2 and were hoping to > encourage people to upgrade this way. There are still 2.2 users :) > > http://www.linuxvirtualserver.org/~julian/#qos-2.2 > > > > To all: if there is a good place for such fixes please let > > me know. > > > > Honestly dont remember these patches -- maybe the time lag. > BTW, what is the motivatein behind: > http://www.linuxvirtualserver.org/~julian/01_ingress-breaks-fw-1.diff At least, FW_REDIRECT, not sure for any others > cheers, > jamal Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch
Hello, On Fri, 12 Jul 2002, Andrei Boros wrote: > I also tried filtering using the u32 match ip dport ... same result. > I even tried u32 match ip (anything ip), same result. This is another issue, may be for howto:12.1.2. Bert promised to clarify them in the Howto: http://mailman.ds9a.nl/pipermail/lartc/2001q4/thread.html Search for "tc: u32 match in nexthdr not working?" In short, dport and sport do not always match, eg. for packets with IP Options. Try different examples. May be your settings are incorrect. > Sorry. However, I don't know of any place where these differences are > explained clearly. Huh. I don't want to start new howto :) Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multiple ADSL link
Hello, On Fri, 12 Jul 2002, Jkx wrote: > > This bug is fixed in iproute2 package from this year. > > Fetch the latest archive. > > (Please add this in the Howto . I spent a couple of > hours to find that) Always use the latest software in such situations, the HowTo is not a changelog :) > so the nex question is : > How could i NAT my local traffic throught this 2 ppp > I usually do that w / Check this URL: http://www.linuxvirtualserver.org/~julian/#routes and read some docs and the included examples. Then you will be able to build correct routing rules for your setup. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ingress qdisc on kernel 2.2.21 with ds8 patch
Hello, On Wed, 10 Jul 2002, Andrei Boros wrote: > I tried to control the ingress traffic with the ingress qdisc with no > success whatsoever. > I got 2.2.21 kernel and installed the ds8 patch to have the ingress > qdisc too. You probably have to apply more fixes to be sure something will not break. I just uploaded some fixes for the 2.2 code as it appears nobody have the time to deal with it: http://www.linuxvirtualserver.org/~julian/#qos-2.2 To all: if there is a good place for such fixes please let me know. > Recompiled, installed kernel and modules. > Recompiled tc with diffserv=y. > > I tried a setup very similar to the example Edge2: Not "very similar" :) The bug is exactly in the differences :) mark here is in decimal (may be can be hex with 0x20): > ipchains -A input -p tcp -d 0/0 20 --mark 20 > ipchains -A input -p tcp -d 0/0 21 --mark 20 > > tc qdisc add dev eth0 handle : ingress "handle 20" here is in hex: > tc filter add dev eth0 parent : protocol ip prio 50 handle 20 fw > police rate 256kbit burst 25k mtu 1.5k drop flowid :1 if you somewhere use fwmark in ip rules, the fwmark there is again in hex. Make sure all values match according to their representation, i.e. 20 in dec is different from 20 in hex. > If anyone has any suggestions, they are most welcome. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multiple ADSL link
Hello, On Thu, 11 Jul 2002, Jerome Kerdreux wrote: > default > nexthop via 80.15.151.117 dev ppp0 weight 1 dead > nexthop via 62.212.102.172 dev ppp1 weight 1 > === > > ppp0 seems to be detected as dead. This bug is fixed in iproute2 package from this year. Fetch the latest archive. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice
Hello, On Mon, 8 Jul 2002, Ard van Breemen wrote: > > Or more correctly, to specify the path between > > each two subnets, the more specific rules and routes before the > > others. > Yes... I like. Although too complex for the users that do not > know what we are talking about. Yes, I usually can't write good docs for the user's eyes :) > > Yes, equalize does not work if the ISPs filter by src. > > This flag is simply not in the kernel, only in user space. > Well, it *does* work in this framework: we only need the > multipath code to select a route, and therefore a source ip. Once > we got the source ip, we will not hit the multipath route > anymore due to the rules... And even if we did, there is a good > chance it is still cached :). Yes, the route cache is the only place that remembers these associations. But it is dangerous for the NAT conns, one IP added and some of the connections can die selecting wrong src IP after the cache is autoflushed. > > This snafu is also fixed in 2.4.19pre8, it is even killed: > > the multipath route is deleted due to SMP locking problems. > Do you mean we cannot have multipaths anymore? Or that the fix > was to remove the multipath route? Yes, the kernel removes the whole multipath route if one device from a path is unregistered. Even without such action from the kernel, the user is obligated to delete this multipath route because if we register the same device name, the nexthop will not switch from dead to alive. So, for 2.4 (I'm not sure how the behaviour will change in 2.5 later) the kernel removes the multipaths but note that we (the users) always have to recreate the multipath routes with unregistered devices. Regards -- Julian Anastasov <[EMAIL PROTECTED]> ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
