From: Scott Morris (swm@emanon.com)
Date: Thu Sep 30 2004 - 18:36:22 GMT-3
Heheheh... Only in calculus did I screw up the bell curve. :) otherwise,
I was an average guy who tended to apply himself in what he found
interesting (which wasn't all that much!)...
Otherwise, it's just a vast collection of useless knowledge that I
occasionally find a use for! ;)
If you have a remote-peer configured, then you should be able to observe a
connection come up. Whether it stays up all the time will depend on your
topology and other things going on. If two peers reach the exact same
things and nothing more, then you'll eventually see the winner, so it may be
a timing issue.
You can always clear the peers to see the other one again! But the session
will be at least initially established!
I miss having Fred Ingham around, he always had entertaining stories to go
along with some of these evil DLSw things... :)
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIP, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Thursday, September 30, 2004 5:32 PM
To: swm@emanon.com; 'Group Study'
Subject: Re: Dlsw load balancing
Hey Scott,
Jeez, how do you know and remember so much? It's really mind boggling.
Were you one of those guys in school all the C students hated because you
messed up the grading curve?
In any case, thanks alot.
BTW, is there an easy way of verifying that cost has been properly
configured?
I know that in the output of the show dlsw cap command, you'll see the cost
configured on the remote peer with the lowest cost, but what about peers
that aren't the lowest cost?
Will those peers NOT show up because dlsw will only create a remote session
with lowest cost peers?
Thanks again, Tim
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Group Study'"
<ccielab@groupstudy.com>
Sent: Thursday, September 30, 2004 2:58 PM
Subject: RE: Dlsw load balancing
> A quandry, it is....
>
> Once you enable load-balancing, then circuit weight is the measurement
that
> is looked at first. If you are not load-balancing, then peer cost is used
> to determine the best path to a destination.
>
> HTH,
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
> JNCIP, et al.
> IPExpert CCIE Program Manager
> IPExpert Sr. Technical Instructor
> swm@emanon.com/smorris@ipexpert.net
> http://www.ipexpert.net
>
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Thursday, September 30, 2004 1:58 PM
> To: swm@emanon.com; 'Group Study'
> Subject: Re: Dlsw load balancing
>
> Thanks Scott, u da mon !!!
>
> And, while we're on the topic of dlsw...
>
> I was just reviewing some of my notes and cam across an interesting load
> balancing issue.
>
> Suppose there's a "conflict" between circuit weight and cost. For
example,
>
> / RTR -B
> /
> RTR-A
> \
> \ RTR -C
>
>
> rtr-A is configured with:
>
> dlsw remote-peer 0 tcp rtr-B circuit weight 10 dlsw remote-peer 0 tcp
> rtr-C circuit weight 10
>
> So, rtr-A should distribute new circuits equally between rtr-B and rtr-C
> based on above.
>
> But, rtr-B is configured with:
>
> dlsw local-peer peer-id rtr-B cost 2
>
> And, rtr-C is configured with:
>
> dlsw local-peer peer id rtr-C cost 4
>
> What happens now?
>
> Based on rtr-B's and rtr-C's config, rtr-A should only connect to rtr-B
> because it has the lowest cost.
> But, based on rtr-A config, connections should be balanced between the 2
> remote peers.
>
> And, if the config's were changed so that rtr-A's remote-peer commands
were
> config'd with cost, but rtr-B and rtr-C local peer commands were config's
> with circuit weight in a "conflicting" way, what would happen?
>
> In other words, does cost take precedence over circuit weight or does
what's
> configured on remote peer still take precedence over what's configured on
> local peer?
>
> And, 1 last scenario. Is there a "default" cost? For example, suppose
> using the same rtr's as above, rtr-A should prefer rtr-B, but no special
> config is allowed on rtr-A. If rtr-B has NO cost configured and rtr-C has
> cost X, will rtr-A prefer rtr-B or rtr-C?
>
> I don't know if these type of issues are going way beyond what might be
> found on the lab, but it seems like Cisco keeps upping the ante in terms
of
> difficulty, so I figure I better just make sure I know this stuff.
>
> Thanks, Tim
>
> ----- Original Message -----
> From: "Scott Morris" <swm@emanon.com>
> To: "'ccie2be'" <ccie2be@nyc.rr.com>; "'Group Study'"
> <ccielab@groupstudy.com>
> Sent: Thursday, September 30, 2004 1:09 PM
> Subject: RE: Dlsw
>
>
> > Correct. While advertised during the peer's capabilities exchange, I
may
> > tell you one thing, but in your remote-peer statement to me, you "know
> > better" and whatever value you have locally for our peering relationship
> > overrides what I may try to tell you.
> >
> > HTH,
> >
> >
> > Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP,
> > JNCIP, et al.
> > IPExpert CCIE Program Manager
> > IPExpert Sr. Technical Instructor
> > swm@emanon.com/smorris@ipexpert.net
> > http://www.ipexpert.net
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > ccie2be
> > Sent: Thursday, September 30, 2004 12:29 PM
> > To: Group Study
> > Subject: Dlsw
> >
> > Hi guys,
> >
> > I've noticed that some parameters e.g. cost, circuit weight, etc can be
> used
> > on both the dlsw local peer and dlsw remote peer commands.
> >
> > Is it always true that if the same parameter is configured on both dlsw
> peer
> > (local & remote), the parameter configured on the remote command takes
> > precedence?
> >
> >
> > TIA, Tim
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:51 GMT-3