From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Oct 13 2004 - 19:39:19 GMT-3
Assume r1 and r2 are connected via ppp (could be isdn, but it doesn't have
to be).
You can configure ppp authentication on r1 but not configure authentication
on r2. If you do this, r2 has to authenticate before it can communicate
with R1, but r1 doesn't have to authenticate with r2 to communicate with it.
Think of it like this.
Suppose you go to a free standing ATM machine in some mall somewhere to take
out some cash. You put your card in the slot and the atm machine tells you
to enter your pin, so you do.
Then you get a message saying something like, "Sorry, but we can't reach
your bank to authenticate your identity. Please try again later."
Quite possibly you have become a victim of a fraud. That ATM machine
"authenticated" you by getting your card # and pin, but you didn't get your
cash. And, even worse, in about 5 minutes your bank account is clean out.
All because you didn't authenticate that atm before giving up your pin.
HTH, Tim
----- Original Message -----
From: "Carlos G Mendioroz" <tron@huapi.ba.ar>
To: "Brian McGahan" <bmcgahan@internetworkexpert.com>
Cc: "Gene Thorne" <gthorne@netcogov.com>; <ccielab@groupstudy.com>
Sent: Wednesday, October 13, 2004 6:01 PM
Subject: Re: Something New (the myths we believe)
> What do you mean by ppp authentication not being a two way process ?
>
>
> Brian McGahan wrote:
>
> > Better yet that you can't remove a line out of a numbered access-list
> > without destroying and recreating the entire list. (you can)
> >
> > "no arp frame-relay" stops inverse-arp replies (it doesn't)
> >
> > ppp authentication is a two way process (it's not)
> >
> > Don't start listing these behaviors as "gotchas" though, they
> > are simply technologies that the fundamental behaviors are
> > misunderstood. Most of these "myths" can be eliminated by simply trying
> > the configuration out and seeing how it works firsthand on the command
> > line.
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> >
> >>-----Original Message-----
> >>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> >
> > Of
> >
> >>Gene Thorne
> >>Sent: Wednesday, October 13, 2004 12:12 PM
> >>To: ccielab@groupstudy.com
> >>Subject: RE: Something New (the myths we believe)
> >>
> >>My favorite myth is that static routes pointing to an interface have
> >
> > an
> >
> >>admin distance of 0, not 1.
> >>
> >>-----Original Message-----
> >>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> >>Joe Rinehart
> >>Sent: Wednesday, October 13, 2004 12:02 PM
> >>To: ccielab@groupstudy.com
> >>Subject: Something New (the myths we believe)
> >>
> >>
> >>Just when you think you have things halfway figured out you realize
> >
> > how
> >
> >>far
> >>off your perceptions can be. I had two "revelations" while working on
> >
> > the
> >
> >>Netmaster DoIt lab #1 (its pretty grueling, in a good way). There
> >
> > were
> >
> >>two
> >>things that really bit me because I thought I knew these for
> >
> > certain....
> >
> >>Myth#1 A Catalyst 3550 cannot do BGP.
> >>
> >>When the lab asked for this I thought it was a joke, and to be honest
> >
> > I
> >
> >>cannot remember where I picked this idea up, but a quick check on the
> >
> > doc
> >
> >>CD
> >>and I found my face turning red (proverbially speaking). I think I
> >
> > was
> >
> >>relying on a "features not supported" on one of the CCIE Cisco Press
> >
> > study
> >
> >>books... In any case there are some limitations but it does indeed
> >>support
> >>BGP....
> >>
> >>Myth#2 Subinterfaces cannot coexist with natural interfaces on the
> >
> > same
> >
> >>physical interface.
> >>
> >>This one blew me away. When I read the question I figured it was one
> >
> > of
> >
> >>those "trick answers" that just had to be interpreted, so I did a
> >>multipoint
> >>subinterface and a point to point subinterface. When I was working
> >
> > though
> >
> >>the answer key I was rather taken aback to see that it was on the
> >
> > physical
> >
> >>interface. Still a skeptic, I removed the multipoint subinterface,
> >
> > put
> >
> >>the
> >>code on the main interface (leaving the P2P subif) and then reloaded
> >
> > the
> >
> >>router. I was shocked it worked.
> >>
> >>I think my reason for posting this is just to see if there have been
> >
> > any
> >
> >>other experiences like this for other folks and what those assumptions
> >>were.
> >>After all, there is a saying about assume.....
> >>
> >>Joe Rinehart, CCNP, CCDP
> >>Data Network Consultant, AT&T Corporation
> >>Pacific Northwest Enterprise Markets
> >>
> >>
> >
> > _______________________________________________________________________
> >
> >>Subscription information may be found at:
> >>http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >
> > _______________________________________________________________________
> >
> >>Subscription information may be found at:
> >>http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
> --
> Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:47 GMT-3