INE Vol 1 - Lab 16 - Multihop MP-eBGP for VPNv4 Exchange

Finally finished this lab, but experienced and oddity...

I saw the routes in the CE routers for the remote CE but wasn't able to ping. I even sourced my pings from a loopback that was being advertised in the CE-PE routing protocol. Weird.

Other than that, this was an interesting one, the 2 routers that join the 2 BGP ASes, were configured as eBGP peers and configured to send-label. Then the the eBGP VPNv4 relationship was farther spread apart, it was actually a peering of the PE to PE across 2 BGP ASes.

All in all, a good lab, but I'm troubled by why I can't seem to ping from CE to CE in either VRF.

On to the next one.

UPDATE------------ Issue resolved.
The problem was something so silly, I didn't have MPLS IP configured on R4, R5, and R6 in my ISIS domain. A good lesson, if your control plane looks good (ie your routing table) then the problem has to be in your forwarding plane. Thanks to Vignesh for his help.

INE Vol 1 - Lab 15 - finished - MP-BGP for Inter VRF

So it's taken awhile to finish this lab, mostly due to the my new role at work. I'm supporting production networks and troubleshooting issues and while it's interesting to some degree, it does take away from studying.

Anyhow, this lab was the same setup as the last one, back to back VRFs, but uses MP-BGP to leak routes between BGP domains. The thing to note on this lab is BGP automatically filters route-targets that it doesn't need to know of (meaning it doesn't have a link configured for). So in order to exchange VPN routes it needs to stop this filtering by...
'no bgp default route-target filter' under the BGP process. That way, it can know the VRF routes and leak them between it's MP-eBGP peer of the other network.

I'm afraid my progress will continue to slow, I hope once things settle down I'll be able to return more aggressively to my studies.

INE Vol 1 - Lab 14 - finished - Back to Back VRF

Pretty straight forward lab on using 2 routers and a single Fast Ethernet interface, dot1q trunked or "router on a stick", to exchange VRF information for 2 ASes to interconnect CEs. Yeah, that's a long sentence. So the 2 CE's span 2 different BGP ASes, and the 2 BGP ASes meet at a single point where the 2 routers share a dot1q FE trunk. The sub interfaces of the FE are configured like CE connections, meaning that the links are configured for a specific vrf on both routers. Then there are 2 BGP peering sessions for each VRF in the IPv4 table. RDs for the VRFs are the same even if the BGP Peering isn't direct.

The BGP peering point just looks like a connection to another CE on each AS.

Good lab, have a feeling a similar configuration is done for VRF-Lite and I'll see it when I do that lab.

INE Vol 1 - Lab 13 - finished - VPNv4 Route Reflection

This lab was interesting. Basically, the lab asks you to use a router (R2) to be VPNv4 route reflector for 3 BGP clients R3, R4, and R6. The 3 clients (or PEs) have a MPLS VPN configured but the route-reflector doesn't. I'm going to liken R2 as a P-core router.

This lab also demonstrates another router, R1, to be the IPv4 route-reflector for it's BGP peers. R1 is the route-reflector for R2 through R6. R1 is also eBGP peered with BB3 and is receiving routes. This portion demonstrates how ipv4 bgp routes are unaffected by VPNv4 BGP routes and vice versa.

This one would be good to go back to, to keep VPNv4 and IPv4 BGP straight.

INE Vol 1 - Lab 12 - finished - OSPF Domain-ID.

In this lab we were asked to peer with the PE routers from 4 remote CE sites using different OSPF AS numbers. The 4 routers were put into 2 VPNs (as most of these labs require). Using different RDs and importing and exporting different RTs, only the members of a vpn were able to talk to each other.

The part that this lab tests you on is OSPF Domain-ID. Using the same domain-id for OSPF on the PEs for the CE members in the same VPN allows the OSPF routes on the CEs to look like inter-area (ia) routes instead of external (e2) routes. This means that over mpls cloud, the 2 sites are looking like they're separated by an area-boarder router when in actuality they're still mutually redistributed into BGP.

On to the next lab.

INE Vol 1 - Lab 11 - finished - OSPF Sham Link.

The gist of this lab was when using OSPF to interconnect 2 remote sites to 2 PEs and they have a back door link to each other (ie a private line) then because the routers are in the same area 0, routes within an area are preferred over routes that are INTER area and OSPF has a lower AD then iBGP. To get around this, between the two PEs you can create an ospf sham-link and then change the cost of the backdoor link to be worse.

config:

Router1(config-if)# area 1 sham-link 10.2.1.1 10.2.1.2 cost 40

verify:

show ip ospf sham-links

INE Vol 1 - Lab 10 - finished - BGP SOO.

This lab was interesting in that there is a "gotcha".

The CE's in 2 different locations are using the SAME BGP AS number (AS 100) so inherently they won't exchange routes due to the loop prevention mech. That being said, using AS-OVERIDE on the neighboring CEs will replace any AS number (AS 100) that is the same with the PE AS number (AS 1), thus allowing connectivity.

The purpose of BGP SOO, which is a BGP extended community attribute, is to provide a loop prevention mechanism. A route-map applied on the PE to 2 CE neighbors "tags" the prefixes learned with a SOO. When tagging to 2 CEs off the same PE, the effect is that the PE won't advertise a learned route with the same SOO to another CE, effectively preventing a loop. An assumption is that the 2 CE's have a backdoor connection between themselves.

1 Thing to note, the solution guide config for SW1 doesn't have a bgp neigh peer statement for SW2, iBGP. But SW2 has a neighbor statement for SW1. (since one side is missing they are not iBGP peering)

On to the next one.

INE Vol 1 - Lab 9 - finished - Export Maps.

This one was pretty straight forward as well...

Use an export map to gain connectivity to ONLY certain subnet in a different VRF, similar to a Extranets and subsequently Common Services VRF but more restrictive (granular). The VRF offering the different subnets still needs to import the rt's from all the other VRFs for connectivity back. Using an Export map (route-map), you set the extended community to designate an rt associated with the matching subnet.

I THINK I'm getting a better handle on VRFs as I go through these labs, I hope I can keep it up.

On to the next one.

INE Vol 1 - Lab 8 - finished - Extranet.

Building off the concept of Central Services, you can use an Extranet to "leak" vrf/routes between two or more VRFs.

Since you can't establish more then 1 Route Distinguisher, you can use an "artificial" rd by route-target export/import and use the "artificial rds.

On to the next one...

INE Vol 1 - Lab 7 - finished - Central Services.

Finished this lab with no issues.

Basically using importing and exporting of RD's for certain VRFs to limit communications between different sites/vrfs.

On to the next one.

INE Vol 1 - Lab 6 - finished - EBGP.

Pretty straight forward, no redistribution necessary since it's bgp.

The one thing I wanted to verify was the eBGP routes on a PE. Something like "show ip bgp ipv4 vrf ... " but there's no command to do that.

Is that right?

On to the next one.

INE Vol 1 - Lab 5 - finished - EIGRP as CE-PE IGP.

I figured I'd just remove the CE-PE IGP from the last lab instead of recreating the whole topology from scratch. This time it was EIGRP.

Things to keep in mind, EIGRP is like BGP in that it uses address-families, within the address families you need to make sure you specify and antonymous-system to match the CE instance. Redistributing EIGRP into BGP use the configure AS and the rest is pretty much the same.

Trekking along on this rainy Friday.

INE Vol 1 - lab 4 -finished

Pretty straight forward and inline with the previous labs... This is one was on OSFP as the CE-PE routing protocol.

Same gotchas, redistribute connected interfaces if you aren't souring your pings from loopbacks (that are already advertised in the CE-PE protocol)

This time around I checked for routes BEFORE I activated the PE-PE iBGP peering in vpnv4... duh, of course the routes won't get propagated.

On to the next lab.

INE Vol 1- Lab 3 - MPLS VPNs with OSPF.

So far so good, breezing through these, but to be fair not much is required for these particular labs. The CE-PE routing protocol is the only difference but the concept is the same, redistribute both ways IGP to BGP and vice versa and use address families where applicable...

Starting this one now, hope to finish it in a couple hours.

INE Vol1 - Lab 2 - MPLS VPNs with Static Routing.

The second time (and seeing how I finished IPX vol 1) is much easier. But still I mess up on little but important things...

- bgp next-hop-self, you obviously need this if the remote ibgp peer isn't reachable via an IGP. Otherwise, how is the traffic supposed to get routed to a hop that it doesn't know of.

- and when redistributing the static vrf route into BGP VPNv4 table, when you want to verify via Pings, you need to redistribute connected interface too because they are the source of your pings unless you source your pings from the loopback. Because if you don't redistribute connected interfaces, the vrf's are not aware of how to get back to the source of your pings.

Grrr... small, but vital things that slipped my mind.

Noted and on to the next lab.

INE Vol 1 - lab 1 - finished

Redoing this workbook after doing IPX vol1. So it should be pretty easy now, finished lab 1 which covered basic MPLS and on to Lab 2 - MPLS VPNs with static routes.

I think the way this workbook is layed out is actually only 2 Main topics, MPLS and Multicast. I wonder how they address other things for instance IGPs or security?

Lab 25 - Advanced Routing completed.

When I saw Advanced Routing, I expected things like redistribution and announcing default routes and such... but really the only parts that I had trouble with was the ISIS section. Things like specifying a DR or using a frame-relay map for CLNS. Even ISIS authentication wasn't bad.

Well, vol 1 is officially complete.

I guess I'm off to look at some CoDs and start INE Vol1 (over again). I figure IPX Vol 2 consists of FULL Mock Labs and I think I should hold off on those until I do INE Vol1 and IPX Vol1 (for a second time).

I feel one step closer.

Sanity Check - done with Lab 24.

Looking back it took me 2 and 1/2 months to finish IPX Vol1 and for some reason, I feel like it took WAY too long to get through 1 workbook. I guess my motivation had really been what's been lacking and yeah, I had some other personal things going on as well. I hope I figure out how to manage it all and manage it better. But I think it all starts with motivation and taking those critical baby steps...

Lab 24 - Multicast VPN

Almost done... All but the last 3 tasks were to setup the environment (which is great review) but not related to Multicast, specifically Multicast VPNs.

I think the best review for Multicast, seeing as I don't ever do it in real life, is to go back and study my materials for R&S. Atleast that way, when I'm thinking in terms of SP, I can kind of get an idea of what a task is asking.

Some things I learned in this lab:

- ip multicast-r vrf VPNX

- ip vrf VPNX

- mdt default a.b.c.d

- ip pim vrf VPNX rp-add x.y.w.z

- show ip pim vrf VPNX nei

- show ip pim mdt bgp

Lab 23 - Traffic Policing completed.

Finished Lab 23 - Traffic Policing, no major issues with this one.

Moving on...

Lab 22 - Traffic Classification completed.

Nothing too heavy in this lab either.

Just a couple notes:

- "ip local policy route-map XXX" for PBR and "ip policy route-map XXX" for PBR on an interface

- you can use a Route-map, Rate-limit to mark traffic and of course you can use MQC, ie, class-maps and policy-maps to mark traffic

Lab 21 - Congestion Avoidance completed.

Just a couple things to remember...

- random-detect can be directly configured on an interface OR you can use CBWFQ to be more precise and drop traffic for specific traffic.

- the policy-map for CBWFQ can only be applied as OUTPUT on an interface.

On to the next lab!

Lab 20 - CAR completed.

One of the tasks asked to rate-limit traffic sourcing from a specific MAC address.

Is there a difference between:

(a) access-list rate-limit 101 xx:xx:xx:xx

and

(b) access-list 700 permit xx:xx:xx:xx

?

I looked it up on Cisco.com

(a) and (b)

Lab 19 - Carrier Supporting Carrier

Finished Lab 19 with no major hiccups. The one thing that I keep forgetting is under EIGRP, under the specific VPN, I need to designate the Autonomous System which is different from the Global EIGRP process.

The configuration of this lab went pretty well, I think I do need to read up on where this is used in the real world. My guess, when a carrier leverages another carriers MPLS footprint.

On to lab 20!

Lab 18 - question about BGP Send-Label.

First off thanks to Zayphyoe and Vignesh for helping me with the post just below this one.

And I'm all for Zayphyoe's suggestion of teaming up to study together, that includes anyone who's studying for CCIE SP.

My issue now is, I have everything working for the most pa

rt minus using BGP Send-Label to send MPLS labels across two BGP ASes.

See Diagram Below (or click link to maximize).

- R1 and R9 are BGP route reflectors for their ASes

- R1 and R9 are ebgp peered

When I enable bgp send-label, the R1 to R9 peering breaks and goes only into an Active BGP state and then I don't get my VPNA (which is R4 to R2 connection) on R7 and vice versa.

I don't know what it is about bgp send-label that's breaking this connection in the VPNv4 table, any thoughts?

Lab 18... issues... twice.

I did lab 18, twice and ended up with the same problem. The first time I did it, I did it on my own. The second time, I followed the Proctor Guide.

Task 18.9 - I'm supposed to configure MP-eBGP between two ASes and then use BGP to send-labels. I configured it, just the same as the proctor guide but I can't get my the eBGP peer routers to see the VPNV4 bgp prefixes advertised in their respective ASes.

So if R2, R1 and R5 are in AS 125 and R5 eBGP peers with R6 in AS 689 (with routers R8 and R9 in AS689), and R2 is peering with a CE, receiving VPNV4 routes after redistribution and R1 is seeing it and advertising to R5, why isn't R5 able to see the VPNV4 routes in its own AS? Plus why can't I configure BGP soft-reconfiguration inbound in address-family vpnv4... I want to see what routes are being received by R5's VPNV4...

For those interested here's R5's config:

!

router ospf 1

log-adjacency-changes

network 150.50.15.5 0.0.0.0 area 0

network 200.0.0.5 0.0.0.0 area 0

!

router bgp 125

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 150.50.56.2 remote-as 689

neighbor 200.0.0.1 remote-as 125

neighbor 200.0.0.1 update-source Loopback0

!

address-family ipv4

neighbor 150.50.56.2 activate

neighbor 150.50.56.2 send-label

neighbor 200.0.0.1 activate

neighbor 200.0.0.1 next-hop-self

neighbor 200.0.0.1 send-label

no auto-summary

no synchronization

exit-address-family

!

address-family vpnv4

neighbor 200.0.0.1 activate

neighbor 200.0.0.1 send-community extended

exit-address-family

!

R5#sh ip bgp vpnv4 all s

BGP router identifier 200.0.0.5, local AS number 125

BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

200.0.0.1 4 125 261 224 1 0 0 00:39:35 0

R5#

******************R1*****************************

R1#sh ip bgp vpnv4 all neighbors 200.0.0.5 advertised-routes

BGP table version is 29, local router ID is 200.0.0.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 125:100

*>i150.50.24.0/30 200.0.0.2 0 100 0 ?

*>i200.0.0.4/32 200.0.0.2 1 100 0 ?

Total number of prefixes 2

R1#sh ip bgp vpnv4 all s

BGP router identifier 200.0.0.1, local AS number 125

BGP table version is 29, main routing table version 29

2 network entries using 312 bytes of memory

2 path entries using 136 bytes of memory

6/2 BGP path/bestpath attribute entries using 888 bytes of memory

1 BGP AS-PATH entries using 24 bytes of memory

1 BGP extended community entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

Bitfield cache entries: current 1 (at peak 4) using 32 bytes of memory

BGP using 1416 total bytes of memory

BGP activity 12/6 prefixes, 26/20 paths, scan interval 15 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

200.0.0.2 4 125 233 257 29 0 0 00:53:21 2

200.0.0.5 4 125 229 266 29 0 0 00:44:51 0

200.0.0.9 4 689 17 17 0 0 0 00:50:58 Active

R1#

**********************************************************

R1 showing it received VPNV4 routes from R2 and advertising it to R5 (R1 is a RR).

Lab 17 - MPLS VPN done... on to the next one.

Lab 17 - quick and easy, down and dirty. Pretty straight forward and re-emphasizing the basics of configuring VRFs and route-targets, one little tricky thing was the use of the same AS number for BGP CE to PE peering. The solution accomplished it one way on the CE but I was also looking to do it on the PE as well... ie use as-override... wonder why they didn't use AS-OVERRIDE on the PE?

On to the next lab, Lab 18 - Inter-AS MPLS VPN

Lab 16 - MPBGP done.

Lab 16 is done. Wasn't really that difficult but was a really good refresher to keeping BGP address families straight. IPv4 vs VPNv4 and using vrf export maps to change route-targets. It helped refresh my memory on how the MPLS VPNs work :) The other big plus was using some vrf specific verification commands like ping vrf XXX a.b.c.d source w.x.y.z and sh ip bgp...

On to Lab 17!

Finished lab 14 - HSRP/VRRP, Skip 15, onto 16 - MP-BGP

Finished Lab 14 - HSRP/VRRP, pretty basic and easy, nothing challenging.

I have to skip 15 which is L2 VPN which requires some switch configurations and I don't have my rack up and running...

Moving on to Lab 16 - MP-BGP :)

I feel like I'm picking up some pace and now that the WB is half over or so, I feel a bit more motivated to finish it up.

Finished lab 13 - QoS

Finished the QoS lab and thought it was great refresher to R&S QoS. There's nothing that tied it in with MPLS so it really was a refresher.

So other then QoS, Security, and some Services like HSRP/VRRP, (and the obvious IGPs) what else is a freebie for those who studied R&S...

Chapter 9 IPv6 and Lab 12 Security

Re-reading chapter 9 - IPv6 and it's a good review of what I learned from studying R&S. Lab 12 Security obviously doesn't correlate to IPv6 :)

I think now that summer's ending, I'm going to be more motivated to study... hopefully :)

Finished lab 11 and chapter 8

I beginning to like my new method of reading the pertinent chapter first and then doing the lab, for me it's really working well to reinforce my understanding. Chapter 8 is a long one and covers a lot of ground but is imperative to understanding TE. Lab 11 is good and could have been better I think if the explanations were more thorough and the lab itself covered more ground.

On to lab 12 - security... now to find the corresponding chapter :)

Finished 1-9, on 10... for the second time.

I decided to redo the first 10 labs of IPX vol1 and I'm glad I did, I think I gained a firmer understanding of what the labs were about and coupled with the labs, I re-read MPLS Fundamentals.... not the whole thing but certain chapters.

I figure I'll finish up lab 10, re-read RSVP and TE and then do lab 11.

Someone in the blogosphere had mentioned a CiscoPress book for MPLS/Service Provider that dealt with configurations... anyone recall what that book is? I'm thinking I would like to see some more configs.

Finally finished Lab 10...

Finished Lab 10, Multicast, and since I haven't been as consistent with studying for SP as I had been for RS, I'm going back to do the first 10 labs again. I hope this solidifies my learning and builds some confidence.

Lab 8 and 9 - MP-BGP and MPLS

I think I have a better "simplistic" view of MP-BGP...

This is how I keep it straight or understand it in my head:

- Address-family VPNV4 is used for PE to PE, to exchange VPN routes - implying that multiple VRFs will cross these peerings.
- Address-family IPV4 VRF XXX is used for PE to CE, to exchange IPV4 routes with the "customer" - implying that the interface connecting to the CE is in VRF XXX.

If this isn't right, I hope someone corrects me :)

Skipped 8 by accident, finishing 9.

I skipped section 8 MP-BGP by accident as when I printed the workbook I must have not printed that section, I already set up 9 which is MPLS so I decided to go ahead and finish this up before going back.

I have to say, I'm much happier with IPX Vol 1 then I was with INE Vol 1. None the less, it doesn't hurt to study off of multiple vendors and I plan on doing so. What does "hurt" is the order, which I had done IPX V1 first. Lesson learned.

Vol 1 Lab 6 - ISIS - notes

Some general very basic info on ISIS, level 1 is relative to intra area, whereas level 2 is relative to inter area... as it relates to ospf.


Task 6.1- General ISIS config
- when configuring ISIS, start by using the NET command and then assign interfaces to the ISIS process with ip router isis command under the interface
- the NET command includes the area, system ID, and selector-byte, ie, net 51.0001.000.c800.0001.00
- to prevent loopback interfaces from forming adjacencies use the passive-interface command under the router process

Task 6.3 - ISIS Link auth
- ISIS Link authentication - under the interface use the command isis password xxx level 2. Specifying level 2 when the link is between 2 different areas

Task 6.4- ISIS Area auth
- SNP authentication/Area authentication is done under the router process area-password xxx authenticate snp validate

Task 6.5 - TLVs
- New metric style is wide. Using "transition" will allow the router to accept the old metric style too. Under the router process, metric-style wide transition

Task 6.6 - timers
- adjust timers like Hello interval and multiplier under the interface.

Task 6.7 & 6.8 Redistribution
- when redistributing connected interfaces, create a route map to be as specific as possible, then redistribute, redistribute connected route-map NAME level-1-2, the "level-1-2" specifies that it will be advertised through both level 1 and 2 routers.
- when redistributing static routes, create a route map to be as specific as possible, and you can set a metric on a specific route in order for it to be NOT advertised. Set the metric to the maximum to accomplish this in the route-map.

So ISIS is new to me and this lab was my first exposure to ISIS. Therefor, writing notes will help keep thing straight in my mind and for future reference.

Reading the chapter on ISIS :)

I think I did it backwards :) I did lab 6 of IPX Vol1 which deals with ISIS and then I'm in the middle of reading chapter 10 - Integrated ISIS... Maybe I should have read FIRST then labbed :)

Oh well, I can always re do the lab to solidify what I'm reading.

IPExpert's Vol 1 SP workbook... so far so good!

So after switching gears to IPX and completing the first 2 labs, I'm pretty happy with starting from the ground up, even if some of things I knew/learned before.

Lab 1 was Frame Relay - nothing new to learn, just some good re-enforcement of things I knew.
Lab 2 was ATM - all new to me!

Lab 3 and 4 I may have to skip for now, until I get access to some switches (my R&S rack is at my 'rents house, powered down).

Off to work on Lab 5 - OSPF, hopefully I'll have the same experience as Lab 1.

Leaving INE Vol 1 for greener pastures...

I can't take the lack of explanation in their solutions and after a few people have suggested IPX Vol 1 as an alternative, which btw I was planning on doing next anyway, has just accelerated my path.

I have experience with IPX (in regards to R&S) so my expectation is set, I'm sure they did an excellent job in SP as they've done in R&S.

... I feel like the monkey has gotten off my back... for now.

Still Trekking...

Since returning from CiscoLive! I've gotten back to studying...

I'm still not happy with INE Vol1's lack of explanation and I'm looking forward to finishing and moving on to something more thorough. I'm about a quarter finished... I sure am dragging my feet. :)

Watching the CoD videos...

Changing gears a little... I decided to watch the CoDs before I return to Vol 1 labs, I need more of a foundation and more explanations. I'm hoping I'm going to get that from CoDs.

INE Vol 1 labs... Still At it...

I'm going through Vol 1 Labs and I'm having flashbacks from the R&S track... specifically the same complaints I had then, I have now.

Where are the explanations in the answer guide?!?!?! If Vol 1 is supposed to be the beginning of the prep for CCIE SP, I would think they would give you at least some verbiage on the solution. Nope, nothing but configuration and verification.

I find that without reiteration of what everything means, I don't learn but I end up memorizing which isn't going to help me in the long run.

waa waa waa... just crying is all.

JNCIA-ER done!

Done!

60 questions, passing is 70%. Multiple guess and was pretty easy. I understand about getting the word out about Juniper networking products and can see why it would be beneficial to have Juniper certified people out there in the industry, but do you have to make the test THAT easy?

I get that making it hard would be discourage people, they'll think "why study for this when I can use my time to study for CCNA or something else?" but there's got to be a better solution then making it easy to the point where you question whether it has any merit at all...

I like JUNOS, I like J-WEB, and I liked using the Netscreens in the past and I think competition is a great thing. I would've liked to come out of the test feeling like I accomplished something challenging, but that's just my opinion.

Back on track to Service Provider.

Sidetracked with Juniper...

A little side tracked from CCIE SP... for... Juniper JNCIA-ER.... what happened here? :)

The method...

Look to the Right... higher, higher... right there.

So I posted a rough method of what I plan on doing and in what order. Next is to determine the amount of time and the number of repetitions I'll need to do.

I'm also thinking it's probably a good idea to attend a class or bootcamp, I know for R&S it definitely helped pull everything together.

For now, I'm working on INE vol 1 :)

... And the hard part begins now.

So I passed the Service Provider Written this morning, better then my Route Switch written which was in the low 80s. The funny thing is, the test center takes your picture now. I guess there's a lot of cheating via the false identities taking place. Craziness.

You would think a weight would be lifted because step 1 has been fulfilled... Nah, instead I'm already feeling the drive/pressure/pseudo anxiety from knowing that the Lab is waiting for me. :)

Well, now on to organizing my plan of attack, will post it once I figure it out!

Scheduled the written!

Scheduled the written and will be taking it shortly, a little nervous as I'm used to reading an Official Exam Certification Guide and a very little other docs. This time around, there is no Official Exam Certification Guide but a bunch of other docs, books, and webpages...

Still, I'm feeling good that it's starting again. :)

and... still... reading...

So much to read and learn... while I enjoy reading, I think I'd enjoy configuring much more.

off topic - if your employer "helped" to get you your CCIE, ie, paid for training, paid for the exam, gave you time at work to study...

What do you owe them in return? If anything?

still reading...

Just wanted to post that I"m still still reading MPLS Fundamentals. Still very interesting and lots of information.

Work has gotten a bit busy with a new project and I'm squeezing in reading time whenever I can.

Can't wait to get the written over with and start doing some labs.

Reading is fundamental.

Still going strong with the reading... I'm realizing I'm definitely going to have to read this book more then once, probably more then twice. What with all the new concepts, it kind of feels like I'm starting from scratch. Regardless, it's still interesting so I'm ok with it.

RFCs and other documents

... still reading the book but reading some RFCs and some other Cisco docs... it's a good change of pace from doing the hands on configurations but I'd rather be doing that instead :)

Weekend plans, reading, reading and more reading.

4 Chapters into it...

Four chapters into the book and I have to say, I'm learning a lot!

MPLS is an incredible technology, very intelligent, can be complex or simple, but very powerful none the less. I can see the benefits to both the Service Provider and the Customers.

An interesting miss-conception that I had about WHY you should go with MPLS, the thought that it's a "faster" network because it doesn't have to look up destination IPs instead it simply looks at the label appended to a packet, was blown out of the water. And it should've been obvious too... Routers are getting so much faster and smarter so the resources used to do an IP look up now is nominal AND its not "slow" by any means. There are more COMPELLING reasons why MPLS is the WAN technology to go with.

I think I made a good choice in pursuing SP, I work for an SP and so I can kind of relate to it better, making it that much more interesting. Although the argument can be made that it's not valuable in the "real world" meaning outside of the SP realm but it's good to know both the enterprise side and the service provider side. The only disadvantage I can see is opportunity cost :) Not being able to study VOICE or SECURITY or more importantly have a life :)

First impressions of "MPLS Fundamentals"

I'm studying for the written and I've begun to read "MPLS Fundamentals" as well as some RFCs. The book it self is a very good read and from what I can tell, takes an approach that's conducive to learning. While I haven't finished the book, I can already tell that this is an excellent place to start to learn about MPLS as a whole.

Surprisingly, it's starting off as a quick read, I'll let you know more once I'm done and if I still feel that way :)

First Post... and the trek begins again ;)

Decided to pursue SP, reason being, I work for an SP :)

Hope I blog my pursuit of the CCIE SP better then I've done for RS (blog.netengineer.org)...

Will update soon!