Archive for July, 2006
July 31, 2006 @ 8:59 am
· Filed under CCIE Study
Why not…
username cisco password cisco
line vty 0 4 login local privilege level 15
Thank you, Greg Posey Jr. CCIE #7981 CCSP, CCSI M.S. EE
secondie writes:
> I think it is for “no enable password”. > > Here is the brief description: > > “aaa authentication login VTY local” […]
Permalink
July 31, 2006 @ 8:59 am
· Filed under CCIE Study
Hello Elias,
I entered the originate command on R1 because the lab scenario stated that R1 was to be the gateway of last resort.
So are you saying R3 should not use that default route? Is this violating an OSPF rule somewhere?
Permalink
July 31, 2006 @ 7:59 am
· Filed under CCIE Study
I think what you are seeing is normal behaviour. The command is intended to inject a type-7 default into the NSSA. Can I ask why you issued the command on R1 and not on the ABR?
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cr/hirp_r/rte_osph.htm#wp1089033
Rgds Elias
On 7/31/06, CCIEin2006 wrote: > > Thanks Alex - Unfortuantely my rack time is over so I […]
Permalink
July 31, 2006 @ 7:06 am
· Filed under CCIE Study
I believe this is more practical on a ppp link with peer neighbor route, having two different IP addresses in same link.
I believe IE core WB has some good labs on this subject.
Regards
Mohamed T. Kondela Senior Network Engineer IT Dept. Fax: 4473037 x 303 mtaib@sagia.gov.sa Saudi Arabian General Investment Authority
——————————————————– This message contains confidential […]
Permalink
July 31, 2006 @ 7:04 am
· Filed under CCIE Study
crypto map mapname 10 ipsec-manual
By using this command you need to establish (exchange) ISAKMP-PhaseI manually then IPSec-Phase II can start negotiating its parameters.
crypto map mapname 10 ipsec-isakmp
By using this command you will let ISAKMP-PhaseI work properly (negotiating PhaseI policy — exchanging keys by DH — peer authentication) and after successful automatic PhaseI establishment, IPSec-Phase II […]
Permalink
July 31, 2006 @ 7:03 am
· Filed under CCIE Study
One of the keys to the lab is to read ahead and do the correct config the first time round.
Regards Duane —–Original Message—– From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of devecchio Sent: 31 July 2006 12:54 PM To: bdennis@nternetworkexpert.com; bmcgahan@internetworkexpert.com Cc: ccielab@groupstudy.com Subject: FW: LAB 7 Task 5 and 5.7
For the Brians, Others, Please […]
Permalink
July 31, 2006 @ 7:02 am
· Filed under CCIE Study
Thanks Alex - Unfortuantely my rack time is over so I cannot show any outputs.
But what is wrong with having a “connected” route towards the forwarding address? Is that documented somewhere?
On 7/31/06, Alex wrote: > > I wonder if it might be a same problem as with “regular” OSPF default > routes: the […]
Permalink
July 31, 2006 @ 7:01 am
· Filed under CCIE Study
Hi Ismail,
And if you want to lab this: “Create a Frame Relay link between two routers and assign each side two different subnet address (Say R1 150.1.1.1/24 and R2 150.1.2.2/24) and see if you can get RIP going between them.”
On 7/30/06, Plank, Jason wrote: > > “The software ensures that the source […]
Permalink
July 31, 2006 @ 6:59 am
· Filed under CCIE Study
For the Brians, Others, Please chime in….
In task 5, on router 1 the send-community attribute was set for neighbors 163.1.13.3 and 163.1.18.8 (R3/SW2). In the task, it never specified this was necessary…now, granted in task 5.7 the community had to be set due to the requirement of the routes released in the suppress were not […]
Permalink
July 31, 2006 @ 6:02 am
· Filed under CCIE Study
I wonder if it might be a same problem as with “regular” OSPF default routes: the OSPF router must have an internal OSPF route to the forwarding address. That means, if R3 has a “connected” route towards forwarding address of R1-originated default and R3 is configured with “network 0.0.0.0″ statement […]
Permalink
Next entries » ·
« Previous entries