Lots of practice.

• July 20, 2009
• Technology  
• Debian  
• Linux  
• OSPF  
• QoS  
• Routing Protocols  

Been a few days since my last post.

During that time, I have taken quite a few practice tests to gauge where im at. I am also slowly progressing through the Exam Guide.

Also, in the near future im switching over to a new hosting service. Need some features which wordpress doesnt allow me to use, such as advertising. I got a friend in germany who has a colocated server which he will provide some access to. Very grateful for this.

I tried upgrading my server to Debian Lenny yesterday, which didnt turn out so well. I am using the 64bit version (AMD64), and whenever it boots it gives a kernel panic… not good.

I fixed it by using a lower kernel version, but with everything else being updated to Lenny. Will have to wait and see how performance is with the new system. Since the kernel has not changed, im not expecting anything significant.

I will most likely be purchasing some extra memory for it, so it has at least 4GB of memory. Wow, memory is so cheap these days. I remember in the old days, i bought 12MB of memory for my 486DX100, and it was close to $500. Now I can get 4Gb of memory for less than $100 🙂

Today I have been playing with QoS and markings. Especially a quote in the Exam Guide puzzled me a bit. But all in all, it comes down to the fact that INBOUND you cannot set a L2 marking! You can however set a L3 marking (such as IP Precedence or DSCP). I completely fumbled the ball with this on OSL (Online Study List)… embarasing. I confused MPLS with Frame-relay DE bit.

I tested this out on Frame-Relay and 802.1Q trunking (since thats the only LAN you are able to QoS tag)..

When applying a policy-map with a SET action on L2 marking you get:

R1(config-if)#service-policy input MARK-INBOUND-L2-SET
Process 'set' action associated with class-map MATCH-ICMP failed:
Set cos not supported in input policy

The policy-map looked like this btw:

Policy Map MARK-INBOUND-L2-SET
 Class MATCH-ICMP
 set cos 6

Also some interesting facts about FECN reflection.. Apparently the ITU name for it is Q.922. The way this works is by the frame-relay switch sending a FECN to the receiver. The receiver then “reflects” this FECN in a Q.922 response message. The frame-relay switch then sets the BECN flag. The sender can then decide to act on this. For example by adaptive shaping. This brings me to another point. Adaptive shaping slows down by 25% by default.. Again something I didnt know.! 🙂

In the routing protocol realm, I also learned a new command yesterday along with some interesting behavior. We know the command: “area nssa“. This makes the area into an NSSA area (same as stub, but with the capability of having ASBR’s). Without the “no-summary” keyword, it wont install any default route, and hence routers within the NSSA area cant reach non-OSPF domain routes (Because Type 5 is filtered (along with type 4 per. RFC standard)). If you then add: “area nssa default-information originate” a default route is then added. All is good and well. We are used to this command on ABR’s. What we are used to however is a type 3 default route. In the NSSA (without no-summary) a type 7 route is actually the default route! If you use the no-summary keyword, it will still insert a type 3 default route! Interesting.

A new command, the “area nssa no-redistribute” came into light. Basically this command is used when a NSSA ABR is also an ASBR. If you are doing redistribution on this ASBR, type 5’s will be inserted, and without this command a type 7 will be generated into the NSSA. With this keyword, nothing will be inserted into the NSSA, but the type 5 routes will still be inserted into regular areas (ie.. non-stub areas).

All good fun an interesting stuff.

On another note, last night I threw my back out playing basketball. Been a long time since my back has hurt this much!

Off to play around with some more linux stuff.