Narbik Bootcamp 2010
I thought i would write a bit about my bootcamp last week. Here’s what I have come up with. I will update this as more thoughts flow into my head 🙂
Day one at Narbik’s bootcamp:
—————————–
What an eye opener. This guy has his stuff under control! We started out with switching topics. Configured all sorts of things. We were told that 60% would be configuration and hands on stuff, while the remaining 40% would be theory (chalk talk). This is a good balance if you ask me. Its not that theory is bad, its just that its so detailed, that you can only grasp so much of it.
There are alot of different ways that you can configure the switches to do exactly what you want, and his lab-books make us go through the majority of them.
Also, i like the fact that the days were accounted for. On certain days we would be doing certain things, which makes planning easier. You can keep certain questions on a specific topic, for those days where its supposed to be covered and focus on the topic at hand.
In the end of the day, we were supposed to do frame-relay lab stuff, but i was just too bombed out. I ended up putting on a movie and then fell asleep immediately 🙂
Day two:
——–
Day two is all OSPF and EIGRP.
This is an important day, as the lab core internal routing protocol will almost certainly be OSPF.
We started out with all the different LSA’s and how areas connect to each other. All the different LSA’s have been covered in detail, where they appear and why.
OSPF filtering is bad 🙂 , and boy theres alot of options you have available to you.
Next up is area types. It was already 17:00 EIGRP was still to come!
Figured out that the hotel will block your internet access if you start up a virtual machine (vmware fusion) and try and access that comming from the same MAC address as the computer you originally logged in with. NAT to the rescue instead of bridge mode.
Finished off EIGRP. Its a pretty cool protocol and one of the things i have taken away from it was that its a very stable protocol thats apparently in use in quite alot of places. I have never seen it in use in Denmark except in testing environments.
Even though its a less complex protocol than OSPF, it still has some quirks here and there. Its really awesome what you can accomplish when you learn what IOS provides for you in different circumstances.
One of the things i enjoyed alot was hearing about Narbiks practical implementations of alot of these technologies. Getting some background information on how and why he implemented this, makes it more than a theoretical exercise in the lab environments.
I like the fact that he distincts between good protocol work and what he calls 007 style configurations.
Also, this guy really doesnt seem like he’s in it for the money at all. He has a passion for these technologies that really shines through in how he teaches.
Day three:
———-
QoS and RIPv2 was on the program. I must admit that when i got back to the hotel room at night i was really smashed and didnt feel like doing any labs at all. I dont see any reason to start some labs when im already mind-numb. I wouldnt learn anything from doing this. All the labs looked really interesting though, so i was looking forward to hitting them when i got home.
Custom queueing has been really nice. Narbik showed how it was actually a bit more complicated than I expected. There was a pretty heated debate on this on group-study not long ago. Cant quite remember how it ended, but todays lecture has certainly proved some points about how the router is actually doing this.
Been going through the MQC with NBAR. How you can actually do really weird things by matching on certain criterias
Policing and shaping is now done. Definitely an area i need more excersise in.
Day 4:
———–
Unfortunally Narbik has become sick, so we would not be able to carry out day 4 or 5 as planned 🙁 This really sucks, but he’s only human you know, so what are you gonna do. Hopefully he’ll be back on his feet in no time and get to spend some time back home with his family.
I hope theres going to be some sort of “goodie” as a compensation, maybe some cool trouble-shooting labs? ;). Its going to be hard to find the time to go back to the bootcamp any time soon, but i hope ill be able to.
I booked another flight back home the next day. Might as well get back for the weekend was the thought. No point in staying at the hotel doing nothing, as the city was so small it really didnt offer much in the way of excitement.
I managed to do some proof of concept regarding frame-relay.
Whats always irked me is inverse-arp. Let me explain some of the things i have discovered by labbing everything up.
Now heres the run-down:
1) Frame-relay routers will ALWAYS respond to inverse-arp requests.
2) If you configure p2p subinterfaces the router will NOT send out inverse-arp requests because it has no need to (it will always assume that its directly connected to the subnet you define as an IP address.
3) If you configure p2m interfaces, and you dont use frame-relay maps but frame-relay interface-dlci instead, the router WILL send out inverse-arp requests.
4) Even if you turn off inverse-arp on a physical interface, your subinterfaces will STILL respond to inverse-arp requests.
5) The “no frame-relay inverse-arp” command ONLY disables sending out inverse-arp requests!
Here’s an example:
"int s0/0
encap frame-relay
int s0/0.21 po
frame-relay interface-dlci 201
ip add 192.168.12.2 255.255.255.0"
Now, because its a point-to-point connection, THIS router will not need to send out inverse-arp requests for anything on the 192.168.12.0/24 subnet. It already knows that everything on that subnet is going out of this interface, and can ONLY reach the other end in one way, namely the p2p connection. This will be revealed by the frame mappings as well:
R2(config-if)#do sh frame map
Serial0/0.21 (up): point-to-point dlci, dlci 201(0xC9,0x3090), broadcast
status defined, active
The other end though, is a different story. This will be R1. Lets configure this on the physical interface, thereby being a p2m interface. We will not create any frame-relay interface-dlci’s or mappings for the moment. All the PVC’s offered to this physical interface will by default fall onto the physical interface. We’ll just configure an ip address:
"int s0/0
encap frame-relay
ip add 192.168.12.1 255.255.255.0"
Now to begin with, we wont have any frame mappings at all. But in time we will send out an inverse-arp request, and R2 will respond with the mapping even though R2 has a p2p subinterface configured.
And a bit later… voila:
R1#sh frame map
Serial0/0 (up): ip 192.168.12.2 dlci 102(0x66,0x1860), dynamic,
broadcast,, status defined, active
Now the last thing I want to point out is where the “no frame-relay inverse-arp” command is applied. If you have a p2m interface, configured with the frame-relay interface-dlci command, you can set your physical interface with a “no frame-relay inverse-arp” command, but this wont stop the p2m interface from doing inverse-arp requests. In the below R1 is reconfigured to have a p2m interface, configured with the interface-dlci command:
interface Serial0/0 no ip address encapsulation frame-relay clock rate 2000000 no frame-relay inverse-arp end interface Serial0/0.12 multipoint ip address 192.168.12.1 255.255.255.0 snmp trap link-status frame-relay interface-dlci 102 end
And again:
R1#sh frame map
Serial0/0.12 (up): ip 192.168.12.2 dlci 102(0x66,0x1860), dynamic,
broadcast,, status defined, active
Anyways, ill stop rambling now. Just thought you all wanted to know how the bootcamp went. Would i recommend this to anyone?
I already have. My coworkers asked me alot of questions on how it was today, and all I could say was that it was a great learning experience, and if they were going down the same path, they would be crazy not to go. The bootcamp is cheap, it goes straight to the point and if you dont think you are learning something from this guy, something is wrong with you, not the bootcamp.
Right now, its girlfriend time. Tomorrow i will be able to dedicate more time to some frame-relay maps. Take care!