Posted on Monday, 11th September 2006 by sean
I got a chance to look at the new CCNA Video Mentor (CVM) by Wendell Odom. It’s a 2 hour Video on CD (all Flash videos) on a variety of topics that’s meant to go alongside the
CCNA Official Exam Certification Library (Exam #640-801), 2nd Edition. The videos are really worked through labs to solidify specific topics, as opposed to generic learning.
Read the rest of this entry…
Posted in Reviews | Comments (1)
Posted on Friday, 18th August 2006 by sean
Often network folk have to make quick estimates without benefit of calculators, measuring tapes, or other handy things. I was thinking about this the other day, and thought I’d post some of the techniques I use.
- I’m 6′ tall, so my armspan is about 6′. Great for measuring the length of cables
- One big pace is about a meter (or 3′)
- Every megabit per second of bandwidth will transfer about half a Gig of data per hour, at best.
- having a rough idea of the cost of a switch, GBICs, and installation, rough guesses for the cost of data circuits (operational and capital), internet bandwidth costs
Any others?
Posted in General | Comments (2)
Posted on Thursday, 17th August 2006 by sean
I just got back from passing 642-811. Even though I ended up with a 962 the number of questions that I thought “I think that’s the right answer” would have made me think my score would have been lower (though as I go back and check, it looks like I was right on most)
Compared with the previous incarnation, this one is far more in depth — more analysis of spanning trees, in depth question on multicast, HSRP, GLBP. Several questions where you were given some show commands or debugs and asked to interpret what’s going on. The simulations were very straightforward.
Read the rest of this entry…
Posted in Reviews, Switching | Comments (1)
Posted on Tuesday, 15th August 2006 by sean
The CCNP track is being updated. Have a look at the new CCNP prep centre: http://www.cisco.com/go/prep-ccnp
Press release: http://biz.yahoo.com/bw/060815/20060815005343.html?.v=1
Summary of the changes (from the prep centre)
642-821 BCRAN becomes 642-825 ISCW Implementing Secure Converged WANS:
Security, DSL and MPLS added
642-831 CIT becomes 642-845 ONT Optimized Converged Cisco Networks:
QoS and WAN added
642-801 BSCI becomes 642-901 BSCI Building Scalable Cisco Internetworks:
Routing Protocols at Campus Edge added
642-811 BCMSN becomes 642-812 BCMSN Building Cisco Multilayer Switched Networks:
Campus Switch Networks and Wireless LANs added
The BCRAN replacement looks the most interesting.
Posted in General | Comments (1)
Posted on Tuesday, 11th July 2006 by sean
Implementation of multicast, at least for the purposes of the CCNP BCMSN exam, is pretty simple. Cisco has the Multicast Quick-Start Configuration Guide which goes over many different ways of doing it.
The exam seems to only care about Protocol Independent Multicast (PIM), which uses the router’s routing table to determine whether or not a multicast packet is to be forwarded. When packet is received on an interface the router looks at the route back to the source. If the interface the packet was received on is the same as the one it would use to send a response, the reverse path forwarding test is sucessful and the packet is forwarded.
PIM operates in two modes, sparse and dense. In sparse mode it is assumed that most people don’t care about the stream and therefore the router must explicity add branches to the multicast tree. In dense mode it is assumed that there are a lot of listeners, and it is the obligation of the router to prune. This is handled through IGMP which is another article.
Consider the following network:
R5 has its E0 interface shut down so that the serial link is used.
I set up everything in PIM dense mode, meaning I needed only
ip pim dense-modeon every interface.
From R0
r0#show ip pim neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
2.2.2.1 Multilink1 1d02h/00:01:43 v2 1 / S
10.50.0.3 Ethernet0 1d02h/00:01:24 v2 1 / DR S
the output of that shows two PIM adjacencies, one out the multilink (R1) and one on the Ethernet (R3). Under the "Mode" column, S means "state refresh capable" and DR means that the router is the designated router for the segment.
To test multicast, I used Multicast Routing Monitor to generate traffic:
r1#show run int mu1
Building configuration...
Current configuration : 138 bytes
!
interface Multilink1
ip address 2.2.2.1 255.255.255.252
ip pim sparse-mode
ip mrm test-sender
ppp multilink
multilink-group 1
end
R0:
ip mrm manager test1
manager Ethernet0 group 239.1.1.1
senders 1
receivers 2 sender-list 1
access-list 1 permit 2.2.2.1
access-list 2 permit 5.5.5.5
access-list 2 permit 10.50.0.3
r3#show run int e0
Building configuration...
Current configuration : 111 bytes
!
interface Ethernet0
ip address 10.50.0.3 255.255.255.0
ip pim sparse-dense-mode
ip mrm test-receiver
end
A similar receiver exists on R5's loop0.
The mrm tester on R0 sets up a multicast stream from 2.2.2.1 to 5.5.5.5 and 10.50.0.3 using multicast group 239.1.1.1:
r0#show ip mrm manager
Manager:test1/10.50.0.1 is not running
Beacon interval/holdtime/ttl:60/86400/32
Group:239.1.1.1, UDP port test-packet/status-report:16384/65535
Test senders:
2.2.2.1
Test receivers:
5.5.5.5 10.50.0.3
Finally, the test can be started:
r0#mrm test1 start
r0#
1d03h: IP MRM test 'test1' starts ......
1d03h: IP MRM status report -- Test:test1 Receiver:10.50.0.3
1d03h: Sender:2.2.2.1 Pkt Loss:1(4%) Ehsr:8
1d03h: IP MRM status report -- Test:test1 Receiver:5.5.5.5
1d03h: Sender:2.2.2.1 Pkt Loss:5(20%) Ehsr:0
1d03h: IP MRM status report -- Test:test1 Receiver:10.50.0.3
1d03h: Sender:2.2.2.1 Pkt Loss:1(4%) Ehsr:8
1d03h: IP MRM status report -- Test:test1 Receiver:5.5.5.5
1d03h: Sender:2.2.2.1 Pkt Loss:5(20%) Ehsr:0
1d03h: IP MRM status report -- Test:test1 Receiver:5.5.5.5
1d03h: Sender:2.2.2.1 Pkt Loss:15(60%) Ehsr:0
1d03h: IP MRM status report -- Test:test1 Receiver:5.5.5.5
1d03h: Sender:2.2.2.1 Pkt Loss:20(80%) Ehsr:0
1d03h: IP MRM status report -- Test:test1 Receiver:5.5.5.5
1d03h: Sender:2.2.2.1 Pkt Loss:25(100%) Ehsr:0
1d03h: IP MRM status report -- Test:test1 Receiver:5.5.5.5
1d03h: Sender:2.2.2.1 Pkt Loss:25(100%) Ehsr:0
I see a bit of loss at the beginning, but after that it stops:
r0#show ip mrm manager
Manager:test1/10.50.0.1 is running, expire:23:56:53
Beacon interval/holdtime/ttl:60/86400/32
Group:239.1.1.1, UDP port test-packet/status-report:16384/65535
Test senders:
2.2.2.1 /Ack
Test receivers:
5.5.5.5 /Ack 10.50.0.3 /Ack
From R5, looking at the multicast route:
r5#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:06:43/stopped, RP 10.50.0.3, flags: SJPC
Incoming interface: Ethernet0, RPF nbr 10.50.0.3
Outgoing interface list: Null
(2.2.2.1, 239.1.1.1), 00:06:43/00:02:54, flags: PTX
Incoming interface: Ethernet0, RPF nbr 10.50.0.1
Outgoing interface list: Null
r0#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 01:27:52/stopped, RP 10.50.0.3, flags: SJCF
Incoming interface: Ethernet0, RPF nbr 10.50.0.3
Outgoing interface list:
Multilink1, Forward/Dense, 01:27:52/00:00:00
(2.2.2.1, 239.1.1.1), 01:27:52/00:02:51, flags: FT
Incoming interface: Multilink1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0, Forward/Dense, 00:05:32/00:00:00, A
r3#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 01:28:24/00:03:25, RP 10.50.0.3, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0, Forward/Sparse-Dense, 01:28:23/00:03:25
(2.2.2.1, 239.1.1.1), 01:28:24/00:02:59, flags: PLT
Incoming interface: Ethernet0, RPF nbr 10.50.0.1
Outgoing interface list: Null
Posted in Routing, Switching | Comments (1)
Posted on Monday, 10th July 2006 by sean
I labbed up some Multicast stuff a while ago and only now am sitting down to write it. I’d like to write BCMSN by the end of the month because I’m taking two weeks off at the beginning of August where I won’t be near the Internet (or my routers) too often.
Multicast is “one to many”, rather than “one to one” for unicast, and “one to all” for broadcast. The basic premise is that one host sends a packet to a multicast group, and only people interested get the traffic. The trick here is how to serve traffic to interested people while not flooding the network unnecessarily.
“Unnecessarily” means that the network doesn’t have to carry the traffic multiple times. If a multicast stream goes to 5 people, only one copy is sent. Routers and switches replicate the traffic as necessary, ensuring that traffic is kept to a minimum.
Multicast uses the class D address space, from 224.0.0.0 to 239.255.255.255. 224.0.0.0/24 is reserved for local LAN use (ie traffic that shouldn’t cross a router), 224.0.1.0/24 is for network control, and 239.0.0.0/8 is the “Administratively Scoped”, ie local use block. There are some other designations, but those are the main ones.
A host sends a packet to a multicast address, and never from. However there must be a layer 2 address to send the traffic to, one that must be recognized as a multicast and treated appropriately.
The IP multicast address consists of 28 bits. The ethernet multicast consists of 23. Thus, 5 bits are ignored, leading to 32 IP multicast addresses corresponding to each MAC address.
To convert from IP to MAC, simply take the 23 lower order bits of the IP address and prepend 01.00.5e. So, 224.0.0.1 becomes 0100.5e00.0001. The easiest way (that I can think of is)
- write down 0100.5e and ignore the first (from the left) octet of the IP address
- If the second octet of the IP is > 128, then subtract 128 from it (to compensate for the ignored 24th bit)
- convert the three octets to hex and copy into the MAC address
Likewise, to go from MAC to IP
- Drop the 0100.5e
- Convert each pair of nybbles left into decimal
- The valid multicast groups are then {224-239}.{x1,y1}.x2.x3 where y1 = the first decimal number + 128
ie
0100.5e10.7101 becomes 0×10, 0×71, 0×01 which is 16 113 1
Valid multicast addresses are then 224.16.113.1, 224.144.113.1, 225.16.113.1, and so forth.
Next up is some sample PIM configuration and how to test multicast. I’m not sure how detailed the exam gets, from what I’ve heard it’s pretty light, focusing mostly on the above.
Posted in Switching | Comments (0)
Posted on Thursday, 8th June 2006 by sean
Just a note while I come up for air…
On most switches with a hardware priority queue (egress expedite queue) like the 3550, it’s statically assigned to queue 4 (on switches with 4 queues). Some switches like the 4500s let you switch the queue, but generally it’s on silicon so you’re stuck. No problem.
However, on the 3560 it’s queue 1. Luckily the commands are different (wrr-queue vs srr-queue) but it’s not exactly obvious that the pq isn’t in the same place.
I haven’t checked the 3750 series, I suspect they’ll also be on queue 1.
Posted in General, Switching | Comments (1)
Posted on Sunday, 14th May 2006 by sean
As promised, here’s some posts from other network blogs that were submitted (some people submitted their site instead of an article, so I picked one). In no particular order:
Understanding OSPF Default Route Generation
Récupère les infos de tes routeurs Cisco avec un super script TCL (Retrieve information about Cisco routers with a super TCL script – Translate to English
Route Summarization
Network Redundancy, Integrity and Reliability…Oh My!
QoS Classification in a Nutshell
Thanks to those that sent me a link, and please repost the above list on your blog so that others can find all these great sites!
I’ll do this again next Sunday, so drop me a link to an article by next Saturday evening.
Posted in Roundup | Comments (2)
Posted on Thursday, 11th May 2006 by sean
Recently I’ve been spending a lot of time dealing with Quality of Service (QoS) for voice, so this article will be an introduction to the topic.
QoS involves giving better treatment to some traffic at the expense of others. It’s not going to make any more data fit on the pipe, it just tries to make all the applications happy. Take for instance VoIP and FTP. VoIP needs only a bit of bandwidth (<100Kbit/sec for a G.711 call), but if there is jitter (variation in latency) the call suffers. FTP doesn’t care about delay or latency, it’ll take as much of the pipe as it can handle (or is constrained because of TCP windowing). Here, the goal of QoS would be to make sure the voice gets the jitter control it needs. If we added in another application such as a CRM tool, we might give bandwidth guarantees to it such that voice gets the priority treatment, CRM gets enough bandwidth to do what it needs, and FTP gets the rest. We could also limito FTP. Such are the decisions necessary when designing QoS policies.
Posted in General | Comments (0)
Posted on Sunday, 7th May 2006 by sean
I was going through my feeds this morning and realized I’m up to 4 other Cisco related blogs (see sidebar), not to mention a few other blogs that occasionally post networking related stuff. This is great! I’ve learned a lot of great tips by reading these blogs, and through my own writing, have talked to many interesting people. So, I have a proposal.
If you have a blog, send me a link to a favourite recent post of yours by Sunday May 14, 2006. The only restriction is that it has to be networking related (ie you don’t have to have a Cisco blog). On Sunday evening I’ll make a post with links to all of them. If you sent me a post, I’d appreciate your reciprocating by posting the list to your own blog.
This isn’t an original idea, I’ve seen it done on other blogs. But it’s an effective method of cross promotion, and brings other visitors that might not otherwise have known about your blog. If it works for all of us, we can do this every couple of weeks, choose topics, etc.
Please share your ideas or links in the comments.
Posted in General | Comments (5)
I'm a happy Linode customer. This is a Linode 540 VPS.