From: Radu Pavaloiu (Radu.Pavaloiu@connex.ro)
Date: Fri Oct 01 2004 - 04:54:29 GMT-3
Only for tcp dlsw+ peers I think you can try "clear tcp tcb 0x......"
I die. I fracture into thousands of fragments of flushed embarrassment.
My body parts fly, connectionless, over a badly constructed spanning
tree that isn't quite loop free.
I fall screaming into 127.0.0.1.
Radu
CCNP, CCDP
#+40213022658
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Friday, October 01, 2004 1:04 AM
To: swm@emanon.com; 'Group Study'
Subject: Re: Dlsw load balancing
I miss Fred also as I'm sure everyone on GS does. Maybe you can talk to
him and shamelessly beg him to come back.
"Clear the peers"?
Are you referring to "dlsw disable" followed by "no dlsw disable" which
removes all active peering?
Or, some way of clearing an individual peering session for which I know
of no graceful way of doing except preceeding the remote peer statement
with "no" and then re-enabling.
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 5:36 PM
Subject: RE: Dlsw load balancing
> 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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:41 GMT-3