Archive for the ‘350-001’ tag
CCIE R&S Written – Epic WIN!
The wife and I had a romantic day driving several hours to a small town to take Cisco exams. If this doesn’t get me some action, I don’t know what else to try.
I’ve already used the phrases “skin of my teeth” and “a pass is a pass” on Twitter today for good reason. Passing is a score of 790, and I blew that away with a 790. One more lapse in concentration and I would have been making up more excuses instead of smiling. I think I’ve mentioned this before, but I have this weird reaction to taking exams where I don’t get nervous at all until after I’m finished. Walking into the testing center, I was fine. Walking out, I was shaking like Northern Virginia. It was so bad that I could barely hold on to the door knob when trying to leave, so I guess that I’m really prouder than I thought I was.
The exam was a total piece of crap. Nearly every diagram was so compressed and blurry that I couldn’t see them at all. Most of the time I can infer what the diagram is showing, but, when your bridge priorities are listed there, it’s pretty hard to find root ports. Absolutely horrible. There were the inevitable spelling errors in there, too. Most of those are fine, but STP and SPT are two different topics that are both covered on this exam. I had no problems figuring out which one they were talking about, but it’s pretty unacceptable to have spelling errors in this exam. Of course, there were also the questions that I feel are unanswerable. Switches in VTP transparent mode behave differently from version 1 to version 2, eh?
After being recommended at Cisco Live this year, I added the Boson ExSIM-Max to the pile of prep materials. It not only helped teach a few new things, but it cleared up a bunch of foggy details. I’m sure that using any other study materials will do the same to some extent, but the Boson stuff provided something else – it helped to teach me to take the exams. I was able to go through the questions and practice figuring out what was being asked, which choices were completely wrong, and how to not get utterly frustrated with the questions. Practice makes perfect, right?
The wife came with me to take her ICND1 exam. She did better than she thought she would, but, alas, no dice this time. She says that she’s glad she’s been through it now and knows exactly what to study. I’m trying to convince her to start her own blog since she’s starting up her cert journey from such a unique place. We’ll see how that works out.
What’s next? I have to find a company to help me prep for the lab now. I’m sure that’s not cheap at all. Maybe I should just blindly sit the lab and see what happens. Maybe not. :)
CCIE R&S Written – Epic Fail
It’s been a long time, eh? I’ve spent the last month or so with my nose down in a book and my mouse in a Google+ Hangout window studying my rear off for the CCIE R&S Written. Too bad I didn’t pass it.
The exam consisted of 77 questions over a 2 hour window. That’s plenty of time to finish; I think I had 48 minutes left when I was through, so time wasn’t a problem. There were only 2 or 3 questions where I was totally lost, so the technology wasn’t a problem. The big problem, like always, was the usual crap questions that are in these exams. Some didn’t provide all the required information. Some were impractical examples of deployments you would never use in the field. Some were on deprecated technologies. Hell, I had one that involved CatOS. Really? CatOS? Since I only failed by about 2 questions (like I always do), these shenanigans are magnified in my mind. It really irks me how these exams are being done; foggy questions don’t really measure ability.
I did have one great advantage last week that I’ve never had – I took the exam at Cisco Live and had 489247248 CCIEs around me willing to help. Since I took the exam on Sunday, I was able to ask people face-to-face for advise on what I need to do to pass, and the consensus was that I needed to practice how to answer questions the way Cisco wants you to answer them since the material wasn’t really that hard. The suggested next steps ran the gamut, too. Some suggested just firing from the hip for answers – the whole “your first guess is always right” theory. Others suggested that I just brute force the exam. Still others even suggested brain dumps along with the idea that we’ve all put in our time and effort already and that the terrible questions shouldn’t be what’s holding us back.
You guys know me by now. I’m definitely not going to give up or anything stupid like that. I’ll probably take a week off to recover from Cisco Live and then head back to the studies. I’ll do the usual brute force method, but I’m going to grab a copy of the Boson exams (which were also suggested) to supplement. I would guess that I’ll try again around the first of August, but we’ll see.
Send any beatin’ sticks questions my way.
Frame Relay Notes – DE, FECN, and BECN
- All are part of the frame relay congestion management suite.
- Frame relay switches monitor links for CIR or oversubscription congestion on links.
- If the VC has a CIR of 256k, the switch knows there is congestion if the customer is sending more than 256k down that VC.
- Discard Eligible
-
- Flag in the LAPF header
- Marks a frame as eligible to be dropped in case of congestion
- Marked via the MQC
- Forward Explicit Congestion Notification
- Flag in the LAPF header
- Set by the switch when the frame is about to enter a link with congestion on a VC
- Congestion in one direction
- FECNs are set when the frame is going into the congestion.
- Receiving router can see that there was congestion on the way.
- FECNs can be used to activate adaptive shaping via FRTS.
- Plain English: If Router B receives a frame with the FECN flag set, that means that there is congestion on the path from Router A to this Router B, and that Router B should expect delays.
- Backward Explicit Congestion Notification
- Flag in the LAPF header
- Set by the switch when a frame has just left the link with congestion
- Congestion is the opposite direction.
- BECNs are set when the frame has just left a link that has congestion on it.
- Notifies the original sending router that there is congestion along that VC.
- Plain English: If Router A receives a frame with the BECN flag set, that means that there is congestion from Router A towards Router B and that the sending host should calm down a little bit.
http://www.sinclair.org.au/keith/networking/frame_relay.html
–
Corrections requested.
Frame Relay Notes – LMI, Headers, and Encapsulation
- Manages link between the router and frame relay switch
- Routers send Status Enquiry to the switch
- The switch responds with a Status message informing the router of the DLCIs available
- Serves as a keepalive
- Default keepalive is 10 seconds, 3 misses is failed
- Three types
- cisco <- default
- ansi (Annex D)
- q933a
R1(config)#interface s1/0 R1(config-if)#frame-relay lmi-type ansi
- Link Access Procedure for Frame-mode Bearer Services (LAPF) is the first header
- Includes DLCI, DE, FECN, BECN
- To be read by the frame relay switch
- Frame relay encapsulation header is next
- To be read by the router on the other end of the VC
- Two types
- cisco : proprietary <- default
- ietf : IETF RFC 2427
R1(config)#interface s1/0 R1(config-if)#frame-relay encapsulation ietf <- for all DLCIs - or - R1(config-if)#frame-relay interface-dlci 100 ietf <- for specific DLCIs - or - R1(config-if)#frame-relay map ip 10.0.0.1 ietf <- for specific DLCis
PPP Notes – LFI
- Link Fragmentation and Interleaving
- A QoS tool to prevent smaller, higher-priority packets from waiting on larger packets to transmit
- For example, VoIP packets and FTP packets
- Fragments the larger packets and interleaves them with the smaller packets
- Only available in PPP with Multilink
- Can be a multilink bundle with a single link in it
- Common to use with LLQ to interleave the delay-sensitive packets
- fragment-delay allows you to change the fragment size
- In milliseconds
- size = fragment-delay * bandwidth of interface
R1(config)#interface Multilink 1 R1(config-if)#bandwidth 512 R1(config-if)#ppp multilink interleave R1(config-if)#ppp multilink delay 10
–
Corrections, please.
Redistribution Notes – AD Manipulation
- Manipulating administrative distance (AD) is another way to help with a mutual redistribution scenario.
- EIGRPs has different ADs for internal and external (redistributed) routes
- OSPF and RIP have the same AD no matter where the route orginated.
- This means that routes redistributed into OSPF may be used instead of a local RIP route.
- AD 110 (OSPF) beats 120 (RIP) every time.
- The distance subcommand allows you to change the AD on specific routes from specific neighbors.
- This example changes the AD of the route to 10.0.0.0/16 advertised from 1.1.1.1 to 121.
- This will make this router prefer a RIP route to the same destination.
ip access-list standard RIP-ROUTES permit 10.0.0.0 0.255.255.0 ! router ospf 1 distance 121 1.1.1.1 0.0.0.0 RIP-ROUTES
–
Corrections are encouraged.
Redistribution Notes – Tagging
- Tagging provides a way to mark common or similar routes to manipulate later.
- In redistribution scenarios with mutual redistribution on two different routers, any routes that gets redistributed from one route process to another are tagged.
- When the other router sees those tags on the route, that route to keep from adding non-optimal routes to its routing table.
- Tags can also be used to do other manipulation such as setting higher metrics or changing ADs.
OSPF
R102#show run ... router ospf 1 log-adjacency-changes redistribute connected subnets route-map SETTAG network 192.0.2.0 0.0.0.255 area 0 ! route-map SETTAG permit 100 set tag 55555 ... R101#sh ip route 10.0.0.2 Routing entry for 10.0.0.0/24 Known via "ospf 1", distance 110, metric 20 Tag 55555, type extern 2, forward metric 10 Last update from 192.0.2.102 on Ethernet0/0, 00:00:13 ago Routing Descriptor Blocks: * 192.0.2.102, from 192.0.2.102, 00:00:13 ago, via Ethernet0/0 Route metric is 20, traffic share count is 1 Route tag 55555
EIGRP
R102#sh run
...
router eigrp 1
network 192.0.2.0
redistribute connected route-map SETTAG
no auto-summary
!
route-map SETTAG permit 100
set tag 55555
...
R101#sh ip route 10.0.0.2
Routing entry for 10.0.0.0/24
Known via "eigrp 1", distance 170, metric 409600
Tag 55555, type external
Redistributing via eigrp 1
Last update from 192.0.2.102 on Ethernet0/0, 00:00:14 ago
Routing Descriptor Blocks:
* 192.0.2.102, from 192.0.2.102, 00:00:14 ago, via Ethernet0/0
Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
Route tag 55555
–
Corrections are encouraged.
CCIE R&S Written Materials
I’m scheduled to take the CCIE R&S Written exam on 10 July at Cisco Live, and I’ve been asked by a handful of people on Twitter exactly what materials I’m using. I figured it would be a good idea to let everyone know so that we all can determine whether or not I’m on the right track. I may get to the exam and find out that the books I’ve been reading aren’t even close. It’s happened before.
CCNP Routing and Switch Quick Reference, 2nd Edition : This doesn’t have the required details, but I read it to get the rust off the more-basic topics. A good read-through at lunch does wonders for the memory.
CCIE Routing and Switching Certification Guide, 4th Edition : I’m using this book as the cornerstone of my studies, and my study schedule is based off of the topics in here. I’m not expecting all the details to be in this book, but it seems to be going along with the blueprint pretty well. We shall see, shan’t we?
Routing TCP/IP Volume I, 2nd Edition, Routing TCP/IP Volume 2 : I’m not reading the Doyle Bibles cover-to-cover; instead, I’m using them for cross reference. If I’m reading anything that makes no sense or that is worded awkwardly, I just read that section of the Doyle Bible to clear it up. It’s been working great so far.
RFCs : Any RFC mentioned in the text goes into my pile of reading materials. A lot of these are fairly short, but some of them are a huge struggle to work through. I would find it hard to believe if you told me you enjoyed RFC 2328.
Obviously, I hope this will be enough to get me through the exam. We’ll know in less than a month, won’t we? This would put me halfway through my goals for the year with many months to spare…months I’ll need for a lab attempt.
Send $1400 any questions my way.
BGP Notes – Synchronization
- With synchronization on, route must be synchronized to an IGP in order for that routes to be able to be voted ‘best” by BGP.
- That means the exact route must already be in the routing table via an IGP.
- Static routes don’t count.
- This is traditionally accomplished by redistributing BGP routes into an IGP.
- With today’s Internet prefix count over 350k, this may not be such a good idea in some situations.
- Synchronization is off by default.
- Synchronization prevents black hole routes from being advertised via iBGP.
- Unless every router is participating in iBGP, there’s no guarantee that any one router will have a route to NEXT_HOP.
- Synchronization also prevents a router from advertising the black hole to an eBGP neighbor.
- You don’t want to tell the world you have a path to a prefix when you really have a !N.
- Synchronization can be safely disabled with the use of route reflectors or confederations.
—–
These are just some notes I’ve been taking. Comment with corrections, please.
BGP Notes – Backdoor Routes
- The fact that eBGP has an AD of 20 can be a problem.
- You may have a very short path via EIGRP (or OSPF or RIP or whatever other IGP), but the longer eBGP path will be preferred.
- For God’s sake, do not lower the AD of EIGRP! Havoc will ensue.
- Using backdoor routes causes eBGP routes to have an AD of 200.
- Allows the shorter-path IGP routes to be added to the routing table.
router bgp 123 network 1.1.1.0 backdoor
—–
Comment with corrections, please