BGP

So I am working on my BGP skills at the moment.  This is going to be a fun exam I think, as the content is rich, and labbing will be plentiful.  I still have a streaming subscription to CBTnuggets for a little while, so I breezed through the CCIE Certification Series BGP videos.  Jeremy did a fantastic job on those, and I took pretty good notes throughout.  I am going to continue on by reading a book that just arrived...Internet Routing Architectures.  The first couple of chapters are a bit dry, but provide a good history in the internet, and ISP's in general.  I will update you all as I go, but bid you farewell for now!

Passed Qos 642-642

Well I cleared the exam today. I'm not going to sit here and say it was easy either.  It was a good hard test.  I did get hit with some off-the-wall stuff, but for the most part if you knew your QoS you will be fine.  Finished with about 15 minutes to spare, and an 869 score.  I was a bit shocked looking at my report though, one category was in the 50%, and two in the 75'ish area.  I did pretty strong in the others areas though, and I think that pulled my score up.  Thanks guys, onward to BGP!

Last nights problem...

So my post last night was concerned with the fragment size noted in the show ppp multilink command.  Well, I figured it out after about an hour of thinking; I then verified this morning.  If you calculate the fragment size at 160 bytes, LFI is automatically going to halve that for a multilink with 2 attached links (because each additional link comprises that percentage of the overall bandwidth).  Now the 72 number is funny, because it should be 80 right?  Well, turns out LFI is smart enough to know 80bytes is the maximum packet size on that link in order to get the 10ms serialization time.  It is also smart enough to know that using ppp you are going to have 6 bytes of ppp header overhead added to each fragment, as well as another 2 bytes to keep track of the fragments.  So all in all, you have 72 + 6 + 2 = 80...and voila. 

So check it out.  I killed serial 0/1, and the bandwidth changes, but not the fragment size...proving that it calculated the fragment size, and then halved it because there were two equal bandwidth links.  Nice.  I still need to find out what the weight number is there...little research after this to find that out. 

MLP Fragmenting and Interleaving

I mainly wanted to post this here for future reference, but I labbed up link fragmentation and interleaving on PPP links tonight.  Cisco recommends this on links slower than 768kbps.  MLP interleaving determines fragment size based on the configured link bandwidth, and what you as the network admin put as the delay within the ppp mulitlink fragment statement.  For those math lovers out there, the formula is:
delay in seconds * configured bandwidth (i.e. 10ms on 128k line would be .01 * 128000 = 1280 bits/160bytes

Here was my interface configs:

interface Multilink1
ip address 172.16.12.2 255.255.255.0
fair-queue 10 512 14
ppp multilink
ppp multilink fragment delay 10
ppp multilink interleave
ppp multilink group 1
!
interface Serial0/0
bandwidth 64
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1
!
interface Serial0/1
bandwidth 64
no ip address
encapsulation ppp
ppp multilink
ppp multilink group 1


Notice that the delay is put in ms in the ppp multilink fragment delay command. Here is some interesting output:

Now the bandwidth here is configured at 64kbps per interface, with 2 in the bundle...so 128k combined.  I configured the delay at 10ms, so if we use our formula we should get: .01* 128000 = 1280/8 = 160 bytes.  But what the duece!  Why does it say right there that the frag size is 72? The QoS book says that it should be 160bytes as well.  Now I know multilink PPP will split the traffic among the lines, but I am a bit confused.  Any clarification on why this is happening would be awesome. 

Oh and btw...to clear that pesky neighbor route thats comes with PPP anyways:



C 172.16.12.1/32 is directly connected, Multilink1


just issue the no peer neighbor-route on your multilink interface...annoying.

Shaping...Cont.

I was having some trouble after looking at the output pasted in my previous post regarding shaping.  What is the difference in these commands:

shape average 64000
shape peak 64000

Both have a byte limit of 2000 bytes per Tc, the same Tc, and average rate.  The only differences were the target rate, and increment bytes.  Well, the difference was truly in those numbers.  Sure, both can send 2000 bytes per interval, if the bytes are in the bucket.  But the true difference is that with the shape peak command, the higher number of bits can be realized.  This is because of the increment bytes.  When you shape to the peak you get Bc + Be replenished every Tc, letting you truly send 2000 bytes per interval.  When you shape to the average you only get Bc every Tc, so under periods of high congestion you will only be able to send 1000 bytes, even though you have the ability to send 2000, because your Be bucket is empty, and only your Bc is getting filled back up every Tc.  Once the network becomes a little less congested, you should once again be able to send those 2000 bytes.  Thanks to great archived posts on techexams.net and INE's blog by Petr for clearing this up in my head.

I scheduled my exam for Tues. the 23rd.

Shaping--Part 2

Just following up a bit after my last post.  Remember I ended up shaping to the average with 64000 bps as my shaping rate?  I ended up with a policy that looked like this:

Now I went in a did a bit of reconfiguration. Heres what I did:


R2(config)#policy-map shape_all
R2(config-pmap)#class class-default
R2(config-pmap-c)#no shape average 64000
R2(config-pmap-c)#shape peak 64000


Now look at the output of a show policy-map interface:

So here you can probably see some differences from above.  Right off the bat you should notice that the target rate is double what we had originally configured!  Our bucket of tokens now is Bc + Be, instead of just Bc in our previous example.  We get our target shaping rate from the following formula:
Rate = configured rate(1 + Be/Bc) or 64000 (1+(8000/8000)) or 64000(2)....128

So essentially this guy is configured to send up to 2000 bytes (8000 bits x 2) each 125ms interval (if the bucket(s) have that many tokens of course!).  But also notice the increment bytes in this example.  They are double what they were in the previous example.  This is because when you shape to the peak, Bc + Be are going to be replenished each Tc.

QoS on a Catalyst 2950

Well, hacked away using some commands on a 2950 today, and pushed through the QoS exam guide by Wendell Odom for the second time (this time hand-writing notes).  I feel really comfortable now with the theory, and am trying to apply some hands-on training.  Too bad there are not that many QoS labs guides out there.  Here's what I did...I'll try to explain along the way:


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

*Feb 28 18:41:56 CST: CDP-PA: version 2 packet sent out on FastEthernet0/1no shut
*Feb 28 18:41:56 CST: %TB-5-TRUST_DEVICE_LOST: cisco-phone no longer detected on port Fa0/1, port set to untrusted. \\This happened when I unplugged the phone\\

2950#sh mls qos int fa0/1
FastEthernet0/1
trust state: not trusted
trust mode: not trusted
COS override: dis
default COS: 0
pass-through: none
trust device: cisco-phone


This is a simple...trust the cos values sent by the ip phone if it is discovered on the port using CDP version 2. The switch here is telling it to overwrite packets sent from any connected pc with a COS of 0, or best effort.


2950(config-if)mls qos trust cos
2950(config-if)mls qos cos 7

FastEthernet0/1
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 7
pass-through: none
trust device: none


Here we are trusting the COS markings that come in, and remarking any untagged frames with a COS of 7.


2950(config-if)#mls qos cos override

FastEthernet0/1
trust state: not trusted
trust mode: not trusted
COS override: ena
default COS: 7
pass-through: none
trust device: none


Here we use the override command to say, "I dont care if your tagged with a COS value..we are re-writing you with a COS of 7." You can see the COS override is set to ena...or enabled. This command also turns the trust state to untrusted, so that ALL COS values are overwritten.


2950(config-if)mls qos trust cos

interface FastEthernet0/1
switchport access vlan 19
switchport mode access
mls qos cos 7
mls qos trust cos
spanning-tree portfast
end

2950(config-if)#do sh mls qos int fa0/1
FastEthernet0/1
trust state: trust cos
trust mode: trust cos
COS override: dis
default COS: 7
pass-through: none
trust device: none



This last little bit was just to show that re-using the mls qos trust cos, resets the trust cos, and disables the cos override flag.

Shaping Calculations

Small post here on traffic shaping calculations. I am thinking of taking the 642-642 QoS test next Tuesday, so I am really trying to re-read the book, and drive the topics home with some note-taking and lab exercises. Basically I have a topology that looks like this (sorry for the lack of visio!):

Host1(client)---R1---R2----Server1 (HTTP/FTP)

The access rate of the link (i.e. clock rate is 128000bps), the CIR given by the ISP is 64kbps. So we need to configure shaping so that our ISP does not drop our traffic. This is a REALLY basic example guys. Here is the config on R2 to shape traffic back to R1:


policy-map shape_all
class class-default
shape average 64000
!
interface Serial0/1
bandwidth 64
ip address 172.16.12.2 255.255.255.0
service-policy output shape_all


I then initiated a huge file download using both FTP and HTTP to engage the shaper. Here is the output of my show policy-map interface serial 0/1:

This, needs a bit of explaining. You can clearly see that the offered rate is at or below our configured shaping rate (63,000 bps at the top). Our target rate is what we configured, 64000. The "byte limit" is correct at 2000 bytes because it equals Bc + Be (8000+8000/8). This is how much the router can send per time interval (125ms). So every 125ms the router will send 2000 bytes in order to conform the traffic to 64kpbs. The Bc bucket is 8000 bits, and by default the Be bucket is = Bc bucket. These values were derived from the shaping rule (if shaping rate is < 320kbps then Bc = 8000; if it is greater than 320kbps then Tc defaults to .025 and Bc can be calculated by the formula Bc = Tc*CIR). The last item is the Increment bytes. Tokens are replenished at Bc per Tc. So every 125ms, Bc (or 1000 bytes) will be put back into the buckets.

EEM

A post on techexams.net prompted me to look farther into this.  It is a pretty handy little scripting tool built into the IOS.  I played with a basic one in GNS3 today:


event manager applet ISR_CISCO
 event syslog pattern "Interface FastEthernet0/0, changed state to down"
 action 1.0 cli command "enable"
 action 2.0 cli command "conf t"
 action 3.0 cli command "interface fa0/0"
 action 4.0 cli command "no shut"
 action 5.0 cli command "ip address 192.168.0.1 255.255.255.0"


This will track if fa0/0 goes down, and if it does it will perform a no shut on it...and assign it an IP address.  Ya, I was just playing, but take a look:


Router(config)#int fa0/0
Router(config-if)#shut
Router(config-if)#
*Mar  1 00:04:06.723: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 00:04:07.723: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar  1 00:04:08.299: %SYS-5-CONFIG_I: Configured from console by vty0
*Mar  1 00:04:10.051: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:04:11.051: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
Router(config-if)#
Router(config-if)#
Router(config-if)#
Router(config-if)#exit
Router(config)#exit
Router#w
*Mar  1 00:04:17.815: %SYS-5-CONFIG_I: Configured from console by consolsh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.0.1     YES manual up                    up
FastEthernet0/1            unassigned      YES unset  administratively down down




Pretty slick...heres a link. I will have to come back to this sometime. But I can see its usefulness.
Cisco EEM

Saturday!

Well I am finishing off the 642-642 CBTNuggets today, and purchasing stuff of ebay for my CCIE home rack.  I am planning on using INE's topology, so I am building around that.  Here's what I am getting:

Device	Type	WAN	LAN
R1	2620XM	(2) WIC-1T	FE
R2	2620XM	(2) WIC-1T	FE
R3	2611XM	NM-4A/S	(2)FE
R4	3640	(2) WIC-1T	(2)FE
R5	3640	NM-4T	(2)FE
R6	3640	(1) WIC-1T	(2)FE
SW1	3550
SW2	3550
SW3	3550
SW4	3550
BB1	2620XM	NM-8A/S
BB2	2509		(1) AUI Trans	octal
BB3	2509	1	(1) AUI Trans	octal
Rack-28U

If its yellow I already have it.  The white ones I still need to get.  I am planning on selling (if he still wants it), my current desktop rack (12U) and 24-port 2950 to a co-worker.  I am pretty stoked, I think that its going to be a cool journey.

Juniper SRX 240's

Well we got a pair of these bad boys at work....We clustered them and have them configured for stateful failover.  I am happy to say that for about 3 months I have been immersed in Junos.  All in all, it is a pretty decent operating system.  Coming from Cisco, the information is kind-of similiar, but not really (if that makes any sense).  I did learn through the process that a firm understanding of the technology is needed to be successful.  For a while, I was approaching these guys from a "Cisco" perspective; but I finally accepted the Juniper way of doing things, and it all seemed to work out.  They fail over nicely.  The one HUGE complaint I have is their misrepresented "dynamic" vpn.  First off, every users needs their own IKE gateway, ipsec policy, dynamic-vpn gateway, and vpn acl.  It is ALOT of administrative overhead to get someone configured.  They say this all will be fixed with version 11 next year...we are on 10.1.  Anywho...in order for the "dynamic IPSEC vpn to work...you have to have HTTPS enabled on the external interface they are coming in on.....ridiculous...it make it impossible to NAT anything through 443 on that same IP.  Yet I digress.  They are now working, and will probably be implemented in 2 months after we do VSS on our core switches next month.  Back out to transfer my homebrew into the fermenter :)

QoS 642-642 Progress

So, I finished the QoS book by Odom....awesome read!  I need to go through and make some notes for the chapters though...sort of a second "glance through."  I also picked up the nugget monthly streaming subscription; and am a pretty good way through them now.  Good progress, I need some lab reinforcement and I should be good.  Anyone know any good QoS labs (I have the ONT portfolio....).

Core IOS Upgrades Today

So we updated our two Catalyst 6509's in preparations for the deployment of Cisco's Virtual Switching System next month.  Ran into a weird problem though...well not really a problem, but something funny that I wanted to share.  We all know that these guys parse your configs as they load, well our 6500's must have "parsed" too much.  When we attempted to log in through the console port we kept getting an:  % Error in authentication.  It did this about 10 times before it finally gave us the glorious username prompt.  Just a funny issue more than anything.  Anyone else ever heard of this?  Both cores did it...we upgraded to an SXI3 release.  BTW:  Here were are sup720 upgrade steps

1) TFTP'd the new ios into the sup-bootflash:
2) issued "boot system flash sup-bootflash:" for the new ios...used the "no" version to remove the old statement.
3) checked our boot variables with the show boot command.  Should show the path you put in above.
4) We currently run HSRP, so only for a brief moment was connectivity lost (reboot secondary, then primary).