Friday Morning Fun - 11/30/2007

November 30th, 2007 neteng

Welcome to the first edition of FMF. I thought it would be fun to post some lighter content on Fridays to help people begin their relaxing weekend (well, I’ll be doing practice labs all weekend, but you get the point…). :)

Have a great weekend everyone.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in FMF, News | 1 Comment »

Fallback Bridging

November 29th, 2007 neteng

Today, I want to take a closer look at one of the more overlooked topics when it comes to switch configuration: Fallback Bridging. In a world of IP-based applications, few of us rarely come into contact with legacy applications and protocols that may require the use of bridging. But being that a CCIE is considered an Internetworking Expert, it’s something candidates will need to know for the lab exam. And if you ever work in a large enterprise, you may run into this when dealing with old mainframes and ancient equipment.

So let’s go ahead and see what this fallback bridging, aka VLAN bridging, is all about when configured on the Catalyst 3550/3560 platforms. Its main use is to allow machines that speak non-routed or non-supported protocols (SNA, DECNet, AppleTalk, etc.) to communicate across VLANs and routed ports. The idea is to put Switched VLAN Interfaces (SVI) and routed ports (no switchport) for which you want to bridge traffic, into a common bridge group. On the 3550, you’re limited to 31 simultaneous bridge groups (32 on the 3560) and an interface can be a member of only a single bridge group. Another important point to remember is that each VLAN has its own spanning-tree instance. It runs on top of the bridge group to prevent loops.

As always, things are best explained through an example:

Fallback Bridging

If we were asked to configure the switch in the diagram, here’s what we’d do:

CCIE-SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CCIE-SW2(config)#bridge 1 protocol vlan-bridge
CCIE-SW2(config)#int vlan1
CCIE-SW2(config-if)#bridge-group 1
CCIE-SW2(config)#int vlan2
CCIE-SW2(config-if)#bridge-group 1
CCIE-SW2(config)#int fa0/1
CCIE-SW2(config-if)#no switchport
CCIE-SW2(config-if)#bridge-group 1

Now let’s verify that our config took:

CCIE-SW2#sh bridge 1 group

Bridge Group 1 is running the VLAN Bridge compatible Spanning Tree protocol

Port 28 (Vlan1) of bridge group 1 is forwarding
Port 30 (Vlan2) of bridge group 1 is forwarding
Port 31 (FastEthernet0/1) of bridge group 1 is up

That’s all there is to it. Now the switch will build a bridging table and bridge all packets between those interfaces except the following: IPv4 & IPv6, ARP, RARP, LOOPBACK, and Frame Relay ARP.

For more information:

Cisco Documentation: Configuring Fallback Bridging

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in Networking, Routing, Switching | 2 Comments »

Train Signal - CCNP CBT Review

November 29th, 2007 neteng

I’ve now had a chance to go through Train Signal’s CCNP discs (specifically for the BSCI & BCMSN exams). The user interface and extras (test exams and lab workbooks) remain the same from their CCNA series. The topic coverage is very broad but Chris managed to tackle each one with a good level of detail. I think CCIE-wannabes like myself will also find parts of this useful as a refresher. A nice addition that I found was the inclusion of the slides used by the instructor, in PDF format. These contained a space to write notes in next to each slide; a good idea for capturing those key terms and gotchas that will be helpful, come review time.

Overall, I’m quite impressed with Train Signal’s product. I’d say they’re a good investment as you work your way towards Cisco certification.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in Reviews | No Comments »

Train Signal - CCNA CBT Review

November 28th, 2007 neteng

Some time ago, Scott Skinger from Train Signal was generous enough to send me copies of their CCNA and CCNP training material. I appreciate his patience as it’s taken me a long time to finally post a review! I’ll cover the CCNP products in another post, but I had a moment to sit down and go through the CCNA goods.

Overall, I found the presentation and material coverage to be quite impressive. I never used CBT material for any of my tests, but after going through the lessons, I realized it would have saved me some time and headaches! Chris Bryant (CCIE #12933) is the instructor for both the CCNA and CCNP series’ and he does a great job of covering important fundamentals for the CCNA aspirant. I especially enjoyed his coverage of binary/decimal conversion. As anyone involved in networking can tell you, knowing this information will help you maintain your sanity when it comes to subnetting, CIDR and wildcard masks. Another highlight was the segment on putting together your own lab and rack rentals. Included with each CBT video is a testing application and a PDF document for lab work. I thought the lab workbook was a fantastic addition as it allows the student to get their hands dirty and apply what they’ve learned from the videos.

Unfortunately, the copy I received was geared towards the previous CCNA exam, so some of the older topics like ISDN were still covered. Useful if you work with ISDN, but not so much for the test. Also, there were some topics missing, like wireless, that appear in the the new CCNA blueprint. But, I’m sure the material has been updated since the changes were made official.

If you’re studying for your CCNA and looking for informative visual and hands-on lessons, you will definitely want to give Train Signal’s product a look.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in Networking, Reviews | 1 Comment »

101 Best Web Freebies

November 27th, 2007 neteng

While I’m putting more lab material together, I wanted to keep the ball rolling on this blog. I was sent an excellent link today, put together by BusinessWeek:

101 Best Web Freebies

There are some of the obvious tools in there: Skype, Ubuntu, etc.

But I also found some gems that folks might not know about:

  • Pandora Recovery - File recovery
  • Libra - Book and Media organizer
  • Mint.com - Financial Managment site (I highly recommend this..been using it for 3 months and love it. Like Quicken, but MUCH simpler and web-based).

That’s just a few of the links…Check it out for yourself.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in Links | No Comments »

PIM Sparse Mode - BSR

November 26th, 2007 neteng

Welcome back everyone. I hope you guys were smart enough to avoid following my lead this past weekend and not stuff yourself silly. I’m growing feathers from all the turkey I ate! But I digress…We’re back in action for awhile and I hope to have some good material coming your way.

Let’s begin where we left off and take a look at our common PIM network. We’ve seen static RP assignments and Auto-RP at work, so now we’ll take a look at BSR. It’s really not very complicated if you’re familiar with Auto-RP and you’ll see what I mean as we go through the configuration. The BSR router plays a similar role to the Auto-RP Mapping Agent, but it performs one major function differently. The Auto-RP MA elects an RP based on the announcements it receives from candidate-RPs (C-RP). The BSR router actually sends all mapping possibilities to every PIM router and allows them to elect an RP. They will elect the same RPs for each group though, as every PIM router uses the same hash algorithm.

PIM - Sparse Mode - BSR

First, we’ll configure R3 to be our C-RP:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip pim rp-candidate lo0

Now let’s verify:

R3#sh ip pim rp map
PIM Group-to-RP Mappings
This system is a candidate RP (v2)

Next, let’s configure R2 to be our BSR:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip pim bsr-candidate lo0

Let’s verify that everything is working as it should be now:

R2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 192.168.23.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:00:54, expires: 00:01:33

You can see that R3 has been selected as the RP for all multicast groups. Now we’ll ping from our R1 multicast source to R6 and see what happens:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 452 ms

You can see that R5 is using R3 as it’s RP. This was learned as the BSR sent the announcement to each PIM router (224.0.0.13), and each PIM router forwarded this announcement to it’s neighbors at the same address. Let’s take a look:

R5#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2
Info source: 150.1.2.2 (?),via bootstrap, priority 0, holdtime 150
Uptime: 00:06:41, expires: 00:02:01

Here’s our mroute table on R5:

R5#sh ip mroute
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.39.39.39), 01:29:37/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 01:29:37/00:02:31

(192.168.12.1, 239.39.39.39), 00:02:56/00:00:10, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:02:56/00:02:31

(*, 224.0.1.40), 01:30:15/00:02:27, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 01:30:15/00:02:27

As far as basic BSR setup, that’s all there is to it! If you have multiple BSRs, the one with the highest priority will be elected. If they all have the default Cisco priority of 0, then the BSR candidate with the highest IP address will be chosen. If you have multiple RP candidates seeking election, then the BSR will also elect the RP based on the same priority/IP address system.

I hope you’ve found this series of PIM labs useful. I haven’t quite decided what to tackle next, but have some ideas in mind. Suggestions are always welcome! In the meantime though, expect to see a review of CCNA/CCNP training materials provided by our friends at TrainSignal.

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »

Monday Morning Networking - 11/26/2007

November 26th, 2007 neteng

Welcome to the first edition of MMN. I’m getting back into the swing of things after the Thanksgiving holiday here in the U.S. I’m currently working on the “PIM sparse mode with BSR” lab, so in the meantime, here are some good links to check out:

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in MMNN, News | 1 Comment »

PIM Sparse Mode - Auto RP

November 21st, 2007 neteng

Ok, so I told a small fib in my last post…But this really is the last post for this week! :) I finished up this lab and decided to go ahead and post it today. We’re using our familiar topology but we’ll be moving away from static RP assignments and using Cisco’s Auto-RP:

PIM Sparse Moded - Auto RP Lab

We’ve designated R3 as our Rendezvous Point (RP) and R2 as our Mapping Agent (MA). As a quick refresher, the RP acts as the root of the shared distribution tree and the MA is in charge of mapping RPs to multicast groups and disseminating that information out to multicast-participating routers. The dynamic RP system makes for a much simpler setup when you need to make changes in the future. Instead of having to update each individual router with new RP information, you just need to touch a few pieces.

The first thing we’ll want to do is assign our RP-candidate. We’ll do that as follows:

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip pim send-rp-announce lo0 scope 16

As you can see, we’re having R3 announce it’s loopback address (150.1.3.3) as a candidate for RP assignment. The scope requirement on this command sets the TTL on the announcement packets, in order to limit how far they can go. I just picked an arbitrary number of 16. This command tells the router to send an announcement to 224.0.1.39, which every mapping agent is listening on. Now let’s verify that this router is set to announce itself as an RP:

R3#sh ip pim rp map
PIM Group-to-RP Mapping
This system is an RP (Auto-RP)

Next, we’ll assign the mapping duties to R2:

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int lo0
R2(config-if)#ip pim sparse-mode
R2(config-if)#exit
R2(config)#ip pim send-rp-discovery lo0 scope 16

We had to make sure to configure PIM on R2’s loopback interface so it could participate. Now let’s verify that R2 is configured correctly:

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 150.1.3.3 (?), v2v1
Info source: 150.1.3.3 (?), elected via Auto-RP
Uptime: 00:00:10, expires: 00:02:49

We now see that R2 is our mapping agent and has already picked up the RP announcement coming from R3. It will now announce the RP assignment to multicast group 224.0.1.40 on which the PIM-configured routers listen. For curiosity’s sake, let’s see what would happen if we also configured R5 to also announce itself as an RP:

R2#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 150.1.5.5 (?), v2v1
Info source: 150.1.5.5 (?), elected via Auto-RP
Uptime: 00:05:50, expires: 00:02:08
RP 150.1.3.3 (?), v2v1
Info source: 150.1.3.3 (?), via Auto-RP
Uptime: 00:24:37, expires: 00:02:23

R5 is now the RP of choice as it won out over R3. This is because of the higher IP address on R5. If R5 were to die, R2 would assign the RP duties to R3 to keep things going.

Ok, let’s take R5 out of the RP game and put things back to where they were. Now we’ll ping from R1 to the 239.39.39.39 group again (of which R6 is a member). Here is what our mroute table will look like on R5:

R5#sh ip mroute
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.39.39.39), 00:01:29/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:01:29/00:02:23

(192.168.12.1, 239.39.39.39), 00:00:04/00:02:55, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:00:04/00:02:55

….unnecessary info omitted….

Results from our ping:

R1#ping 239.39.39.39

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.39.39.39, timeout is 2 seconds:

Reply to request 0 from 192.168.56.6, 468 ms

Hope this was informative! We’ll return with a vengeance next week and tackle BSR along with other exciting topics. Enjoy the long weekend…

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in HOWTO, Multicast, Networking, Routing | 2 Comments »

Happy Turkey Week

November 20th, 2007 neteng

Sexy Turkey

I’m taking a break from blogging for the rest of the week. For those who celebrate, have a great Thanksgiving!

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in Uncategorized | 1 Comment »

PIM Sparse Mode - Static RP

November 20th, 2007 neteng

Welcome back to the PIM show! I know you’re just chomping at the bit to continue our PIM routing escapades, so we’ve come back to another lab…this time featuring sparse mode routing. We’re going to use the same topology as our dense mode lab and tweak things a little bit. For this lab, we’re just going to implement a static RP device. After this lab, we’ll dive into Auto-RP & BSR. Here’s our sparse mode topology:

PIM Sparse Mode - Static RP - Lab

We’re going to use the loopback0 interface of R3 as the RP address. This address must be reachable via our IGP. The first thing we’ll want to do is enable PIM on the loopback interface:

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int lo0
R4(config-if)#ip pim sparse-mode
R4(config-if)#exit
*Nov 20 09:19:23.503: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 150.1.3.3 on interface Loopback0

Next, we need to statically assign the RP to each router participating in PIM (R2, R3 and R5):

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip pim rp-address 150.1.3.3

It’s important that remember to configure this on our RP as well, because it will not accept it’s status as an RP and you’ll get a message such as this:

*Nov 20 10:38:15.419: %PIM-1-INVALID_RP_REG: Received Register from router 192.168.23.2 for group 239.39.39.39, 150.1.3.3 not willing to be RP

We can verify that the RP is now assigned with the following command:

R2#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
RP: 150.1.4.4

As you can see, the default mapping for the RP assignment is for all IP multicast groups. If you wanted to, you could have multiple RPs for different multicast groups by using ACLs. It could look something along the lines of this:

access-list 1 permit 239.0.0.0 0.255.255.255
ip pim rp-address 150.1.3.3 1
ip pim rp-address 150.1.4.4

This is saying “I want to use R3 as my RP for all multicast traffic going to 239.x.x.x.”
Here is what our mappings would look like in conjunction with the first assignment:

R3#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static
RP: 150.1.4.4 (?)
Acl: 1, Static
RP: 150.1.3.3

Okay, now lets do a test ping from R1 to R6 (who is still joined to our 239.39.39.39 group from our previous dense-mode lab, via the ip igmp join-group command) and see how our mroute table looks from R5’s perspective:

R5#sh ip mroute
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.39.39.39), 00:05:01/stopped, RP 150.1.3.3, flags: SJC
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:05:01/00:02:58

(192.168.12.1, 239.39.39.39), 00:02:28/00:02:20, flags: JT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:02:28/00:02:58

(*, 224.0.1.40), 00:05:05/00:02:58, RP 150.1.3.3, flags: SJPCL
Incoming interface: FastEthernet0/0, RPF nbr 192.168.35.3
Outgoing interface list: Null

As you can see, we have our (*, 239.39.39.39) group which is part of the shared tree initially created by PIM sparse mode. Once the source-based tree is built, multicast packets are no longer forwarded along the shared tree and therefore you see the stopped message in the shared tree entry. In our case, the topology is pretty limited so the shared tree and source-based tree are essentially the same.

That’s all there is to it. I hope this was useful for you. As always, comments are welcome!

neteng

Buy Me a Beer! Help me keep my sanity as I write more articles.

Posted in HOWTO, Multicast, Networking, Routing | 1 Comment »