[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stalled connections between pf servers



>What happens when you make one router the master of both carp groups? I 
>would assume that the issue mentioned above with pinging 20.1 and 30.1 
>goes away. Does your traffic stalling issue also go away?
If I, for example, set 20.1 down (ifconfig carp3 down on hobbes) and the other
interface (30.1 on hobbes) is already in backup, then yes, my traffic problem
goes away because all the traffic is now being routed through one box (calvin).
I tried to make up a little test to further prove my experience. I can ping the
two carp interfaces (in normal master/backup mode) from both sides of the
network, and can show with tcpdump that only the local server to the subnet
actually responds. If I put the carp interface into INIT, then the other server
responds correctly. My results are below. 
Let's assume for a moment that my theory about the traffic entering hobbes and
leaving calvin when traversing the subnets is true. How would I go about writing
a route-to set that could ensure this is not possible? 
Basically, what I think I would need is a rule that says:
	
[1] Any traffic entering calvin, and destined for the 20.1 network should be
routed to hobbes (unless hobbes is down somehow).
[2] Any traffic entering hobbes, and destined for the 30.1 network should be
routed to calvin (unless calvin is down somehow). 
That way, any return traffic that enters the normal default gateway for that
segment is already destined for the correct local server. The easiest method,
theoretically, is to simply route all 20.0 traffic on calvin to 20.1 (who's
master is hobbes). However, as my testing shows, 20.1 traffic on calvin never
leaves the server (and goes to hobbes) since even in BACKUP mode, the carp
interface seems to be able to receive some traffic. Or possibly, the presence of
the x12 interface on calvin (which is already on the 20.0 network) confuses the
routing? Certainly this experiment hinders my redundancy capabilities.
Honestly, as I've been reading this past weekend, I just do not see people doing
the kind of setup I did. Most people it seems would think of each internet
connection separately, and have a redundant firewall for each connection instead
of what I've done which is having each machine redundant for the other. Either
that, or want to do some kind of load balancing which I am not. My multi-homed
setup just seems to be a bit out of the ordinary configuration. 
Thanks again for all your help. 
Test 1: Ping 20.1 from 20.20
--------------------------------------------------------------
hobbes# tcpdump -nr hobbes/test1/fxp0.log
10:52:54.892606 192.168.20.20 > 192.168.20.1: icmp: echo request
10:52:54.893165 192.168.20.1 > 192.168.20.20: icmp: echo reply
10:52:55.884086 192.168.20.20 > 192.168.20.1: icmp: echo request
10:52:55.884185 192.168.20.1 > 192.168.20.20: icmp: echo reply
10:52:56.880150 192.168.20.20 > 192.168.20.1: icmp: echo request
10:52:56.880248 192.168.20.1 > 192.168.20.20: icmp: echo reply
10:52:57.876187 192.168.20.20 > 192.168.20.1: icmp: echo request
10:52:57.876280 192.168.20.1 > 192.168.20.20: icmp: echo reply
hobbes# tcpdump -nr hobbes/test1/fxp1.log
calvin# tcpdump -nr calvin/test1/xl2.log
calvin# tcpdump -nr calvin/test1/xl1.log
Test 2: Ping 30.1 from 20.20
--------------------------------------------------------------
hobbes# tcpdump -nr hobbes/test2/fxp0.log
12:26:12.267168 192.168.20.20 > 192.168.30.1: icmp: echo request
12:26:12.267802 192.168.30.1 > 192.168.20.20: icmp: echo reply
12:26:13.255377 192.168.20.20 > 192.168.30.1: icmp: echo request
12:26:13.255491 192.168.30.1 > 192.168.20.20: icmp: echo reply
12:26:14.255393 192.168.20.20 > 192.168.30.1: icmp: echo request
12:26:14.255473 192.168.30.1 > 192.168.20.20: icmp: echo reply
12:26:15.255426 192.168.20.20 > 192.168.30.1: icmp: echo request
12:26:15.255504 192.168.30.1 > 192.168.20.20: icmp: echo reply
hobbes# tcpdump -nr hobbes/test2/fxp1.log
calvin# tcpdump -nr calvin/test2/xl2.log
calvin# tcpdump -nr calvin/test2/xl1.log
Test 3: Ping 30.1 from 30.193
--------------------------------------------------------------
hobbes# tcpdump -nr hobbes/test3/fxp0.log
hobbes# tcpdump -nr hobbes/test3/fxp1.log
calvin# tcpdump -nr calvin/test3/xl2.log
calvin# tcpdump -nr calvin/test3/xl1.log
12:28:17.443454 192.168.30.193 > 192.168.30.1: icmp: echo request
12:28:17.443644 192.168.30.1 > 192.168.30.193: icmp: echo reply
12:28:18.437308 192.168.30.193 > 192.168.30.1: icmp: echo request
12:28:18.437368 192.168.30.1 > 192.168.30.193: icmp: echo reply
12:28:19.438773 192.168.30.193 > 192.168.30.1: icmp: echo request
12:28:19.438832 192.168.30.1 > 192.168.30.193: icmp: echo reply
12:28:20.440252 192.168.30.193 > 192.168.30.1: icmp: echo request
12:28:20.440317 192.168.30.1 > 192.168.30.193: icmp: echo reply
Test 4: Ping 20.1 from 30.193
--------------------------------------------------------------
hobbes# tcpdump -nr hobbes/test4/fxp0.log
hobbes# tcpdump -nr hobbes/test4/fxp1.log
calvin# tcpdump -nr calvin/test4/xl2.log
calvin# tcpdump -nr calvin/test4/xl1.log
12:31:33.935154 192.168.30.193 > 192.168.20.1: icmp: echo request
12:31:33.935318 192.168.20.1 > 192.168.30.193: icmp: echo reply
12:31:34.945493 192.168.30.193 > 192.168.20.1: icmp: echo request
12:31:34.945557 192.168.20.1 > 192.168.30.193: icmp: echo reply
12:31:35.947084 192.168.30.193 > 192.168.20.1: icmp: echo request
12:31:35.947145 192.168.20.1 > 192.168.30.193: icmp: echo reply
12:31:36.948646 192.168.30.193 > 192.168.20.1: icmp: echo request
12:31:36.948712 192.168.20.1 > 192.168.30.193: icmp: echo reply