Journal

bermovick

Providing Protocol Support for Broadband Access Aggregation of PPPoE Sessions

BOOM.



(hehe - I can't get it to work even with the page open though)

bermovick

Foundation Lab 1 done. I didn't realize they were so short.

Only tripped up on 2 things which I've made notes on.

bermovick

I have spent all of the little time I've had available for studying over the past week repeatedly trying to get PPPoE to work. WTH? I got it fine last time with a little help.

Gonna move on and come back cause I'm just spinning my wheels here, trying the same commands over and over.

gorebrush

PPPoE is a pain in the butt though

joelsfood

Maybe I'm missing something, but what is the use case for PPPoE these days? Been a long time since I've seen that term.

bermovick

In my situation, the case for PPPoE is: "It's on the lab".

I may have asked this on one of the previous pages, but I can't remember (and am too lazy to look it up), but is there any good way to get good & fast at redistribution? I understand it well enough, but if you sit me down with a topology, it takes me far too long to determine redistribution issues than I'm comfortable with.

Doing a ton of redistribution labs is one way, but not sure if it's the only/best way.

gorebrush

I think it really is down to trying out different scenarios, find as many as you can...

bermovick

Yeah, that's what I was afraid of. I find I'm not imaginative enough to come up with my own scenarios. Gonna spend today trying to come up with the different situations so I have something to work with when writing up a lab.

gorebrush

I find that sometimes. Start simple, add to it piece by piece. Adopt a "What would happen if I try this?" and document it. Follow the steps, review the outputs, look at the results...

Adding two entry points into a networking domain is where the fun starts

try gnsvault for pre-made lab ideas?

bermovick

Bah! Damn NEC network here has it blocked for some reason. I'll check it out at the house.

Pissed off at INE now - I started to review their solution & verification on the redistribution section of their lab I'm working on (parallel lines between 2 routers, both running ospf & eigrp and both doing mutual redistribution is really screwing with my head) and right off the bat there's a HUGE mistake regarding the RIP redistribution of connected interfaces/routes.

It's difficult enough trying to get a deep grasp of this without false information being given.

bermovick

Still here, still working on trying to crack redistribution. I've been trying to find online blogs or what have you discussing redistribution, but I mostly just find things along the difficulty level of "don't forget to add the subnets keyword when redistributing into OSPF", or "don't forget to add metrics when redistributing into RIP or EIGRP".

Yeah, I know that. Why don't you help me understand something actually at the difficulty level I need to understand, Mkay?

(ok, that sounded a bit entitled).

Work is quieting back down again I think, so I'm trying to break things via labs. What sucks is when I set up a lab that's supposed to be broken but it still works! It's hard to troubleshoot why something ISN'T not working

AwesomeGarrett

What is it that you're looking for when it comes to difficult redistribution scenarios?

bermovick

I'm ... really not sure how to answer that. I'm not really looking for difficult scenarios, just actual scenarios, instead of just information on what the redistribution arguments are.

This is one of those cases where (to me at least), you think you understand it because it's pretty much an easy concept, but when you start actually doing it, you realize the one concept mentioned (going from a higher AD to a lower AD, then back to a higher AD) is really just the tip of a very detailed iceberg.

I managed to make a broken topology earlier with a single redistribution point, yet it took me 3 tries to get it properly broken, and afterwards I actually had to draw out the topology, what I thought the routing updates would be like across each link and then do packet captures where I wasn't certain / to verify what I knew. Then I had to think about WHY before I got it. (It was actually quite scientific, in retrospect.)

And that was just a "simple" scenario with only a single point of redistribution and only 2 routing protocols. Add in a 3rd protocol, then also add connected redistribution at multiple places, and sprinkle it with some route maps and it gets to be too much to keep track of.

reaper81

Here's some stuff I wrote in the past. Maybe it will help you a bit at least:

Route redistribution – filtering and mitigating loops | Daniels networking blog
Route redistribution – Route-maps and tagging | Daniels networking blog

bermovick

I remember finding that site before; one of the better written ones (and I use variations of your topology from the first link).

Adding the word "loop" to my google search is getting me a bit more useful links (yours is at the top of the search by the way! congrats!).

I think perhaps ultimately I need to stop trying to do it in my head. When I drew out yesterday's issue I no longer had to try to 'remember' it all, because each step had a note written down (like "<--RIP,120"). Being able to stop and focus on a certain router without worrying about forgetting the rest made it easier (albeit a bit slow).

reaper81

Thanks!

It's kind of funny that creating loops is actually not as easy as one would imagine. Funny thing number two is that I've barely seen redistribution in the 8 years or so I've been involved in networks. Sometimes between IGP -> BGP but almost never IGP -> IGP.

Basically if all protocols did what EIGRP does with higher AD for external routes, loops would probably not exist.

You may run into issues if you go from a higher AD into a lower one and then back to a higher. So normally you would have something like RIP -> OSPF -> RIP/EIGRP which is not very realistic to be honest.

I guess they key is to learn of protective measures like distribute lists, route tagging and so on.

Good luck with your studies!

bermovick

Did anyone else have problems with IPSec over DMVPN on CSRs? One DMVPN appears to work fine, but if you try to bring up a second DMVPN (not a second spoke on the same DMVPN), the first fails and neither works. I spent a whole day thinking I'd configured wrong since I configured both at the same time!

Gonna poke at it a bit more, but looks like it might be a software bug. Which sucks since that means I'm unable to meet the lab requirement for this step, which later steps may depend on, and doing workarounds means having to account for those later (and possibly do further workarounds at that step)

Actually it looks like the first continues to not work after removing the second, until you reload. Chalking this up to software issue and moving on (I guess just removing ipsec since that keeps routing functional)

jamesp1983

Related to your redistribution concern...

Network 101: Routing Loop (Redistribution)

bermovick

Aug 25, although since that's only 4 months away I'm still entertaining the idea of just retaking the written later this year and getting a new window, as I don't think I can be ready in time.

bermovick

jamesp1983 wrote: »

Related to your redistribution concern...

Network 101: Routing Loop (Redistribution)

Thanks, but I don't think a link that basic will help with the current lab where R1 is running OSPF pid 1, EIGRP pid 5, redistributing between the two (and redistributing a loopback into OSPF). R1 is connected to R2 which is running OSPF pid 1, OSPF pid 2 and EIGRP pid 5, redistributing between all 3 (as well as a loopback redistributed into OSPF pid 1), with R1 and R2 being adjacent on OSPF pid 1 and EIGRP pid 5. R2 is also connected to R3 which is running OSPF pid 2 and R3 is redistributing its loopback into OSPF pid 2.

Now quickly determine issues between this (there are also other internal routers in OSPF pid 1 and EIGRP pid 5 that are affected by this)

bermovick

Had some really weird cold or something for the past month+. The odds of me being ready before my window closed was already iffy, and this pretty much closed the deal (at least that's what I'm telling myself). The silver lining is that I don't have to worry about setting a looming date, and can just hit the labs until I feel I'm ready.

Having that month break was nice in that I don't feel any "study exhaustion" anymore, and am feeling refreshed.

bermovick

ARGGGH; I hate when IPSEC doesn't work but doesn't give any indication why

bermovick

So often I'm finding myself stuck on things and uncertain if I've done something wrong or if there's some bug with CSR1000v or something.

I mean surely it can't be the CSR, since everybody uses it, and nobody else seems to have these seemingly constant issues with it, right?

right?

So then I end up completely doubting I'll ever be able to do this, since the simplest things just. don't. WORK.

bermovick

STILL getting hung up on redistribution labs. So many little gotchas and caveats and exceptions I have to remember and add.

I'm not sure my solutions are correct considering how many extra things I end up adding just to make it work.

bermovick

Weird cascade of failures in my lab today. 2 routers couldn't establish a BGP peering. After verifying the configuration looked ok, I rebooted both. 10 minutes later their BGP is up, but one of them no longer establishes an OSPF virtual-link with a 3rd device. After verifying config again, I reload #3. 5 minutes later, 2 and 3's virtual-link comes up, but now 3 and a 4th device have lost THEIR virtual-link. I'm just passing time while #4 reboots. Hopefully I won't waste too much more time with this!


HAHAH oh sheesh this is embarassing. I finally figured it out when device #4 came up and nothing worked. Had created a new loopback to advertise with BGP. Any guesses what happened to the router-ids after the reload?

bermovick

Found a couple other issues during the troubleshooting; The original lack of bgp peering was actually caused by a routing loop I hadn't spotted (possibly an intermittent one since my tcl script should have failed otherwise) and I had a typo in an acl that was causing some issues. Everything's resolved now (as far as I know), but wow... that took about an hour and a half. Far too long and (I assume) far too reactionary.

bermovick

Started the first full-scale lab from INE today.

O. M. G.

Task 1 I did fine. Task 2 I didn't even know what they were wanting; even after reading the answer I don't know how I was supposed to know that was what they wanted from the instructions. And it only went downhill from there.

bermovick

I ran into eigrp maximum-hops! Despite google including a link to a techexams thread from the ccna section, I have literally never heard of that field before. I flipped through every book I have and nary a one mentioned it.

Ran a packet capture and sure enough, it's right there in the update. Ended up having to look at the solution to find where and how the command is applied. I still find it cool to find new features and ways of doing things, although the lack of information for it in the configuration section of the doc cd (or any of my books) was a bit worrisome.

When I got to work today my config from friday was gone so I had to re-do it. I remembered enough of the command to find it in the master index, but one of my big fears is needing information on a new feature like this during the real exam and not have it be in the place you'd think it should be - exactly like this.

bermovick

2 days in a row now I come back to work and all my IOU devices have disconnected. They'll reconnect but are unresponsive and I have to kill all of the processes and restart, losing any config I hadn't saved. (Technically after I shut down some of them the others start responding but I'd rather my rollback point be consistent across all devices).

It's a bit annoying, so if anyone has encountered this before let me know The IOU devices are running on a debian 32-bit VM hosted by an ESX box. There's plenty of RAM allocated, and a significant amount of swap not even being touched. The host is old and slow, but not THAT bad.

In actual study news, I made it pretty dang far yesterday. I got stuck with vpnv4. BGP was redistributing between vpnv4 and ipv4 vrf as far as I could tell from its bgp tables, but wasn't advertising the routes to vrf bgp neighbors. I didn't have my mpls book handy to review so wrapped up for the day, but that was nearly 1/2 the lab done without getting stuck!

NetworkVeteran

> Maybe I'm missing something, but what is the use case for PPPoE these days?

It assigns IP addresses. You might say, why not DHCP ("IPoE").. but, why not PPPoE? Especially you already run it! PPPoE is still out there. Some advantages include built-in connection monitoring, better end-user accounting, and authentication.