Category Archives: Uncategorized

Happy New Year

Hi Everyone,

I wish you all a Happy New Year!

Currently im very busy studying for my 2nd attempt at the CCDE Practical exam.
I have it booked for the next slot, which is February 22nd in London.

Thankfully there are more and more material available for the CCDE than just a year ago. One of my primary sources are the study group which I have mentioned before, which Daniel (lostintransit.se) and I started way back.

Im also going through the INE scenarios as well as LiveLessons available through a Safari subscription. Those are really good and I highly recommend them.

One of the primary things im practicing at the moment is picking up business requirements from a given scenario. This is quite hard as im at heart an implementation-focused guy. But its good to learn something new and very useful.

If you are not following it just yet, I can highly recommend the “Unleashing CCDE” site on Cisco Learning Network (https://learningnetwork.cisco.com/blogs/unleashing-ccde). There are alot of good posts there on how to pick up these “soft” skills.

I will keep the blog updated with my study progress through February and we’ll see what happens February 22nd 🙂

Take Care.

/Kim

1st Attempt – No Dice

So I just got back from my first attempt at the CCDE practical, and unfortunally I didnt pass it.
It was a very different exam than the CCIE and it takes a little while to become used to the interface and exam style.

I started my journey to London on the 30th of August and right off the bat it started out badly with me getting an eye infection in one eye. By the end of the day it had spread to my other eye. Not really what you want or need going into an exam which is heavy on the reading part.

However, it was awesome meeting some of my study buddies from our Slack group! We had a great meal and a few good beers! – Time to call it a night.

The exam has been documented elsewhere, so i wont spend much time on it here. Suffice it to say its a difficult beast 🙂

I only used 5.5 hours of my 9 hour slot, and i just wanted to get out of there and rest my eyes to be honest.

I departed London September 1st and im now back at work. Much the wiser however.

I now know how the exam feels like and the delivery method. I also know what sort of questions are being asked of you and in what detail.

I do need to make up my mind about whether to try the November date or go for the February one. With all the stuff going on in my life at the moment (now being a home-owner), im leaning towards the February one.

Time to get back to work! 🙂

Looking forward

“All that matters, is where you are going” is a favorite quote of mine.

With that an update as well as a plan to move forward.

I have now finished Narbik’s Volume 2 Service Provider workbook. It took a little while longer than I had planned. This is mainly because i took some time off during the holidays (well, studied less at least 🙂 ).

Just today, I finished working on a plan of attack for the next phase of my studies. My goal is to take 3 days at a time, planning 3 days ahead and then plan again. Hopefully this will prevent me from being overwhelmed with tasks and ending up doing none of them.

There are basically 3 areas to my study, 1) Reading, 2) Labs, 3) Videos. With my “3 day”‘s approach, i try to mix things up, so i don’t get into a rut with any one thing.

Currently im reading Deploying IPv6 Networks as well as going through INE videos on Inter-AS MPLS and Carrier-Supporting-Carrier (CsC). All interesting stuff.

Lab wise, next up is Narbik’s Volume 3 labs. I figure somewhere around 4-6 weeks to go through them. The labs contain complex scenarios such as CsC, so each one will take alot longer than Vol 1 and 2 labs.

Thats all for now folks!

I wish everyone a happy new year!

 

Apologize for the down-time

I apologize for the recent down-time.
My provider had a glitch which is hopefully fixed now.

The cat is out of the bag.

The cat is out of the bag.

I am going for my 2nd CCIE. This time its in the Service Provider track.

For a while i have felt something missing. And what is missing is a clear cut direction on what i want to learn more about in my professional life.

I had a choice to make. Should i simply pick out areas of interest in the networking space and learn what i could about those or should i commit to a certain CCIE track and follow that path of learning.

I decided on the latter. There are several reasons for this. First off, is the fact that the CCIE program will take you through technologies that are used in that specific track. Seeing as i dont have much in the way of experience in the Service Provider field, its great with some guidance.

Another important reason for me, is that i can split up the journey to the CCIE into several sub-goals and work towards those. This has the benefit that i can measure my progress and lift myself up that way. Im sure you could do this without going for the CCIE as well, but for me, it makes it simpler.

So why the Service Provider track? — Well, if i had to describe it with one word, i would say “passion”. I started looking at Security as the next thing and even though lab equipment is alot easier to get your hands on for security, i just couldnt “feel” it. And if i learned anything from the first round, its that you cant go through with this without a great deal of passion.

I have little to no knowledge of many of the SP topics like Sonet/SDH, but they interest me. And thats what i need to keep going.

So there you have it. Thats the next goal for my professional life.

I will provide an update on how i will go about it and in what time frame, when i have worked out a plan for it.

Again. Stay tuned!

Redundancy for small sites.

We are working with alot of customers having lots of small “sites”, meaning that each site range from having 1 to 20 devices. The devices can be a user workstation or it can be some sort of automatic equipment having a VPN tunnel back to the main headquarter.

As the importance of each site grows, we are seeing these customers asking for a fail-over method for these sites and with the rise of cheap 3G connections it only seems natural to go down that route.

Cisco makes some small branch routers with 3G as part of the features. Routers such as the Cisco 819 suits the type of customers asking for this type of solution.

With these routers you basically get a normal WAN interface consisting of a Gigabit or FastEthernet interface and a Cellular interface which you have to tie together with a dialer interface.

To create the automatic failover, i have a small topology consisting of 4 routers:

Topology

The CE router is the site-router (think 819’ish router), but instead of a Cellular interface, i have created a Serial interface. (I dont have the possibility for 3G in my home lab).

ISP1 and ISP2 are two different ISP’s, but could also be the same ISP, providing services through different delivery methods.

What we want to accomplish is the ability to choose a different default route in case our primary provider fails. This failure can be both a link failure, but also a routing failure. How “far out” you want to meassure this routing failure is up to you, but choose a sensible and stable point.

In our example, the 43.43.43.43/32 is our “stable” point.

This is how we are going to accomplish the task:

First off, we need to use IP SLA to provide us with an up/down situation toward the stable point. We will just use regular icmp-echo, sent at a 5 second interval.

We then create a tracking object which we will use with our static routing commands. The tracking object references the IP SLA.

But in order for this to work, we must make sure that we always use our primary interface/path for sending these echo’s. If not, we would have continous flapping. When primary goes down, it switches to the secondary, but since we might be able to reach the stable point through our second path, it will reinstall the primary default route and on and on.

To pull this off, we will use a local policy (a policy which only local router traffic must abide to). In this policy, we specify ICMP traffic top our stable point, set the next-hop and if this doesnt work, send ICMP to null0 to drop it.

Lets check out the configuration on the CE router:

Define the IP SLA:

ip sla 20
  icmp-echo 43.43.43.43 source-interface FastEthernet0/0
  frequency 5

Schedule the IP SLA to start now and run forever:

ip sla schedule 20 life forever start-time now

Create an access-list for our local traffic:

access-list 110 permit icmp any host 43.43.43.43

Create a policy-map that controls the path the ICMP traffic will take:

route-map ROUTE-PBR permit 10
match ip address 110
  set ip next-hop 10.10.10.2
  set interface Null0

Apply the local policy:

ip local policy route-map ROUTE-PBR

Set up our static routing. Utilize the primary path if tracking object is up, if not use secondary path with an AD of 253:

  ip route 0.0.0.0 0.0.0.0 10.10.10.2 track 10
  ip route 0.0.0.0 0.0.0.0 11.11.11.2 253

So lets verify our solution. Under normal circumstances:

CE#sh ip route | beg Gateway
 Gateway of last resort is 10.10.10.2 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets
 C       1.1.1.1 is directly connected, Loopback0
 10.0.0.0/30 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, FastEthernet0/0
 11.0.0.0/30 is subnetted, 1 subnets
 C       11.11.11.0 is directly connected, Serial0/0
 S*   0.0.0.0/0 [1/0] via 10.10.10.2

We can see that we have our static route to our primary path. This must mean that our tracking object is up:

CE#sh track
 Track 10
 Response Time Reporter 20 state
 State is Up
 4 changes, last change 00:28:57
 Latest operation return code: OK
 Latest RTT (millisecs) 36
 Tracked by:
 STATIC-IP-ROUTING 0

Everything good here.

Lets verify that we have end-to-end connectivity:

CE#ping 100.100.100.100 so loo0

Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
 Packet sent with a source address of 1.1.1.1
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 40/49/60 ms

Superb!

Lets simulate an interface-down scenario on ISP1:

ISP1(config)#int f0/0
 ISP1(config-if)#sh

And now on CE:

*Mar  1 00:48:35.859: %TRACKING-5-STATE: 10 rtr 20 state Up->Down

CE#sh ip route | beg Gateway
 Gateway of last resort is 11.11.11.2 to network 0.0.0.0

1.0.0.0/32 is subnetted, 1 subnets
 C       1.1.1.1 is directly connected, Loopback0
 10.0.0.0/30 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, FastEthernet0/0
 11.0.0.0/30 is subnetted, 1 subnets
 C       11.11.11.0 is directly connected, Serial0/0
 S*   0.0.0.0/0 [253/0] via 11.11.11.2

Do we still have reachability:

CE#ping 100.100.100.100 so loo0

Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
 Packet sent with a source address of 1.1.1.1
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 16/23/28 ms

Awesome.

Lets instead pull the ISP1 link back up, but simulate a routing failure by denying ICMP on ISP1:

ISP1(config-if)#do sh access-list 110
 Extended IP access list 110
 10 deny icmp any any (110 matches)
 20 permit ip any any
 ISP1(config-if)#ip access-group 110 in

Again on CE:

*Mar  1 00:50:20.899: %TRACKING-5-STATE: 10 rtr 20 state Up->Down
 CE#
 CE#ping 100.100.100.100 so loo0

Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
 Packet sent with a source address of 1.1.1.1
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 24/31/40 ms

Again our tracking object goes down and we still have reachability. Lets make sure we go through ISP2 now:

CE#traceroute 100.100.100.100 source loo0

Type escape sequence to abort.
 Tracing the route to 100.100.100.100

1 11.11.11.2 20 msec 4 msec 4 msec
 2 172.16.100.4 40 msec *  44 msec

And when ISP1 comes back online:

*Mar  1 00:51:30.915: %TRACKING-5-STATE: 10 rtr 20 state Down->Up
 CE#traceroute 100.100.100.100 source loo0

Type escape sequence to abort.
 Tracing the route to 100.100.100.100

1 10.10.10.2 60 msec 44 msec 28 msec
 2 172.16.100.4 52 msec *  48 msec
 CE#

Nice and very useful.

I hope this is something you can use as well.

NAT on a stick

NAT on a stick.

I ran into this a while back, and then again the other day. Its really a puzzling way of doing NAT.

The topology:

Topology

Imagine this scenario (even though its very unlikely as far as i can see):

Our organisation has purchased an internet connection with a local provider. They are only able to provide us with 2 available IP addresses + our transit IP address.
We have several servers, and alot of clients that needs to connect to the internet.

NAT is the obvious choice. However, theres a problem. Our gateway only have 1 interface, and we are not allowed to buy anything else! Also, we cant use sub-interfaces.
(i told you it was quite unlikely 🙂 )

So, our IP addresses are:
Our public IP transit address: 83.84.85.130/30
Our gateway at the ISP: 83.84.85.129/30
Our extra assigned IP addresses: 70.70.70.1/30

Our internal IP addresses: 192.168.100.0/24

We have configured a router to act as the server, and this router has the IP address: 192.168.100.50
Beyond that, we have a loopback interface with this IP address: 10.0.0.1/24

For demonstration purposes, the entire internet is represented as 1.1.1.1, which is a loopback on the ISP router.
Also, i know that the choice of IP addresses would not really work in real life, but bear with me, its not important for the scenario.

Our first hat-trick is to get basic connectivity between our gateway-router (R1) and our LAN, as well as to the ISP.

Lets configure the interface in this manner:

interface FastEthernet0/0
 ip address 192.168.100.1 255.255.255.0 secondary
 ip address 83.84.85.130 255.255.255.252
 ip virtual-reassembly
 duplex auto
 speed auto

Lets verify that we have connectivity:
To our server:

R1#ping 192.168.100.50

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.50, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/18/60 ms

And to our ISP:

R1#ping 83.84.85.129

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 83.84.85.129, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/73/104 ms

Everything is OK! so far.

Lets just check the routing table on R1, so you can all follow along a bit better:

R1#sh ip route | beg Gate
Gateway of last resort is 83.84.85.129 to network 0.0.0.0

 83.0.0.0/30 is subnetted, 1 subnets
C       83.84.85.128 is directly connected, FastEthernet0/0
 10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Loopback0
C    192.168.100.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 [1/0] via 83.84.85.129

Okay, everything seems fine RIB wise.

Next up is a mind-bender. Remember that in order for NAT to work, we need to designate one interface as inside, and another as outside.
This is really to create a logical flow of things. However, our main limitation is that we only have 1 interface to operate on. If we had a router with two interfaces, we could use one as inside and the other as the outside interface.

What we want to utilize in order to get this working, is how IOS process packets.
I can highly recommend that you take a look at this: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

First, inbound packets to the router are first subject to policy-based routing, before any NAT’ing takes place. It is also taking place right before ordinary routing.
What we want to do, is send packets to the R1 router, these will be received by the “inside” interface, completing the first requirement. The routing decision has already been made, we need to send it to loopback0. This is done in order to “hit” an outside interface.

When the loopback interface sees the packets, it makes the routing decision, not per policy-based routing, but by ordinary routing. However, IOS routes it OUT of the loopback0
interface, back to our f0/0 interface. This completes the second requirement, going out of the interface thats configured as “outside”.
Since it doesnt match what we want to policy-base route on f0/0, it gets routed OUT of the f0/0 interface, NAT’ed as 70.70.70.1-2.

Return answers goes through the same process. It is received by the f0/0 interface, gets policy-routed (since the outside NAT is not on the f0/0 interface) to the loopback interface, which IS the outside interface and gets translated back to our original source (LAN IP addresses).

So lets get the components configured.
One of the most important components is our policy-routing. As mentioned, we will put our policy onto the f0/0 interface, which means that packets comming into this interface will be subject to policy routing if it matches the route-map.

We want two things to match our policy-routing. Namely inside traffic, that needs to get NAT’ed in order to goto the internet, and return traffic, destined for the NAT addresses (remember they must hit the outside interface again).

This access-list should do the job:

R1(config)#access-list 110 permit ip 192.168.100.0 0.0.0.255 any
R1(config)#access-list 110 permit ip any 70.70.70.0 0.0.0.255

We then need to create our route-map used for policy-based route:

R1(config)#route-map PBR
R1(config-route-map)#match ip add 110
R1(config-route-map)#set int loo0

So, everything that matches our access-list gets policy-routed to the loopback0 interface.

Lets go ahead and apply it to the interface, so we are done with it:

R1(config-route-map)#int f0/0
R1(config-if)#ip policy route-map PBR

At this point, we are done with the policy routing section. Next up is our NAT setup.
Remember that we want our f0/0 interface to be the inside interface and the loopback0 interface to be the outside interface, so lets get that out of the way:

R1(config-if)#int f0/0
R1(config-if)#ip nat inside
R1(config-if)#int loo0
R1(config-if)#ip nat outside

Alright, next up is to create a pool of IP addresses we can use for the NAT process. (I want to point out at this point that i have not gotten NAT with the 1 transit IP address working in this scenario).

ip nat pool TSTPOOL 70.70.70.1 70.70.70.2 netmask 255.255.255.252

The above creates a NAT pool, which states that we want to use 2 IP addresses, namely .1 and .2.
We also need to create an access-list that specifies which internal (as Cisco calls Inside Local) IP addresses we want to perform NAT on:

R1(config)#access-list 120 permit ip 192.168.100.0 0.0.0.255 any

Basically it states that all internal IP addresses will be NAT’ed when going out the outside interface.

Finally, lets put our NAT statement into place:

ip nat inside source list 120 pool TSTPOOL overload

So we want to take all IP addresses listed in access-list 120 and replace the source-address with the addresses in the TSTPOOL. We also want to perform PAT (port based NAT) to further increase our chances of getting an internet connection. (Otherwise, only 2 simultanous connections could exist).

Now, lets test this out! Lets try with a ping from our Server-1 to the internet (which is 1.1.1.1):

Server-1#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 176/252/312 ms

Awesome, we have connectivity. Lets check out what the “internet” is really receiving by looking at the ISP router:

*Mar  1 10:37:41.017: IP: s=70.70.70.2 (FastEthernet0/0), d=1.1.1.1, len 100, rcvd 4
*Mar  1 10:37:41.017: IP: tableid=0, s=1.1.1.1 (local), d=70.70.70.2 (FastEthernet0/0), routed via FIB
*Mar  1 10:37:41.021: IP: s=1.1.1.1 (local), d=70.70.70.2 (FastEthernet0/0), len 100, sending
*Mar  1 10:37:41.309: IP: tableid=0, s=70.70.70.2 (FastEthernet0/0), d=1.1.1.1 (Loopback0), routed via RIB

Again, what we would expect. The source address has been translated into our assigned IP addresses. As a final confirmation, lets check the NAT status on R1:

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 70.70.70.2:46     192.168.100.50:46  1.1.1.1:46         1.1.1.1:46

As can be seen, we have translated the source-address of 192.168.100.50 to 70.70.70.2.

I want to show you the output of “debug ip policy” on R1, so you can see the logic taking place:

*Mar  1 10:42:02.557: IP: s=192.168.100.50 (FastEthernet0/0), d=1.1.1.1 (Loopback0), len 100, policy routed
*Mar  1 10:42:02.557:     ICMP type=8, code=0
*Mar  1 10:42:02.557: IP: FastEthernet0/0 to Loopback0

And later on:

*Mar  1 10:42:02.617: IP: s=1.1.1.1 (FastEthernet0/0), d=70.70.70.2 (Loopback0), len 100, policy routed
*Mar  1 10:42:02.617:     ICMP type=0, code=0
*Mar  1 10:42:02.621: IP: FastEthernet0/0 to Loopback0 83.84.85.129

The first one shows that a request from an internal host is POLICY routed to the loopback0 interface. The second one shows the reply, in which the destination 70.70.70.2 is POLICY routed to the loopback0 interface.
This matches our access-list for policy based routing.

In summary, this is VERY ugly and it has some caveats. For example you cannot specify your own next-hop ip address on the loopback interface. If you had a /24 loopback interface, you could specify an ip-next hop of something else in there and IOS would try to route it through the loopback, resulting in it getting hit with the ip nat outside. Also, i have not found a way to use the transit net as the source address as you would normally use.

I wanted to show you this so you dont go “What!?” if you see it anywhere, which is most likely to be in a lab scenario, not real-life.

So please! dont ever use this 🙂

Beginning of a new week.

Yesterday i managed to do 2 hours worth of lab time + an hour on my latest blog post about BGP. All in all 3 hours worth of CCIE level stuff. I’m pleased with that after my motivational down-time.

I also managed to do a lot of physical work yesterday, fixing the car up, getting everything cleaned out. Its gorgeous now. So I was well tired, but after drinking Red Bull i simply could not fall asleep. It ended up being about 2:30 – 3:00 before i finally dosed off. Up at 6:30 again, and now I’m smashed 🙂

Not sure how much lab time i will have today, as i have to drive to the nearest Apple (3rd party) store to hand in my laptop AGAIN. They messed it up last time, and now my wireless NIC is not working. Beautiful! Ill never buy anything in Humac again. If im getting more apple equipment, it’ll be from apple themselves.

Now its time to finish up some work tasks (documentation) and then head off. 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 🙂