From: Art Davis (senzaart@xxxxxxx)
Date: Thu Aug 31 2000 - 12:51:25 GMT-3
"Logg sync" will force a <carriage return> after the router spits some output
at you. No more typing in the middle of the line! You can leave "logg con" on
so you can see your interfaces and your pvc's coming online.
Art
Sam Munzani <sam@chinet.com> wrote:
Thanks a lot Tony,
It definately helps. I will add that in my list of commnad to blast on
each router.
BTW, One of the CCIE I know for a while had recommended me to use
following command on each router during lab.
line con 0
logging synchronous
He said that command will help a ton during lab. I was unable to
understand exactly what is the effect of that command. What is difference
between sync and async logging? If you know and can explain please help.
Thanks in advance ,
Sam
On Wed, 30 Aug 2000, Tony Medeiros wrote:
> I used these alias commands on every practice lab I do. The short cuts
> became second nature after a while. I paste them into every router along
> with the usuals like "ip subnet-zero" etc
>
> alias exec s sho run
> alias exec c conf t
> alias exec i sho ip route
> alias exec x sho ipx route
> alias exec a sho apple route
> alias exec ib sho ip inter brief
> alias exec xb sho ipx inter brief
> alias exec ab sho apple inter brief
> alias exec az sho apple zone
> alias exec xs sho ipx servers
> alias exec b sho ip bgp
> alias exec bn sho ip bgp nei
>
> Whats nice too is on newer versions of code (12.0 and up I think) you can
> do a "s inter f1/0" which is equal to "sho running config interface fast
> 1/0" and get just that part of the config instead of the whole thing.
Saves
> time and wear and tear on the space bar!!
>
> Hope this helps.
> Tony Medeiros
> CCIE 6172 for one day now
>
>
> ----- Original Message -----
> From: "Sam Munzani" <sam@chinet.com>
> To: "Kevin Baumgartner" <kbaumgar@cisco.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Wednesday, August 30, 2000 3:25 PM
> Subject: Re: Inverse ARP and Subinterfaces
>
>
> > I Agree with you.
> >
> > Somebody posted here yesterday that he used a lot of alias commands to
> > save typings.
> >
> > Can you share some of those with group please? I would like to avoid as
> > much typing as I can becuse of my fat finguring habbits.
> >
> > Thanks in advance,
> >
> > Sam
> >
> > On Wed, 30 Aug 2000, Kevin Baumgartner wrote:
> >
> > > Sure more typing but it avoids a lot of frustration in the lab with
> > > trying to get Framerelay connections up and going.
> > >
> > > Maybe not the recommended way of doing it in the real world but I
> > > would recommend using only frame-maps in the lab.
> > >
> > > But it's only a sugestion and that's what I am going to do in the lab.
> > > The first time I took the test I ran into a lot of problems getting
> > > inverse-arp to work. And the Framerelay part of the test is not much
> points
> > > anyways.
> > >
> > > I would rather spend my time on the rest of the test where the points
> > > are and not try to figure out inverse-arp.
> > >
> > > - Kevin
> > >
> > > >
> > > > On HUB router using Multipoint why not? Since it will learn remote
> > > > networks by Inverse-ARP there would be no need to have Frame-relay
> > > > maps. This saves a lot of typing time if you have many spokes with
IP,
> > > > IPX, Apple, Dec and god knows what other protocols they may ask for.
> > > >
> > > > Without using Inverse-ARP you will end up having 10-12 map
statements.
> > > >
> > > > For spokes,
> > > > I am strongly in favor of using Static maps.
> > > >
> > > > Sam
> > > >
> > > > On Wed, 30 Aug 2000, Alan Simpkins wrote:
> > > >
> > > > > Having taken the lab 3 times now, and being scheduled
> > > > > for #4, I would recommend against using inverse-arp,
> > > > > except where required if at all.
> > > > >
> > > > > --- Shaun Nicholson <Shaun.Nicholson@kp.org> wrote:
> > > > > > Another issue with inverse arp what if you have a
> > > > > > fully meshed frame relay network but you are not
> > > > > > allowed to use all of the PVC's.
> > > > > > Inverse arp will use the all the DLCI's available
> > > > > > and you could end up using a PVC you are not allowed
> > > > > > too and not be awair of what you've done.
> > > > > > Think about it in the pressure of the lab
> > > > > > environment you see its up and you can ping so you
> > > > > > dont bother doing a sh frame map or sh frame pvc and
> > > > > > you've lost points without realizing it.
> > > > > > Map statements mean you avoid using the PVC you are
> > > > > > not allowed to use.
> > > > > >
> > > > > > I agree with the Frame-relay map, frame-relay map,
> > > > > > frame-relay map ...... statement.
> > > > > >
> > > > > > Way too many issues with the inverse arp in the lab.
> > > > > >
> > > > > > Shaun
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > kbaumgar@cisco.com on 08/29/2000 11:55:00 PM
> > > > > > To: masalmon@cisco.com@Internet
> > > > > > cc: ccielab@groupstudy.com@Internet (bcc: Shaun
> > > > > > Nicholson/MD/KAIPERM)
> > > > > > Subject: Re: Inverse ARP and Subinterfaces
> > > > > >
> > > > > > My recommendation is to not depending on inverse
> > > > > > arp when doing
> > > >
> > > > > > the lab. It can be something problematic to get
> > > > > > things working and
> > > > > > you can waste a lot of time trying to get things to
> > > > > > work.
> > > > > >
> > > > > > I know of someone that spend 1/2 of the first day
> > > > > > just trying to
> > > > > > get framerelay working and pinging between routers.
> > > > > > And didn't even
> > > > > > get to finish most of the questions because of this.
> > > > > >
> > > > > > The recommend I heard from some which I agree with
> > > > > > is
> > > > > > Frame-relay map, frame-relay map, frame-relay map
> > > > > > ...
> > > > > >
> > > > > > - Kevin
> > > > > >
> > > > > > >
> > > > > > > No can do you are using map statements. My
> > > > > > contention is to use inverse
> > > > > > > arp. I realize that you can use map statements to
> > > > > > achieve
> > > > > > > reachability. I wish ot use inverse arps on the
> > > > > > hub router.
> > > > > > >
> > > > > > > Simon Baxter wrote:
> > > > > > > >
> > > > > > > > Yip, just added it just for you!!
> > > > > > > >
> > > > > > > > interface Serial0
> > > > > > > > ip address 192.1.1.2 255.255.255.0
> > > > > > > > encapsulation frame-relay
> > > > > > > > no ip mroute-cache
> > > > > > > > ip policy route-map policy
> > > > > > > > frame-relay traffic-shaping
> > > > > > > > frame-relay priority-dlci-group 1 100 200 300
> > > > > > 400
> > > > > > > > frame-relay map bridge 400 broadcast
> > > > > > > > frame-relay map ip 192.1.1.1 100 broadcast
> > > > > > > > frame-relay map ipx A.0000.0c01.1235 300
> > > > > > broadcast
> > > > > > > > frame-relay map appletalk 300.1 200 broadcast
> > > > > > > > no frame-relay inverse-arp
> > > > > > > > frame-relay qos-autosense
> > > > > > > > !
> > > > > > >
> > > > > > > > interface Serial0.2 multipoint
> > > > > > > > ip address 202.1.1.2 255.255.255.0
> > > > > > > > cdp enable
> > > > > > > > frame-relay interface-dlci 500
> > > > > > > > !
> > > > > > > >
> > > > > > > > RTRB#
> > > > > > > > RTRB#show frame map
> > > > > > > > Serial0 (up): bridge dlci 400(0x190,0x6400),
> > > > > > static,
> > > > > > > > broadcast,
> > > > > > > > CISCO, status defined, active
> > > > > > > > Serial0 (up): ip 192.1.1.1 dlci
> > > > > > 100(0x64,0x1840), static,
> > > > > > > > broadcast,
> > > > > > > > CISCO, status defined, active
> > > > > > > > Priority DLCI Group 1, DLCI 100 (HIGH), DLCI
> > > > > > 200 (MEDIUM)
> > > > > > > > DLCI 300 (NORMAL), DLCI 400 (LOW)
> > > > > > > > Serial0.2 (up): ip 202.1.1.1 dlci
> > > > > > 500(0x1F4,0x7C40), dynamic,
> > > > > > > > broadcast,, status defined, active
> > > > > > > > Serial0 (up): ipx A.0000.0c01.1235 dlci
> > > > > > 300(0x12C,0x48C0), static,
> > > > > > > > broadcast,
> > > > > > > > CISCO, status defined, active
> > > > > > > > Serial0 (up): appletalk 300.1 dlci
> > > > > > 200(0xC8,0x3080), static,
> > > > > > > > broadcast,
> > > > > > > > CISCO, status defined, active
> > > > > > > > RTRB#ping 202.1.1.1
> > > > > > > >
> > > > > > > > Type escape sequence to abort.
> > > > > > > > Sending 5, 100-byte ICMP Echos to 202.1.1.1,
> > > > > > timeout is 2 seconds:
> > > > > > > > !!!!!
> > > > > > > > Success rate is 100 percent (5/5), round-trip
> > > > > > min/avg/max = 56/59/60 ms
> > > > > > > > RTRB#
> > > > > > > >
> > > > > > > > as you'll see, everything else apart from s0.2
> > > > > > is static and no inverse
> > > > > > > > arped...
> > > > > > > >
> > > > > > > > Simon
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: mark salmon [mailto:masalmon@cisco.com]
> > > > > > > > Sent: Wednesday, August 30, 2000 2:31 PM
> > > > > > > > To: ccielab@groupstudy.com
> > > > > > > > Subject: Inverse ARP and Subinterfaces
> > > > > > > >
> > > > > > > > HAs anyone been able to get inverse arp to work
> > > > > > with frame relay
> > > > > > > > multipoint subinterfaces? According to Caslow,
> > > > > > multipoint subinterfaces
> > > > > > > > do inverse arp by default. I have not been able
> > > > > > to set it up that way
> > > > > > > > in a hub and spoke environment (both sides
> > > > > > multipoint subinterfaces).
> > > > > > > >
> > > > > > > > Any ideas?
> > > > > > > > --
> > > > > > > >
> > > > > > > > Mark Salmon
> > > > > > > > Project Engineer
> > > > > > > > Cisco Professional Services
> > > > > > > > Phone:773-695-8235
> > > > > > > > Pager:800-365-4578
> > > > > > > > email: masalmon@cisco.com
> > > > > > > >
> > > > > > > >
> > > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:33 GMT-3