|
Hello,
On Wed, 26 Sep 2001, Alexandre CASSEN wrote:
> Hi julian,
>
> Fisrt of all excuse me for the very long delay :) I am just back to work
> and to LVS.
No problem :)
> >- in some setups we must consider how we can send the outgoing traffic
> >usually according to the source addresses. I.e. when you get WANs from
> >one ISP, how many subnets you receive. Same subnet or different subnet
> >for each WAN?
>
> Well, my first thought was just about using VRRP to add VIP redundance.
> I need this functionnality for my job so I just wanted advices and point
> of view to start implementation and to give my work back to the community.
Yes, In fact, my first goal is totally to overwrite some
parts of the networking to support networks on multiple devices,
with a failover capability, etc. IMO, In a week I'll have a 3th edition
of my patch for dead gateways which now has support for alternative
routes. As result, we will be able to use per-connection load balancing
for outgoing traffic (currently rp_filter does not like the idea of
placing one network over many devices). So, we will be able to use
LVS to utilize many links (our previous idea). LVS is almost ready for
such thing with the exception that the ICMP traffic is not scheduled,
it is forwarded only as related traffic to TCP/UDP connections.
> As we said in different anteriors post, the only way to use VRRP on a
> director
> (LVS or other) owning multiple NICs is to run a VRRP instance per NICs
> since
> VRRP can be view as a routing protocol & synchronization between VRRP
> instances
> must be handled using part of VRRP protocol (synchronization using high
> level
> priority advert).
Yes, may be it is difficult to me to understand all details
of your work, may be because I'm busy with other patches :)
> Reading this mail I can see that you see very ahead :) which is very nice !
> So I can try to give my point of view on certain part.
>
> First of all concerning WAN subnets : In a very common utilization, we are
> working in the same subnet. But for ISP or operator utilization, I agree
> with
> you we can receive many subnets. But considering this last case, can we map
> those
> subnets and routings directly into a "global gateway router" to be focused
> only onto
> the redundance functionnality ?
Yes. In fact, I'm trying to differentiate the hosts on gateways
and end hosts, where the gateways can be an end host too, i.e. all gateways
see all internal and public networks. The routing is destination-based
for all direct links and source-based for the universe. At first look,
IMO, each setup that can be served from a firewall load balancer (for
outgoing traffic) can be replaced with multipath routes that know
the real state fo each gateway at the border. If one end host is on
private network, there is a NAT box that uses the knowledge for all
gateways and their state. If there are more NAT boxes, the end hosts
can use alternative routes to each one. So, I have to think more on
your setup where VRRP will keep one IP reachable for many end hosts.
For me the question is whether I need such box at all :)
> All your points are very interresting... considering outgoing traffic
> loadbalancing,
> we are out of the VRRP scope... we must consider routings setups &
> scheduling.
Yes, complex things :) I first have to fix the routing
behavior
> for security setups SNAT can be use but DR can be much more efficient
> decreasing the director
> load.
DR can be secure at the same level, you only need agreement
with our ISP to use a private network with them, IMO, I have never
tried it.
> The best point of the setup you describe is to be able of selecting
> outgoing interface using
> LVS keys... To answer to this I really need to setup a small architecture
> to try it :)
I already don't remember that :) LVS and everyone that uses
routing calls is aware of the gateway status and with correct routes
LVS forwards the traffic to the right (and alive) gateway for
specific IP range. May be NAT requires some rerouting to hit the right
gateway on one device.
> will schedule work on this :)
>
> Regards,
> Alexandre
Regards
--
Julian Anastasov <ja@xxxxxx>
|
