Re: L3 DSR

Ed Toro <[email protected]>
Newsgroups gmane.comp.programming.load-balancing.general
Message-ID <[email protected]>
Thanks, Ken. That's a good explanation.

DSR seems to popular with people who are streaming video or other bulk 
data. They don't want to burden the LB with all that return traffic or 
pay the licensing for it to handle that level of traffic.They can also 
get away with buying a lower end LB since even the smallest LB can do 
DSR without using many resources. I think it's a bit of a corner case 
but can be quite cost effective for some.

Anyone serving up regular ol' HTTP/HTML/Web2.0 stuff will probably 
benefit from using a full L7 reverse proxy mode LB. Used in this way, 
the LB can add performance and management that can translate to cost 
savings in manpower and server hardware. I would also think it provides 
a higher level of risk mitigation.


Kenneth Salchow wrote:
>
> It’s been a while, but, here’s the typical way I’ve always know how to 
> do DSR:
>
> You configure your server to have both a valid network IP within its 
> network AND the ip address of your VIP from the ADC that your client 
> is connecting to. When the packet comes in the ADC doesn’t change 
> anything but forwards it on to the appropriate server. In order for 
> this to work, you need to route the packet to the server as if it is 
> the next hop router. When it sees a destination address (VIP) that it 
> also owns, it replies and uses that IP as the source.
>
> Now—if you separate the server from the load balancer via another 
> router—you are going to have to convince that router to route VIA the 
> node you selected. You have to trick that router into thinking that 
> everyone of your servers are a valid route path to the VIP and to pick 
> the one the load balancer wanted. Now, I’m sure there are probably 
> ways to do this, but I don’t know of any easy ones off hand—you start 
> getting into some very real network voodoo IMHO. And the real question 
> is why would you want to/need to do that?
>
> The other way I’ve seen—for http anyway—is for the load balance to 
> select a node and issue a redirect directly to that node instead of 
> forwarding the packet. You lose ALL control of the communications, but 
> that works—and as longs as you account for NAT and such—it doesn’t 
> matter where the servers are—they could even be on another site.
>
> *KJ (Ken) Salchow, Jr.* *|* Manager, Technical Marketing
>
> *From:* [email protected] [mailto:[email protected]] *On 
> Behalf Of *zep k
> *Sent:* Tuesday, March 31, 2009 1:40 AM
> *To:* Load Balancing Mailing List
> *Subject:* Re: [load balancing] L3 DSR
>
> SungLyeol
>
> As we all know, DSR means a way of returning packets to clients. 
> Weather they flow back thru LB or directly to clients.
>
> For direct return, LB should forward packets to server without chaning 
> ip address.
>
> For this forwarding method, MAC based communication should be used. 
> Anyone know other tech?
>
> From the discription you did below,
>
> Servers reside on different network. How does the LB forward packets 
> to Servers?
>
> Are you asking if there is another method other than MAC communication 
> for DSR?
>
> We need correct description.
>
> Regards
>
> Alex
>
> 2009/3/31 SungLyeol Choi <[email protected] <mailto:[email protected]>>
>
> Hello.
>
> I think those are normal DSR even though L4 is connect to L3 and has 
> two different network.
>
> my question was
>
> Clients
>
> |
> | 192.168.10.0/24 <http://192.168.10.0/24>, VIP : 192.168.10.100
> |
>
> L2 or L3-SW ==== L4 SW
> |
> | 172.16.10.1/24 <http://172.16.10.1/24>
>
> L3 SW
>
> l
> | 10.10.10.0/24 <http://10.10.10.0/24>
> Servers
>
> it means Server should be located in other network. my customer told 
> me some vendors mentioned that.
>
> in this topology L4 should send client traffic to Server by L3 SW.
>
> thanks.
>
> Date: Mon, 30 Mar 2009 10:22:50 -0700 (PDT)
> From: Surya ARBY <[email protected] <mailto:[email protected]>>
> Subject: Re: [load balancing] L3 DSR
> To: Load Balancing Mailing List <[email protected] <mailto:[email protected]>>
> Message-ID: <[email protected] 
> <mailto:[email protected]>>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> Hello.
>
> I guess it protects against L2 broadcast because you can build L2 
> isolation by constraining? return traffic to go to the routing point 
> of the network, thus limiting flooding, that's the only sense I take 
> from the sentence :)
>
> Surya
>
> --- En date de?: Lun 30.3.09, Kenneth Salchow <[email protected] 
> <mailto:[email protected]>> a ?crit?:
>
>
> De: Kenneth Salchow <[email protected] <mailto:[email protected]>>
> Objet: Re: [load balancing] L3 DSR
> ?: "Load Balancing Mailing List" <[email protected] <mailto:[email protected]>>
> Date: Lundi 30 Mars 2009, 17h59
>
>
>
>
>
>
>
>
>
>
>
>
> Maybe I?m forgetting something, but I believe *all*
> DSR (direct server return) is L3.? L2 DSR wouldn?t be too useful
> unless you had one really, really big, flat, private network, would it?
>
> ?
>
> Most vendors support this type of configuration in one way or
> the other?but I also don?t know of any that recommend the
>
> configuration, except for very specific circumstances.? But?even in
>
>
> video streaming these days, there are benefits to running the traffic 
> back through
> the ADC in order to manage out-bound traffic flow?and there are plenty of
> boxes that can handle the throughput.
>
> ?
>
> So?when you talk about ?protecting L2 Broadcast??what
> exactly are you trying to do and why?
>
> ?
>
> --and, if I?m being complete silly, please forgive me?it
> is Monday morning.? J
>
> ?
>
> KJ (Ken) Salchow, Jr.??|??Manager,
> Technical Marketing
>
> ?
>
>
>
> From: [email protected] <mailto:[email protected]>
> [mailto:[email protected] <mailto:[email protected]>] On 
> Behalf Of SungLyeol Choi
>
> Sent: Monday, March 30, 2009 9:46 AM
>
> To: [email protected] <mailto:[email protected]>
>
> Subject: [load balancing] L3 DSR
>
>
> ?
>
>
>
> Hi guys.
>
>
>
> ?
>
>
>
>
>
> Have you heard about L3 DSR?
>
>
>
>
>
> which vendors support this?
>
>
>
>
>
> I heard L3 DSR could protect L2
> broadcast. but I think LB should consider a lot of things to support that.
>
>
>
>
>
> ?
>
>
>
>
>
> Thanks.
>
>
>
>
>
>
>
> _______________________________________________
> lb-l mailing list
> [email protected] <mailto:[email protected]>
> http://vegan.net/mailman/listinfo/lb-l
> Searchable Archive: http://vegan.net/lb/archive
> http://lbdigest.com <http://lbdigest.com/> Load Balancing Digest
> http://lbwiki.com <http://lbwiki.com/> Load Balancing Wiki
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://vegan.net/pipermail/lb-l/attachments/20090330/6b17b93c/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Mar 2009 10:25:39 -0700
> From: Joo Yong-Seok <[email protected] 
> <mailto:[email protected]>>
> Subject: Re: [load balancing] L3 DSR
> To: Load Balancing Mailing List <[email protected] <mailto:[email protected]>>
> Message-ID:
> <[email protected] 
> <mailto:[email protected]>>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> I suppsoe that L2 or L3 config doesn't matter. the important thing in 
> DSR is
> "returning packet" should
> not be forwarded to L4 and L4 should not do any processing for that.
>
> Clients
> |
> | 192.168.10.0/24 <http://192.168.10.0/24>, VIP : 192.168.10.100
> |
> L3-SW ==== L4 SW
> |
> |
> | 10.10.10.0/24 <http://10.10.10.0/24>
> Servers
>
> In this topoloty, L4 can have two interfaces for 192.168.10.0/24 
> <http://192.168.10.0/24> and
> 10.10.10.0/24 <http://10.10.10.0/24>. In Servers point of
> view, GW should be L3-SW. Client requests will be forwarded to L3 but L3
> knows the VIP location (L4)
> and it will forward the request via L2-fwd.
>
> L4 will do a client processing and send the packet to Servers. In this
> moment, DSR should be enabled
> and request packet's DIP is not modified. and Server will received the
> packet and then forward it to L3-SW
> since L3-SW is a gateway for servers.
>
> I suppose that this is L3 DSR and return packet will not traverse to L4.
>
> Also, L4-SW is in the same network with servers, health check by using
> real-mac (VIPhealth) is also
> working and No mac flapping. (Since L4 is doing L3 fwd + L4 processing and
> packet's SIP should be
> modified. L3-SW will not have any duplicate mac-address entry in the 
> fdb. -
> Even there are same mac
> in fdb, if VLAN is different, there should be no issues to do a L2-fwd).
>
> I have no idea why L2 broadcast issue is there on DSR. (do you mean
> "mac-flapping"? - this can cause
> flooding in the network).
>
> Best regards,
>
> - yongseok
>
> 2009/3/30 SungLyeol Choi <[email protected] <mailto:[email protected]>>
>
> > Hi guys.
> > Have you heard about L3 DSR?
> > which vendors support this?
> > I heard L3 DSR could protect L2 broadcast. but I think LB should 
> consider a
> > lot of things to support that.
> >
> > Thanks.
> >
> > _______________________________________________
> > lb-l mailing list
> > [email protected] <mailto:[email protected]>
> > http://vegan.net/mailman/listinfo/lb-l
> > Searchable Archive: http://vegan.net/lb/archive
> > http://lbdigest.com <http://lbdigest.com/> Load Balancing Digest
> > http://lbwiki.com <http://lbwiki.com/> Load Balancing Wiki
> >
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://vegan.net/pipermail/lb-l/attachments/20090330/87d718d9/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 30 Mar 2009 10:43:17 -0700
> From: Joo Yong-Seok <[email protected] 
> <mailto:[email protected]>>
> Subject: Re: [load balancing] L3 DSR
> To: Load Balancing Mailing List <[email protected] <mailto:[email protected]>>
> Message-ID:
> <[email protected] 
> <mailto:[email protected]>>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> There is TYPO.
>
> SIP ---> SMAC.
>
> Best regards,
>
> - yongseok
>
> On Mon, Mar 30, 2009 at 10:25 AM, Joo Yong-Seok 
> <[email protected] <mailto:[email protected]>>wrote:
>
> > I suppsoe that L2 or L3 config doesn't matter. the important thing 
> in DSR
> > is "returning packet" should
> > not be forwarded to L4 and L4 should not do any processing for that.
> >
> > Clients
> > |
> > | 192.168.10.0/24 <http://192.168.10.0/24>, VIP : 192.168.10.100
> > |
> > L3-SW ==== L4 SW
> > |
> > |
> > | 10.10.10.0/24 <http://10.10.10.0/24>
> > Servers
> >
> > In this topoloty, L4 can have two interfaces for 192.168.10.0/24 
> <http://192.168.10.0/24> and
> > 10.10.10.0/24 <http://10.10.10.0/24>. In Servers point of
> > view, GW should be L3-SW. Client requests will be forwarded to L3 but L3
> > knows the VIP location (L4)
> > and it will forward the request via L2-fwd.
> >
> > L4 will do a client processing and send the packet to Servers. In this
> > moment, DSR should be enabled
> > and request packet's DIP is not modified. and Server will received the
> > packet and then forward it to L3-SW
> > since L3-SW is a gateway for servers.
> >
> > I suppose that this is L3 DSR and return packet will not traverse to L4.
> >
> > Also, L4-SW is in the same network with servers, health check by using
> > real-mac (VIPhealth) is also
> > working and No mac flapping. (Since L4 is doing L3 fwd + L4 
> processing and
> > packet's SIP should be
> > modified. L3-SW will not have any duplicate mac-address entry in the 
> fdb. -
> > Even there are same mac
> > in fdb, if VLAN is different, there should be no issues to do a L2-fwd).
> >
> > I have no idea why L2 broadcast issue is there on DSR. (do you mean
> > "mac-flapping"? - this can cause
> > flooding in the network).
> >
> > Best regards,
> >
> > - yongseok
> >
> > 2009/3/30 SungLyeol Choi <[email protected] <mailto:[email protected]>>
> >
> >> Hi guys.
> >> Have you heard about L3 DSR?
> >> which vendors support this?
> >> I heard L3 DSR could protect L2 broadcast. but I think LB should 
> consider
> >> a lot of things to support that.
> >>
> >> Thanks.
> >>
>
>
> _______________________________________________
> lb-l mailing list
> [email protected] <mailto:[email protected]>
> http://vegan.net/mailman/listinfo/lb-l
> Searchable Archive: http://vegan.net/lb/archive
> http://lbdigest.com <http://lbdigest.com/> Load Balancing Digest
> http://lbwiki.com <http://lbwiki.com/> Load Balancing Wiki
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> lb-l mailing list
> [email protected]
> http://vegan.net/mailman/listinfo/lb-l
> Searchable Archive: http://vegan.net/lb/archive
> http://lbdigest.com Load Balancing Digest
> http://lbwiki.com Load Balancing Wiki
>   

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.