From: Ahmed Mustafa (ahmed.mustafa@sbcglobal.net)
Date: Sat Mar 20 2004 - 19:02:06 GMT-3
PacketMan,
I liked your idea of sharing tips. This will b really beneficial to of CCIE
candidates.
Sorry, I forgot to include Bri interface for "no peer neighbor route". That
is what I meant.
Regards,
Ahmed
----- Original Message -----
From: "Packet Man" <ccie2b@hotmail.com>
To: <ahmed.mustafa@sbcglobal.net>; <richard.dumoulin@vanco.es>;
<alsontra@hotmail.com>; <ccielab@groupstudy.com>
Sent: Saturday, March 20, 2004 12:49 PM
Subject: Re: Lab Tips - Redist OSPF into another Protocol
> Ahmed,
>
> Thanks for your excellent contribution. I was hoping this lab tips idea
> would generate exactly this kind of response. Now, (you're not surprised
> are you) I have to ask you about something you said here in Tip #4.
>
> 1) Why have "no peer nei route" on a loopback int? Isn't this only
needed
> on a bri 0 int to prevent the isdn link from flapping?
>
> Thanks again for this wonderful contribution.
>
>
> >From: "Ahmed Mustafa" <ahmed.mustafa@sbcglobal.net>
> >Reply-To: "Ahmed Mustafa" <ahmed.mustafa@sbcglobal.net>
> >To: "Richard Dumoulin" <richard.dumoulin@vanco.es>,"Packet Man"
> ><ccie2b@hotmail.com>,<alsontra@hotmail.com>,<ccielab@groupstudy.com>
> >Subject: Re: Lab Tips - Redist OSPF into another Protocol
> >Date: Sat, 20 Mar 2004 10:58:34 -0800
> >
> >More Tips
> >
> >
> >1) The external key is only required if OSPF redistributed into BGP. I
> >have tested OSPF with EIGR/RIP and all OSPF external/internal routes were
> >redistributed without the external keyword.
> >
> >2) All routing protocols such as eigrp/rip/isis will have a default cost
> >of
> >20, except BGP that will have a default cost of 1 when these protocols
get
> >redistributed intos ospf.
> >
> >3) ibgp routes will not get redistributed into other protocols unless
you
> >specifically use the keyword internal. ebgp routes will get
redistributed
> >without any special keyword.
> >
> >4) always use "no peer neighbor route", router-id's, ip ospf network
> >point-to-point on ospf loopback interfaces to have stability in your
> >network
> >unless it is instructed not to do so.
> >
> >5) Make sure you pay attention to routes coming from BB routers. When
you
> >get to the task where you start receving BB routes make sure you can ping
> >those routes from everywhere. If you wait until the end you will get lot
> >of
> >grief. If lab requires to have full IP reachibility, and can't ping the
BB
> >routes that you think you should be able to ping. Ask proctor rightway
to
> >get clarification.
> >
> >6) When you reach to a security task, always ping your routes after
> >configuring each task. Don't complete the section and then start
pinging.
> >You won't know where to start troubleshooting versus pinging routes
after
> >each task then you will know rightaway.
> >
> >HTH,
> >
> >
> >
> >
> >----- Original Message -----
> >From: "Richard Dumoulin" <richard.dumoulin@vanco.es>
> >To: "Packet Man" <ccie2b@hotmail.com>; <alsontra@hotmail.com>;
> ><ccielab@groupstudy.com>
> >Sent: Saturday, March 20, 2004 1:41 AM
> >Subject: RE: Lab Tips - Redist OSPF into another Protocol
> >
> >
> > > I believe this is for ospf although for isis it's a good idea to be as
> > > specific as possible too.
> > >
> > > So for ospf, the command "redistribute ospf 2 match internal external
1
> > > external 2" can be used. But the recommended way is to explicitly
state
> >the
> > > network one wants to redistribute into BGP with a prefix-list and a
> > > route-map. Here the "match internal external " is not needed,
> > >
> > > --Richard
> > >
> > > -----Mensaje original-----
> > > De: Packet Man [mailto:ccie2b@hotmail.com]
> > > Enviado el: sabado, 20 de marzo de 2004 1:53
> > > Para: Richard Dumoulin; alsontra@hotmail.com; ccielab@groupstudy.com
> > > Asunto: RE: Lab Tips - Redist OSPF into another Protocol
> > >
> > >
> > > Hey Richard,
> > >
> > > Good Tip - That's just the sort of thing I imagined when starting this
> > > thing.
> > >
> > > But, couldn't that tip be more generalized ie. when redist ospf into
> >any
> > > prot or is this specific to redist into BGP only?
> > >
> > >
> > > >From: Richard Dumoulin <richard.dumoulin@vanco.es>
> > > >To: Packet Man <ccie2b@hotmail.com>, alsontra@hotmail.com,
> > > >ccielab@groupstudy.com
> > > >Subject: RE: Lab Tips - ISDN
> > > >Date: Sat, 20 Mar 2004 00:41:21 -0000
> > > >
> > > >I have been spending two hours trying to figure out why my ospf
> >external
> > > >route was not getting redistributed into BGP.
> > > >So TIP:
> > > >
> > > > By default, when redistributing ospf into BGP only internal ospf
> >routes
> > > >will go into BGP. Remember the external option !!
> > > >
> > > >--Richard
> > > >
> > > >-----Mensaje original-----
> > > >De: Packet Man [mailto:ccie2b@hotmail.com]
> > > >Enviado el: viernes, 19 de marzo de 2004 23:37
> > > >Para: alsontra@hotmail.com; ccielab@groupstudy.com
> > > >Asunto: Re: Lab Tips - ISDN
> > > >
> > > >
> > > >Hey Alsontra,
> > > >
> > > >That's a GREAT tip. I wasn't even aware of those commands. sounds
> >like
> > > >they can be very useful. But, what the difference and benefit
between
> > > >using
> > > >
> > > >this method and using the old method (pinging the remote BRI
> >interface)?
> > > >
> > > >
> > > > >From: <alsontra@hotmail.com>
> > > > >To: "Packet Man" <ccie2b@hotmail.com>,<ccielab@groupstudy.com>
> > > > >Subject: Re: Lab Tips - ISDN
> > > > >Date: Fri, 19 Mar 2004 16:19:41 -0800
> > > > >
> > > > >ISDN:TIP
> > > > >
> > > > >1.After making your initial ISDN configs, use the "isdn test call
> > > >interface
> > > > >bri (DN#)" command to verify that your interface working properly.
> > > > > Also, use the "isdn test call disconnect interface bri all"
> >instead
> >of
> > > > >"clear int bri 0/0". The latter command can cause problems with the
> >isdn
> > > > >switch that may cause you problem later on.
> > > > >2. If your using dialer interfaces make sure to use either ppp or
> >dialer
> > > > >caller to identify the calling party(by name or number).
> > > > >
> > > > >Shootin from the hip here, so forgive the typos...
> > > > >
> > > > >Alsontra-
> > > > >
> > > > >
> > > > >
> > > > >----- Original Message -----
> > > > >From: "Packet Man" <ccie2b@hotmail.com>
> > > > >To: <ccielab@groupstudy.com>
> > > > >Sent: Thursday, March 18, 2004 1:58 PM
> > > > >Subject: Lab Tips
> > > > >
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I've created a "Lab Tips" file of small items - factoids,
> >reminders,
> > > > > > suggestions, etc, I tend to forget. This is something I can
refer
> >to
> > > > > > constantly when I'm doing practice labs or just have a few
minutes
> >to
> > > > >spare.
> > > > > >
> > > > > > Here's a snippet from my Tips file.
> > > > > >
> > > > > > BGP
> > > > > > Hard code router-id
> > > > > > Don't use loopbacks for ibgp peering unless explicitly required
> > > > > > Look for nei ... next-hop-self requirement especially on F/R hub
> >and
> > > > > > ethernets
> > > > > > Disable bgp client to client reflection when clients are fully
> >meshed
> > > > > > Turn off auto-sum & sync unless explicitly required
> > > > > > Reset BGP sessions using hard reset rather than soft reset.
> > > > > > Know how to config nei xxxx local-as in combo with RR.
> > > > > > Know all ways to config dampening
> > > > > >
> > > > > > I'm sharing this with GS because I suspect many candidates might
> >also
> > > > >have
> > > > > > something like this. And, I thought that with all the great
brain
> > > >power
> > > > > > among GS subscribers we could all help each other by adding tips
> >to
> > > >such
> > > >
> > > > >a
> > > > > > file.
> > > > > >
> > > > > > Here's my definition of what makes for a good tip.
> > > > > >
> > > > > > 1) A tip may not in any way violate the NDA
> > > > > > 2) A good tip should be something that might be easily
forgotten
> > > > >because
> > > > > > it's not that often encountered or somehow different from the
> > > >ordinary.
> > > > >For
> > > > > > example, when configuring ISIS over frame relay, don't forget
to
> > > >enter
> > > > >the
> > > > > > "fram map clns <dlci> broadcast" statement. For me, this is a
> >good
> > > >tip
> > > > > > because I personally don't practice ISIS that often and I seem
to
> > > >almost
> > > > > > always forget that command.
> > > > > >
> > > > > > 3) A good tip must be short and clear because the whole idea
> >behind
> > > >this
> > > > > > file is to provide a quick reminder of various networking facts
> >that
> > > >can
> > > > > > come in handy during the actual lab.
> > > > > >
> > > > > > 4) A good tip must should not waste time going into the "why" of
> >the
> > > > >fact
> > > > >or
> > > > > > all the various permutations. For that, anyone interested can
> > > >research
> > > > >the
> > > > > > "why" of the fact on their own.
> > > > > >
> > > > > > 5) A good tip for one person might not be at all useful to
someone
> > > >else.
> > > > >We
> > > > > > each tend to remember and forget different things. But, for
> >example,
> > > > >over
> > > > > > time the BGP tips section may include 30 items and while I doubt
> >all
> > > >30
> > > > > > items will be useful to all people, I'm sure that 5 or 10 or 15
of
> >the
> > > > >tips
> > > > > > will be useful to many people - just that it won't be the same 5
> >or
> >10
> > > > >or
> > > > >15
> > > > > > tips.
> > > > > >
> > > > > > 6) A good tip must be potentially relevant to a ccie R&S
> >candidate.
> > > > > > Therefore, I ask that Off Topic comments be submitted
elsewhere -
> > > >Let's
> > > > >keep
> > > > > > posts with the subject "Lab Tips" focus on just that.
> > > > > >
> > > > > > It's my hope that over time, with the input of a lots of people
> >here,
> > > > >this
> > > > > > lab tips file will grow to include tips that cover every topic
> > > > >potentially
> > > > > > on the R&S lab exam. And, that as a result, we can each add the
> >most
> > > > > > personally valuable tips from this group effort to our own lab
> >tips
> > > > >file.
> > > > > >
> > > > > > Right now, my tips file has no entries for voice. So, I'd like
to
> > > >start
> > > > >off
> > > > > > by asking people to submit their voice config tips. Of course,
> >tips
> >on
> > > > >any
> > > > > > potential lab are also welcomed.
> > > > > >
> > > > > > Here are some other potential tips topics I hope people feel
free
> >to
> > > > >submit
> > > > > > tips to.
> > > > > >
> > > > > > Redistribution
> > > > > >
> > > > > > ATM
> > > > > >
> > > > > > 3550
> > > > > >
> > > > > > OSPF
> > > > > >
> > > > > > NAT
> > > > > >
> > > > > > HSRP
> > > > > >
> > > > > > F/R
> > > > > >
> > > > > > ISDN
> > > > > >
> > > > > > QOS
> > > > > >
> > > > > > Multicast
> > > > > >
> > > > > > NTP
> > > > > >
> > > > > > Voice
> > > > > >
> > > > > > Eigrp
> > > > > >
> > > > > > Please add your tip under the appropriate heading and send back
to
> >GS.
> > > > > >
> > > > > > Hope this helps lots of people.
> > > > > >
> > > > > > Packet Man
> > > > > >
> > > > > >
This archive was generated by hypermail 2.1.4 : Thu Apr 01 2004 - 08:15:42 GMT-3