|
On Fri, Jul 18, 2003 at 01:40:57PM +0200, Roberto Nibali wrote:
> Hi Andy,
>
> Glad you solved it.
>
> >I looked into this a little bit further. The problems I was having were
> >mostly due to the OpenBSD firewall not keeping state on those
> >connections that needed to be routed by that router/etherIP bridge
>
> Configuration mistake? Did you forget a "keep state" or was it another
> semantical issue?
No, to clarify I had to make the firewall rules to the clustered service
stateless. I log all blocked traffic, so I would have seen it if it
was just getting blocked. But it wasn't getting blocked, though, it
just kind of disappeared after going on the bridge. After I
allowed traffic without keeping state from my client machine to the
cluster node it started working (except for the mtu).
>
> >machine. After I got that fixed traffic would show up on the cluster
> >node and the node would try to reply, but I would never see the return
>
> Do you have a scrub rule?
No I don't have any scrub rules.
>
> >traffic. So after doing a little further investigation the tcpdumps
> >showed me that the traffic needed to be fragmented because on that
> >bridge the mtu is 1280. So I set the mtu to 1280 on the the cluster
> >node and everything works.
>
> That's why I wanted all the tcpdumps :). BTW, how did you set the mtu? I
> hope you set it on routing level and not on link level, because then you
> would limit all traffic through the interface to such a low mtu.
I set the mtu on the link level. How do you change it at the routing
level? That would definitely be desirable. I'm trying to figure out
why the mtu discovery isn't working. It works if I'm on the same
network, but not if I have to use a route. On the director I get this
on a tcpdump:
08:55:00.924860 192.168.0.48 > 192.168.0.143: icmp: 192.168.0.48 unreachable -
need to frag (mtu 1280)
But I never see that on 192.168.0.143. Doing a tcpdump on the router,
I see it on vlan0 at 192.168.0.1, which is on the router interface
for 192.168.0.48, but never on vlan2 at 192.168.0.129 which is the
router interface for 192.168.0.143.
>
> Why is your bridge on 1280?
The mtu on the gif interface is 1280:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
I assume it's because of the overhead of encapsulation.
>
> >So you can add that as another way to geographically extend the LVS.
>
> :)
>
> >Although it is a little inefficient since all broadcasted lan traffic
> >gets transmitted, but that isn't a problem for me.
>
> You can always add a blackhole route for broadcast traffic. Put a VIP
> route with high prio into a separate routing table and the broadcast
> traffic into another one, where you add a blackhole route. The default
> gateway should then be in the VIP route table.
>
> Cheers,
> Roberto Nibali, ratz
> --
> echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
