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!

Soon….

Just wanted to let everyone know that im working on a post describing the Narbik bootcamp. Just concentrated on labs at the moment. It will arrive shortly

Done packing.

Im done packing for Narbiks bootcamp next week. I will be flying out tomorrow morning and probably be at the hotel at around 1ish in the afternoon.

I have brought my training clothes, and hopefully ill get to utilize the hotel gym facilities during the day.

I also have about 20 pages left of the volume II workbook, which ill do remote on my home lab. These are actually the hardest labs so far. They are about mutation maps on switches, using the layer 3 functionality to mark/remark frames and/or packets.

Switch QoS is certainly one of my weakest areas, and one I need to work on quite a bit.

I have decided to bring 2 laptops, just in case and my new bag is really handy with lots of space.

I will try and write a blog commentary on how the bootcamp is carried out by Narbik, how well i grasp the material and generally the whole experience. I will be back saturday the 6th in the evening but i expect i will be too mentally tired to do much else than just rest

Anyways. Im off to get some sleep. Have to get up very early tomorrow!

Advertise Maps

More Narbik Labs. I have arrived at the BGP section, and its very good. It touches on some more obscure features that are really useful.
One of the things i ran into was the use of advertise-maps, exist-maps and non-exist maps. I have used these before, but very briefly.

I also have notes on the use of the mentioned maps, but its one of those things that if you dont use it, you forget it. When i read the task description i immediately
thought of using route-maps in some way. However, the task required some conditional requirements. More specifically, if this network exist
advertise this other network, otherwise dont. Right there, that cancelled my immediate idea.

So lets take a look at the suggested way of accomplishing this task. Namely using advertise-maps, exist-maps and non-exist-maps.

First of, our topology:

Topology for advertise maps

To begin with, we create a normal iBGP peering. I will not go into detail on how to do this since its documented so well alot of different places, including Cisco’s DocCD.
We then advertise all loopbacks on both R1 and R2. Lets verify that its all working so far:

R1(config-router)#do sh ip bgp
 Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*>i2.2.2.0/24       192.168.12.2             0    100      0 i
*> 11.11.11.0/24    0.0.0.0                  0         32768 i

*Note, that i cut some output out to breviate the post.

Its all working so far, lets include R2 for completeness:

R2(config-router)#do sh ip bgp
 Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.0/24       192.168.12.1             0    100      0 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*>i11.11.11.0/24    192.168.12.1             0    100      0 i

Alright, we are seeing the routes appear as we expected to.

Lets get to the advertise-map part.

These maps will be applied on a per neighbor basis. Ask the following question: “What prefixes do we want to send to this neighbor under what circumstances?”.
As with any other neighbor parameter, it will be under the router-config and after a neighbor command:

R1(config-router)#neighbor 192.168.12.2 ?
  activate                    Enable the Address Family for this Neighbor
  advertise-map         specify route-map for conditional advertisement

Now, lets define our task. We want to advertise the 1.1.1.0/24 route IF the 11.11.11.0/24 route exists in our BGP table.

First, lets create a couple of access-lists that define the networks 1.1.1.0/24 and 11.11.11.0/24:

R1(config)#access-list 1 permit 1.1.1.0 0.255.255.255
R1(config)#access-list 2 permit 11.11.11.0 0.0.0.255

Update:

We actually HAVE to match the inverse of the network in order for it to work. This only goes for the exist-map. There are some discrepancies here. If we create an ACL with the network not inversely matched, but later in the ACL creates one that is, the first ACE will be hit (sh access-list). Go figure.

Now to our maps. What we really want to create is some route-maps. Lets create our advertise map first. This map defines what network we want a condition on:

R1(config)#route-map AD-MAP
R1(config-route-map)#match ip add 1

Next up, lets create our exist-map. This map defines what routes must exist in our BGP table, if the previous (advertise-map) should be advertised:

R1(config)#route-map EXIST-MAP
R1(config-route-map)#match ip add 2

Finally we need to apply the two maps to get the functionality we want. We do this with the neighbor command as we started out with:

R1(config-router)# neighbor 192.168.12.2 advertise-map AD-MAP exist-map EXIST-MAP

Lets then do a soft-reconfig outbound to the neighbor in order to avoid the pacing-walk timer, which i believe is 60 seconds:

R1#clear ip bgp 192.168.12.2 out

Now, the network we are “meassuring” on, is loopback1 on R1, which is up now, so we expect 1.1.1.0/24 being advertised to R2:

R1#sh ip bgp nei 192.168.12.2 advertised-routes
   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       0.0.0.0                  0         32768 i
*> 11.11.11.0/24    0.0.0.0                  0         32768 i

And on R2:

R2#sh ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.0/24       192.168.12.1             0    100      0 i
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*>i11.11.11.0/24    192.168.12.1             0    100      0 i

So far, so good. Everything is working fine, and R2 is getting our “questionable” route.
Lets shut down loopback1 on R1 and see what happens with 1.1.1.0/24:

R1(config-if)#do sh ip bgp nei 192.168.12.2 adver

Total number of prefixes 0

Nothing! (remember that we shut down loopback1, so 11.11.11.0/24 went away automatically). Now R2 to verify it completely:

R2#sh ip bgp
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i

Great! our conditional advertisement works as planned. Task completed.

Lets recap. We created an advertise-map called AD-MAP. This map tells the router, that this is the network in
question. If our exist-map ends up being true the network in the advertise-map will be advertised. This exist-map is called EXIST-MAP and tells the router that if the network listed in this
exist-map is in the BGP table we want to advertise the network listed in the AD-MAP. If it doesnt exist in the BGP table, we DONT want to match it.

I hope this has been entertaining and has clarified on how and when to use advertise-maps!

Packing my gear – Taking some punches lab wise.

Making up a list of things i need to bring for the bootcamp. I finally want to try and be a bit more organized regarding this
on this trip. I thought id do that best by starting writing all the things i think i will need straight away, and then go back and forth on the list
and add things as i saw fit. Turns out that just doing this today, turned up 35 things already

I saw that there was a gym at the hotel. I hope i will get a little excersice done the day i arrive and on friday after its all done.

An update on Red Bull. This stuff still works on me + you can get it in stores here now as well, but at a crazy price of $3 each.
Thats just a bit over the top. I dont know why they are even able to sell them here, since last i checked Taurin was illegal in beverages in Denmark.

Anyways, i bougt 2 to begin with, and when i figured out that they worked, i now got an additional 10 for the remainder of Vol.2 labs

Hopefully i will also be able to find a place in Milton Keynes that sells them as well.

All i need now, is to pay the taxi company + print out my boarding passes (Ryanair stuff).

On the lab side, today really sucked. I didnt focus correctly and made some stupid mistakes regarding OSPF network types. More specifically
when they are not the same. Also learned a thing though. Namely that non_broadcast and point-to-multipoint will “peer”, but they wont transfer routes!
My knowledges was limited to the fact that they should perform an adjacency because the timers would be correct. But a good thing to keep in mind!
All in all, some punches tonight. Hopefully tomorrow will be better.

Goodnight World!

Distribute-list Fun!

Last night i was doing some Vol.2 Narbik Labs. I was supposed to filter some OSPF routes entering
the routing table on a certain router. I chose to use an extended access-list because, well, just because i could.
The command i wanted to use, was the router-config mode command “distribute-list”.

A bit of info on the distribute-list command. This command is used to filter routes in the routing protocol.
You can filter routes comming in from a certain interface, routes going out a certain interface (in some protocols), and
routes going into/out from another routing protocol when doing redistribution.

I knew that the way the extended access-list was interpreted would be different compared to what we normally
think of when using an extended access-list. Lets take a look.

Here’s an extended access-list

access-list 140 permit ip 100.100.0.0 0.0.0.0 255.255.0.0 0.0.0.0

This access-list looks a bit weird at first glance. However, there’s logic in the madness. The source pair
will be the network you are trying to match, in this case we want to match 100.100.0.0/16. The network must
match 100.100.0.0, hence we use a wildcard mask of 0.0.0.0. We only want the /16 netmask, which is 255.255.0.0.
Again we match this with 0.0.0.0 to make sure we only get this certain netmask.

Yes, i do know that prefix-lists would be alot easier and more transparent. In this case however, an access-list
was to be used.

The difference lies in how an IGP treats the extended access-list compared to how BGP treats it.
BGP treats the access-list as described above, but an IGP does not!

An IGP treats the access-list as follows:
The “source-pair”, in the example above “100.100.0.0 0.0.0.0″, has to be the update-source. Who sent the update
is what we are matching.

The “destination-pair” is our network part. This is where the network we want to match should be placed. If we continue
our example, we would put “100.100.0.0 0.0.0.0″ in this field. Note that we cannot match the netmask this way!

To finalize our example:

   access-list 140 permit ip 1.1.1.1 0.0.0.0 100.100.0.0 0.0.0.0

Which means, routing updates comming from 1.1.1.1, matching network 100.100.0.0 is allowed.

Now for the tweak

You can get the IGP distribute-list command to work as the BGP equivalent by using a route-map implementing the extended
access-list. Lets re-use our previous extended access-list:

access-list 140 permit ip 100.100.0.0 0.0.0.0 255.255.0.0 0.0.0.0

Now, lets create a route-map to use this access-list:

route-map TST-MAP
  match ip add 140

You can then use this route-map in your distribute-list command:

distribute-list route-map TST-MAP in

The only issue with this is that it goes for anything comming into OSPF, both from other routing protocols and from other
OSPF neighbors on other interface. Maybe not what you are looking for, but its doable

Anyways, I hope that shed some light on this nasty command.

A motivator!

I normally dont post/view/send alot of video clips around. But today this entered my twitter, and i thought id share it. I really find it an awesome clip:

Hope you like it, take care!

Closing out on 2009

Short update before the end of the year.

This year has been the worst one for me yet. Mainly because of health reasons. It has also been the year ive accomplished the most in my personal life, obtaining CCNP in the spring, and passing the CCIE written in the autumn.

I look forward to 2010 being a year that will prove to be alot better. So far, the girlfriend will graduate next month, she’s already been hired for a new job, and im still enjoying my new job alot. So workwise, things are looking brighter.

I am still suffering quite alot from my disease, but im determined to make 2010 be a year where ill minimize its effect on my life in general.

I just finished a frame-relay lab in the Narbik Workbooks on authentication, both PAP and CHAP has been covered in all sorts of directions. It was all good practice.

Looking at the archives, i have now maintained this blog for 2 years. I plan on keeping at it in more and more detail as my study progresses. I thank you all for reading!

Tonight its party time though. I will be going to a good friends house and have some dinner and lots of booze

I wish you all a very happy new years evening and a great new years!

Kim

Narbik Workbooks, VMPS and some random stuff.

I just re-cabled my home lab and setup everything so i could work on Narbik’s foundation workbooks. You can check out more at:

http://www.micronicstraining.com

These are the workbooks that you get before the bootcamp, to get you up to speed with individual technologies. All in all theres about 600 pages (~300 pages in Vol1 and the same in Vol2).

So far they are very good. Alot of refresheners and some new things that I have not encountered in detail yet. The most noticable of these is VMPS (Vlan Management Policy Server). I have skimmed over these in my previous studies, as its hardly a technology being used anymore (or so the texts says).
Basically its a technology that allows you to manage what vlans your workstations will be attached to. Its a Mac-address-to-vlan mapping tool.

You setup a VMPS server, which will pull the mappings through TFTP, and then you set the ports on the switch to dynamically learn of the vlan mappings. Its only a couple of commands, but i’d never set it up before:

"(config)# vmps server <ip-address> primary"
"(config)# vmps retry <retry-number>"
"(config)# vmps reconfirm <minutes>"
"(config-if)# switchport access vlan dynamic"

The above configures a primary VMPS server (add another line without the primary keyword to have a secondary server). It sets the retry count, which is the number of times the switch will try to contact the VMPS server. Finally the reconfirm parameter configures how often the switch should reconfirm the mac-address-to-vlan mapping.

Note that default behavior is to try and map the mac-address-to-vlan, if this fails the port is still open but no data can flow through it. In “secure” mode, the port is completely shut down.

You can verify the configuration by using:

"sh vmps"

The output “sh vmps” will produce looks like this:

Switch#sh vmps
VQP Client Status:
--------------------
VMPS VQP Version:   1
Reconfirm Interval: 60 min
Server Retry Count: 3
VMPS domain server: 192.168.1.2 (primary, current)
 192.168.1.1

Reconfirmation status
---------------------
VMPS Action:         No Dynamic Port

I have specified 192.168.1.2 as the primary VMPS server and 192.168.1.1 as the fallback one. Every 60 minutes the switch will reconfirm the mappings.

Thats about it for VMPS.

The other thing, which i have encountered before, especially during CCNP studies, is the voice vlan feature along with extending trust.

The entire idea is to have a Cisco phone connected to a switch port. You then want to have voice traffic on a certain vlan, data traffic on another. You want to trust the CoS values from the phone, but reset any CoS values the workstation connected to the phone is sending along.

Setting the voice vlan:

"(config-if)# switchport voice vlan <vlan-nr>"

And setting the data vlan:

"(config-if)# switchport access vlan <vlan-nr>"

Setting the CoS values on incomming frames from the workstation to the phone:

"(config-if)# switchport priority extend cos <cos-value(0-7)>"

And finally trust the CoS values if a Cisco phone is connected:

"(config-if)#mls qos trust device cisco-phone"

Apart from that, some random things about trunking, etherchannels and VTP has been covered.

Tip: Did you know you could see the VTP password currently in use, simply by issuing “sh vtp password” from the exec prompt?

Okay, off to play around some more

Bootcamp ordered and random things.

I finally got around to ordering my bootcamp.

I have chosen Narbik Kocharians bootcamp over both IPexpert and Internetwork Expert. I have only heard great things about his classes, so it was a pretty obvious choice for me.

I will be going feb. 1st until feb. 5th.

I am really looking forward to it, but it also presents me with alot of work to accomplish in the mean time. I have two foundation workbooks to go through in a very short timeframe.

Yesterday i started on reconfiguring my rack equipment to support the workbooks from Narbik, hopefully i can finish it before tomorrow. Id like to get a head start on the whole thing starting the day after tomorrow. I know i wont be able to do much of anything tomorrow, since its christmas day. I will however be bringing my laptop to my dads house, so I can skim over my new best friend, The Workbooks ™.

I will also need to schedule some study time, ONLY to browse through the Doc CD and getting really aquainted to it. I will have to stop using google to get to the right documentation since i wont have that in the lab exam itself.

Even though im using google calendar, im thinking about creating a basic word document with dates in it, and what i need to accomplish on those dates. It just seems so redundant to have it in two places, but oh well.

In a few hours im off work, and i really need to start getting the motivation for doing this thing back somehow.

Oh, and I will get my new laptop back for xmas

Have a really nice christmas everyone!