Journal

I'm not sure that I'm not going to regret doing this, but following in the footsteps of making a thread for my progress towards the IE.

Last night I grabbed a pdf for the routing & switching cert guide (I don't feel guilty about doing this, as the actual book has been purchased and is in transit. I may get it tomorrow or Monday at the latest - I just wanted to get started).

Read for about 3 hours last night and made it through Chapter 1 and most of Chapter 2. Everything seemed pretty easy / review until I came to a screeching halt at the end of Chapter 2 with the sudden introduction of PPPoE. Tried making sense of it for a while but gave up on it. I'll be looking at it more tonight, but may just make a note and move on. I'm hoping it'll make more sense on the re-read. That worked pretty well for a few areas in the Route studies.

To me learning is kindof like putting together a puzzle. It's much easier to do if you're adding to something you already know/have done. This surprise PPPoE felt like I was suddenly working on a totally new area of a puzzle where I didn't even have 2 pieces together yet.

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

I'd seen that post when researching earlier. I think I understand what they were trying to say but my (limited) understanding of what they were saying seems to contradict my (limited) understanding of what everywhere else was trying to say. Perhaps nobody understands it exactly and they come up with something that helps them understand 'good enough' the end result.

I've moved on, and have now spent all week trying to figure out using MBGP extensions for multicast. I can get it "working" easily enough - the concept is pretty basic. I have to use quotes around "working" though, because the only way I can get it working seems to make it completely pointless. I have SO many questions, and am going to spend today reading the BGP & MSDP to see if it makes any more sense. I'm leaving my puzzlement here as well though.

I completely understand the point - although as I'm writing this, I'm not even sure of that. My thought was the need was to keep 'others' unicast routes out of your unicast RIB - hence having the parallel multicast RIB you're populating. The issue comes back down to BGP not advertising routes unless they're in the unicast RIB. So in order for a border router (with an eBGP peer) to forward the MBGP NLRI internally, they have to be put into the unicast table anyway!!!! I would assume either by redistributing the NLRI into their IGP or by running both unicast and multicast iBGP address-families internally. So what's the need for the multicast SAFI when the unicast SAFI is already required to do the exact same work?

The only sense I can make of this would be to have different BGP configurations (RRs, TE, etc), but that's seems like SO MUCH OVERHEAD.

[EDIT] I started up a quick/dirty GNS3 session to quickly test/break from scratch and ... it works with ONLY the multicast BGP address-family activated. Perhaps it was something wrong with my CSRs preventing the edge peer from advertising ebgp-learned routes under that AF. I've rebooted the whole set and am trying again. Will report back shortly.

[UPDATE] Nope. Still having the same problem. I swear I'm going to feel stupid if it's something... dumb.

R4# sh bgp ipv4 multicast 155.1.79.0
BGP routing table entry for 155.1.79.0/24, version 0
Paths: (1 available, no best path)
   Not advertised to any peer
   Refresh Epoch 1
   100
      155.1.146.6 (inaccessible) from 155.1.146.6 (150.1.6.6)
         Origin incomplete, metric 2, localpref 100, valid, external
         rx pathid: 0, tx pathid: 0

R4# sh ip route 155.1.146.6
Routing entry for 155.1.146.0/24
   Known via "connected", distance 0, metric 0 (connected, via interface)
   Routing Descriptor Blcoks:
   * directly connected, via GigabitEthernet1.146
      Route metric is 0, traffic share count is 1

BOOYA! Found what was missing. The link between eBGP peers looks to need pim enabled on it. I'm still trying to decide if that makes sense or not. (EDIT #96): I'm thinking it's good - not for the PIM peering, but so the interface is recognized by PIM as a valid outgoing interface -- much like how it needs configured on interfaces where there are receivers (which also threw me off at first)

FINAL EDIT: ........ or not. Back to the drawing board.

After more testing, it turns out I was correct, in that I'd just needed PIM on the interface connecting the eBGP peers. With that in place I've moved on, tackling the MSDP sections which was a pretty logical extension, and then anycast RP which I figured out fairly quickly.

I skipped the switch section of multicast for now (I'm lazy and didn't feel like going over to my test rack next door), and have moved on to IPV6. So far nothing terribly tricky, but the latter half of the IPv6 section looks like it has some meat to it.

I'm still pretty concerned about post 110 and my thoughts on finding things in the Doc CD. My struggle continues. Today's specific example was turning off split-horizon with RIPNG. I never did find it there, but figured it out on my own.

I'm tempted to try looking EVERYTHING up there, no matter how long it takes. Even for things I know. Just to TRY getting proficient at maneuvering there but GAH. I don't think I have the patience.

bermovick wrote: »

I completely understand the point - although as I'm writing this, I'm not even sure of that. My thought was the need was to keep 'others' unicast routes out of your unicast RIB - hence having the parallel multicast RIB you're populating. The issue comes back down to BGP not advertising routes unless they're in the unicast RIB. So in order for a border router (with an eBGP peer) to forward the MBGP NLRI internally, they have to be put into the unicast table anyway!!!! I would assume either by redistributing the NLRI into their IGP or by running both unicast and multicast iBGP address-families internally. So what's the need for the multicast SAFI when the unicast SAFI is already required to do the exact same work?

The only sense I can make of this would be to have different BGP configurations (RRs, TE, etc), but that's seems like SO MUCH OVERHEAD.

Multicast BGP is only used for supplying PIM with RPF information, that's it. The point of using multicast BGP is that you can apply BGP policy to only the multicast address family which can create a multicast topology that's different from the unicast topology. In theory this allows you to pretty easily implement different paths for unicast and multicast traffic. This is can also be accomplished using static mroutes, but BGP can withdraw routes and fail over to different links and so on.

Basically, it's like unicast static routes vs. unicast BGP; it's a more scalable way of creating reachability information, but specifically for multicast. And yes, you need to have the prefix in your IP RIB for you to be able to advertise it into the multicast address family on the originating router, but you don't need to advertise the unicast prefix into BGP.

So what's the need for the multicast SAFI when the unicast SAFI is already required to do the exact same work?

There's no point unless you want to have different policy for multicast and unicast. If you don't use the multicast AF, PIM will just get RPF info from the unicast table. Hell, it might get it from the unicast table anyway in some situations since multicast BGP competes with the unicast table based on AD for the right to support PIM.

The two big caveats seem to be:

1) If a prefix is learned through multicast BGP and through some unicast source, and the unicast source has lower AD, PIM uses the unicast source. You'll get a rib failure on the multicast route. I think that this seems kind of dumb since you surely have the goal of overriding the unicast topology if you are using multicast BGP in the first place. You can fix this by setting AD specifically for the multicast address family with:

!
address-family ipv4 multicast
distance bgp x y z
!

2) A multicast bgp prefix is not valid for the RPF check unless the next hop is directly connected. It will install fine in the RIB (no rib failure), but it doesn't take part in the RPF. This is the same behaviour as static mroutes. This means that you need to adjust next hop manually in some situations.

It seems like a big mess to me.

Yeah, I had to actually see a valid RPF check where no route exists to really understand it. My erroneous conclusions was due to it not working.

I found a link that helped me start to understand. Let me see if I can find it again. (I'll laugh if it's the blog of someone here, by the way).

Jeff Kronlage's CCIE Study Blog: Rethinking mroutes; Multicast BGP

IPv6 section going slow but steady. I keep finding bugs in the INE workbook though. They're probably getting as sick of the bug reports I'm sending in as I am in having to send them.

Finished IPv6 section. Finding that ipv6 install section in the 15.2 area of the doc-cd was golden. Next section is QoS which I approach with some trepidation. This is going to be slow going since I would guess it's my single weakest area (something I hear is pretty common so at least I'm in a good crowd), and I need to try to remedy that some.

I want to add: Does anyone else using CSR1000v ever have a device randomly stop processing packets? It's bloody annoying because sometimes the only indication I have that it's done so is when a lab fails to work properly.

Surprisingly, I'm doing better than I thought with the QoS sections. About the only things really tripping me up are attention to detail (not reading the tasks closely enough so I don't do exactly what it asks -- and this hasn't been limited to the QoS sections), and knowing when to do policing vs shaping based on the wording of the task.

Does anyone know of a decent place that explains AAA authorization? Before now everything has only really covered the authentication part which I've got down, but everything I've found so far trying to explain the second 'A' seems to skirt around the topic and not really cover it well.

I've also been trying to lab to see what does what, but blindly labbing AAA means frequent reboots as you lock yourself out, and that's pretty time consuming!

Security is only 5% of the lab, so I don't have to go super deep into it (... yet), but I don't want to whiff on any area cause you never know when you need a few extra percent.

Is AAA even on the lab? You'll know that the three A's are Authentication, Authorization and Accounting.

A high level overview is you are aware that Authentication is the part that allows a user into a device (if configured for AAA of course), Authorization controls what commands they are authorized to run, and Accounting is a way of tracking what actions a user has taken. Now on a local basis, you can essentially configure AAA to look at the local user database using the aaa new-model command, and then by configuring appropriate AAA models on a management plane, i.e. console vs vty ports etc.

As you will know now, there is no TACACS server on the v5 lab exam, so that's good. Blindly configuring AAA for TACACS servers that weren't even available in the lab was always 1. stupid, and 2. pointless. Stupid, because as you've found out it is very easy to lock yourself out of a device if you haven't configured it properly, and pointless because... how can you check if it was working when you were right?

We use TACACS extensively at work so I've seen enough TACACS configs and have access to the ACS box (though I am by no means an expert at ACS, I just reset other users passwords).

https://ccie4all.wordpress.com/2013/01/21/aaa/

Good write up here on it too.

Yeah, I have tacacs+ installed on my linux box at home, but I only use it for authentication. It's helpful when I give a friend who's working on their CCNA access to real equipment, to just give them an account on the linux box (which is also where port 22 hole in my firewall connects to)

The lab blueprint mentions AAA, but just barely. INE's workbook has a section on authorization, but the workbook has gone well outside the lab blueprint in a couple other places so ... I don't know

Good point...

Basically though you can setup your ACS to control what commands your users can do. Same principle on a local device without the ACS box, but I guess it's a lot more fiddly. This is a subject I've definitely put under the "Reference the DocCD if I need to" during my big day..

I think I've got to re-think my strategy here, because today has been completely awful. Every single task I've been at least partially unable to do, and I continue to have a near-100% failure rate at finding anything in the Doc CD. I end up struggling for a while, then looking at the answer and I have to question how much benefit that is and how much time I'm just wasting with this method.

I don't know about you,b ut I definitely still learn when I have to give up and read the solutions guide in the IPX workbooks.

That being said, it's definitely frustrating. I just try to get a bit further through the tasks each time before i Have to look, but then when I do, I try to make sure that I READ the solution. Not just the settings, but the actual explanations as to what is being accomplished, why, etc. Even if it means that my rack rental runs out before I finish the whole set of tasks. I don't like using up that rack rental time that way, but if I'm just memorizing/typing, and not really learning, then it's a waste anyway, even if I "finish" the set of tasks.

Whenever I have a day like that - the answer is easy - step away from the keyboard.

Are you feeling a bit frazzled? Doing too much lately? If I'm tired and things are just not working then I just walk away, but it'll be too frustrating/depressing to keep on bashing at the keys. Tomorrow I bet you'll be fine.

Vague task instructions. Ugh. I cringe every time I run across something like this:

Once connected to R2, only allow this user to connect to R1.
    Log any attempt to connect from R2 to any destination on port 80.

My solution blocked conections to any destination on port 80 (including those to R1) FIRST (which in retrospect is still not 100% correct). The solution given was to allow to R1, then block anything (ELSE) with a destination port 80.

Technically I think the correct answer would have to be
1) permit connections to R1 port 80 but log them.
2) permit connections to R1
3) deny connections anywhere else to port 80 and log them.
4) implicit deny catches the rest.

Configure R3 to drop any packets destined to the router with IP source route option (either loose or strict).

Aaaand the acl in the solution uses source/destination addresses of any/any.

*grumbles*

Are these tasks from some sort of workbook?
Which one are you using?

(TL;DR, sorry for asking that

)

Yeah, these are tasks from INE's workbooks.

Income tax return may be sufficient to get me into a bootcamp.

I've been torn on these. For the cost, that's a couple lab attempts. They seem to be really valuable though, from what I've read...

But they're so expensive. I'm dropping more on a 5 day class than I've spent on most of my cars...

Berm - In all honesty the bootcamps are not worth it.

bootcamp = guarenteed time on the console (just like at school) but if you have enough self drive you can do that at home. You need to prep well and make sure you stick to it, but theres nothing better than a teacher pulling you along.

For the price of them i believe they are amazingly overpriced unless work is paying (like in my circumstances i was lucky that they did) if i had to do another bootcamp, there would be no way personally i would pay.

A 5-12day cram session should not make the difference between a pass and a fail, especially if you know that INE for example is going to follow the same workbook you have probably already purchased and as well as the videos.

my 2 cents

I haven't bothered with a bootcamp for what it's worth.

I will imagine they are very nice if you need an instructor to explain everything for a week and a perfect opportunity to clear up some weak spots or some subjects you might have some doubts about - but personally I'd just read more websites or more DocCD

Thanks guys. It's good to hear others say the same things I've always thought.

Plus that money can go towards tokens for (GRADED) mock labs w/ INE or the other vendors or something. I think those might be really useful.

Also, I don't know what happened the past few days (probably discovering the master index back in 15.2), but I'm having MUCH better luck finding all but the most obscure things now; and even then I'm not doing horribly.

GAAAAH.

So many days I get so frustrated that stuff doesn't work AND I DON'T KNOW WHY.

WHY does a vpnv4 route show up under the RD but not under the VRF (show bgp vpnv4 unicast [rd 100:1|vrf VPN_A])? I've been fighting this damn thing all day with 0 progress. BAH

Without fail, as soon as I come here and vent, I figure it out (This has happened SO MANY TIMES these past 6 pages).

Problem was from a previous lab, a forgotten route-map changing the route-target for that route.

I really doubt I'll be ready before my 18 month window runs out. Far too many frustrating days where I spend the entire day trying to figure out a single lab.

(And then I post here and figure out it's a stupid mistake on my part, like configuring crypto isakmp key CISCO hostname 150.1.7.7)

Today is going EXTREMELY well. I don't know if that's because I'm doing an area that really interests me (ipsec & vpns... don't ask me why; they're just cool).

I think this is the last section before I start working on the bigger labs from INEs workbook (sucks that there are only a few though)

VERY glad to hear it, bermovick. I've been having some struggles studying myself, I'm glad you've gotten over that hump for now.

Cheers!

Good to see some more positive work here. Keep it up man.

Working on the foundation lab 1 from the INE workbook. A bit amusing that I'm running into simple things and knowing AN answer, but not if it's THE answer they want or if there's some other way to do something I don't know about

I'm doing better with the doc cd, but I still encounter things that completely stonewall me. Even googling to find the area and then reverse-engineering the path to that area doesn't always work (case in point: PPPoE server config. I found the client config easy enough but the task requires both ends configured. I checked the blueprint but it doesn't specify only the client config needs known so I gotta be able to find both)

PPPoE to be honest, is a pain in the ass to find anyway

Quick Links