On Fri, 2007-12-28 at 18:22 -0600, Jerry Vonau wrote: > Brian J. Murrell wrote: > > > and given the CGCO routing table: > > > > 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 > > 67.193.45.68 dev eth0.1 scope link > > 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 > > 10.8.0.0/24 via 10.8.0.2 dev tun0 > > 10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.254 > > 10.75.23.0/24 via 10.8.0.2 dev tun0 > > 67.193.44.0/23 dev eth0.1 proto kernel scope link src 67.193.45.68 > > default via 67.193.44.1 dev eth0.1 > > > > and the main routing table: > > > > 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 > > 192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224 > > 10.8.0.0/24 via 10.8.0.2 dev tun0 > > 10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.254 > > 10.75.23.0/24 via 10.8.0.2 dev tun0 > > 67.193.44.0/23 dev eth0.1 proto kernel scope link src 67.193.45.68 > > 169.254.0.0/16 via 10.75.22.223 dev br-lan proto zebra metric 20 equalize > > default > > nexthop via 67.193.44.1 dev eth0.1 weight 1 > > nexthop via 192.168.200.1 dev ppp0 weight 1 > > > > Both tables are the same,
No they aren't. Most specifically, the CGCO (one of the provider
tables) table, above at top only has a default route to the CGCO
provider. The main table (which is consulted only as a last resort
according to my route rules) is the only table with both default routes
and which is therefore eligible for round-robin default routing. AFAIU.
> is the copy column in the providers file
> blank?
Yes:
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
COPY
CGCO 1 64 main eth0.1 detect
track,balance
IGS 2 128 main ppp0 detect
track,balance
> Both provders' routing should not be in each others table.
Correct. They are not:
# ip route ls table CGCO
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
67.193.45.68 dev eth0.1 scope link
192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224
10.8.0.0/24 via 10.8.0.2 dev tun0
10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.254
10.75.23.0/24 via 10.8.0.2 dev tun0
67.193.44.0/23 dev eth0.1 proto kernel scope link src 67.193.45.68
default via 67.193.44.1 dev eth0.1
# ip route ls table IGS
66.11.173.224 dev ppp0 scope link
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224
10.8.0.0/24 via 10.8.0.2 dev tun0
10.75.22.0/24 dev br-lan proto kernel scope link src 10.75.22.254
10.75.23.0/24 via 10.8.0.2 dev tun0
67.193.44.0/23 dev eth0.1 proto kernel scope link src 67.193.45.68
default via 192.168.200.1 dev ppp0
But given a route rule table with:
0: from all lookup local
10000: from all fwmark 0x40 lookup CGCO
10001: from all fwmark 0x80 lookup IGS
20000: from 67.193.45.68 lookup CGCO
20256: from 66.11.173.224 lookup IGS
32766: from all lookup main
32767: from all lookup default
Does that not mean that packets on this connection:
udp 17 179 src=99.228.107.5 dst=67.193.45.68 sport=34786 dport=1194
packets=25769 bytes=7319381 src=67.193.45.68 dst=99.228.107.5 sport=1194
dport=34786 packets=25116 bytes=4779760 [ASSURED] mark=64 use=1
(notice the mark=) are sent via the CGCO table and ultimately to the:
default via 67.193.44.1 dev eth0.1
route? Seem so to me, yet I still see:
Dec 28 23:31:18 gw.ilinx kernel: Shorewall:fw2all:REJECT:IN= OUT=ppp0
SRC=66.11.173.224 DST=99.228.107.5 LEN=481 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1194 DPT=34786 LEN=461
Dec 28 23:31:18 gw.ilinx kernel: Shorewall:fw2all:REJECT:IN= OUT=ppp0
SRC=66.11.173.224 DST=99.228.107.5 LEN=545 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1194 DPT=34786 LEN=525
Dec 28 23:31:19 gw.ilinx kernel: Shorewall:fw2all:REJECT:IN= OUT=ppp0
SRC=66.11.173.224 DST=99.228.107.5 LEN=505 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=UDP SPT=1194 DPT=34786 LEN=485
I can't see how those are making it to the ppp0 interface.
> /sbin/ip route ls table SHAW
> 24.78.192.1 dev eth1 scope link src 24.78.192.197
> 10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75
> 24.78.192.0/23 dev eth1 proto kernel scope link src 24.78.192.197
> 169.254.0.0/16 dev eth1 scope link
> default via 24.78.192.1 dev eth1
>
> Note the lack of routing for my other provider.
I'm not quite following what routing you see in my CGCO table that is
for the other provider. Indeed there is the
192.168.200.1 dev ppp0 proto kernel scope link src 66.11.173.224
route but that is a very specific route which should not be causing my
problem. I don't think.
In taking a closer look at the REJECT messages above, the SRC address is
for my ppp0 interface, indeed but I assumed that the cross-provider SNAT
rules were doing that, but it does not seem to be the case:
Chain ppp0_masq (1 references)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * * 10.75.22.0/24 0.0.0.0/0
0 0 SNAT all -- * * 67.193.45.68 0.0.0.0/0
to:66.11.173.224
You can see there are no hits on the second rule. So maybe these
packets are getting a source address for the interface the kernel is
wanting to route out of at the moment (i.e. the current round robin
candidate). How does one defeat this "feature" of the kernel and force
packets out of a specific interface? I thought:
Chain tcpre (3 references)
pkts bytes target prot opt in out source destination
1679 393K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match !0x0/0xc0
4240 452K MARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK set 0x40
0 0 MARK all -- * * 10.75.22.101 0.0.0.0/0
MARK set 0x80
Which is a result of the tcrules:
CONTINUE:P 0.0.0.0/0 0.0.0.0/0 all - - - !0/0xc0
# default routing of everything else through cogeco (put exceptions
# below since last match wins)
64:P 0.0.0.0/0
64 $FW
128:P 10.75.22.101
Was supposed to take care of that.
This was all working on my white russian kernel 2.4.30 kernel and is now
not working with kamikaze 2.6.23. ~sigh~
b.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
