Breakout switches and IRB don't play well together

I've discovered another possible caveat when using dynamips for your labs, at least when using a breakout switch.  If you're using locally connected interfaces, or not using real switches it's not going to bite you though.

While working IPExpert Volume 1 Workbook Lab 7 which is a frame relay based lab focusing on bridging, I found that when using Dynamips IRB on ethernet interfaces doesn't work as expected when you're using a 3550 as your breakout switch.

This may be related to the one way CDP "feature" due to the 3550 not supporting l2protocol tunnelling on trunk port.

I found it confusing at the time since the bridging was working fine over the frame cloud but not over the ethernet.

This was the irb config I had on R2:

hostname R2

bridge 1 protocol ieee
bridge 1 route ip

bridge irb

interface Serial2/1.205 point-to-point

 description to R5 via Frame
 frame-relay interface-dlci 205
 bridge-group 1
!

interface BVI1
 ip address 150.100.221.2 255.255.255.0
!

This was the irb config I had on R5:

hostname R5

bridge 1 protocol ieee
bridge 1 route ip

bridge irb

interface FastEthernet0/1

 description to R6 and R7 via Cat3
 no ip address
 duplex auto
 speed auto
 bridge-group 1
!
interface Serial2/1.502 point-to-point

 description to R2 via Frame
 frame-relay interface-dlci 5012
 bridge-group 1
!

interface BVI1
 ip address 150.100.221.5 255.255.255.0
!

R6 and R7 are routers with interfaces on directly attached to the 150.100.221.0/24 subnet.

In the end I installed one of the many USB200M Ethernet Adapters I still have before going the breakout switch route in my Ubuntu Server - which was automatically installed as eth2, I edited the lab .net file to have R5 Fa0/1 use eth2, patched it to Cat3 replacing the feed from the breakout switch and fired things up and obtained the expected connectivity.

R2#ping 150.100.221.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.221.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/11/36 ms
R2#ping 150.100.221.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.221.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/24 ms
R2#ping 150.100.221.7

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.221.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/20 ms
R2#show bridge

Total of 300 station blocks, 297 free
Codes: P - permanent, S - self

Bridge Group 1:

    Address       Action   Interface       Age   RX count   TX count
ca05.06f6.0006   forward   Serial2/1.205     0          6          6
ca03.06f6.0006   forward   Serial2/1.205     0          5          4
ca04.06f6.0006   forward   Serial2/1.205     2          6          5

R2#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  150.100.221.2           -   0000.0c81.46a0  ARPA   BVI1
Internet  150.100.221.5          46   ca03.06f6.0006  ARPA   BVI1
Internet  150.100.221.6          46   ca04.06f6.0006  ARPA   BVI1
Internet  150.100.221.7          25   ca05.06f6.0006  ARPA   BVI1
 
R5#sh bridge
Total of 300 station blocks, 297 free
Codes: P - permanent, S - self

Bridge Group 1:

    Address       Action   Interface       Age   RX count   TX count
ca04.06f6.0006   forward   FastEthernet0/1   0          6          5
ca05.06f6.0006   forward   FastEthernet0/1   0          6          5
0000.0c81.46a0   forward   Serial2/1.502     0         15         15
 
R5#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  150.100.220.5           -   ca03.06f6.0008  ARPA   FastEthernet0/0
Internet  150.100.221.2          24   0000.0c81.46a0  ARPA   BVI1
Internet  150.100.221.5           -   ca03.06f6.0006  ARPA   BVI1
Internet  150.100.221.6          45   ca04.06f6.0006  ARPA   BVI1
Internet  150.100.221.7          24   ca05.06f6.0006  ARPA   BVI1


Not necessarily a show stopper but something to be aware of when you're doing a lab and things appear to be correctly configured but aren't working.  It's good to know that I'm not alone with making this observation.  There's something certainly to be said for having plenty of interfaces directly attached to your dynamips box and not needing the breakout switch.

Started IPExpert Volume 1 Workbook

I have completed the first three labs in the IPexpert Volume 1 Workbook which have been focused on Switching.  While a good number of the tasks are relatively straight forward, some of the tasks introduced some things that I wasn't aware of until looking at the Detailed Solution Guide to track how I went.

One of the commands, that I found interesting which I don't think was specifically mentioned in any of the material I've examined so far (but is there for the looking in the config guide) introduced in one of the tasks is the "switchport protected" command.  It is basically a cut-down version of private-vlans.  The scope of function is switch wide and it basically enables "isolated ports" on the same VLAN - any port or SVI that is not specifically "switchport protected" is basically a promiscuous port.

With the lab exercises, usually initial configurations for LAN switches and Routers are provided which are designed to work on the Proctor Labs equipment and I don't have the same setup which means I need to modify the configs a little.

Below is a pretty simple bash script that uses sed to modify the configs to suit my equipment.


#!/bin/bash

# This script modifies the IPexpert initial configs to match my hardware
# Cat1 + Cat2 = 3750
# Cat3 + Cat4 = 3550
# R1 - R9 = 7200
# BB1 - BB3 = 2611

TEMPFILE="/tmp/rework.sed"
if [ -f $TEMPFILE ]
then
  rm $TEMPFILE
fi

# IPexpert's R2 has Gigabit Ethernet Interfaces - our R2 only has FastEthernet
# Comment out the media-type line
if [ -f R2.txt ]
then
    sed -e 's/GigabitEthernet0/FastEthernet0/g' \
        -e 's/media-type/! media-type/g' \
        R2.txt > $TEMPFILE
        mv $TEMPFILE R2.txt
fi


# Change the Interface numbers to match with my 3750
# Gi0/2 will eventually become a copper SFP but at present we will map it to Fa1/0/12
if [ -f Cat1.txt ]
then
    sed -e 's/FastEthernet0\//FastEthernet1\/0\//g' \
        -e 's/GigabitEthernet0\/2/FastEthernet1\/0\/12/g' \
        -e 's/GigabitEthernet0\//GigabitEthernet1\/0\//g' \
        Cat1.txt > $TEMPFILE
        mv $TEMPFILE Cat1.txt
fi


# Change the Interface numbers to match with my 3750
if [ -f Cat2.txt ]
then
    sed -e 's/FastEthernet0\//FastEthernet1\/0\//g' \
        -e 's/GigabitEthernet0\//GigabitEthernet1\/0\//g' \
        Cat2.txt > $TEMPFILE
        mv $TEMPFILE Cat2.txt
fi

# Change the Serial Interfaces to match the emulated routers
for R in R*.txt
do
    sed -e 's/memory-size/! memory-size/g' \
        -e 's/Serial0\/0\/0/Serial2\/0/gI' \
        -e 's/Serial0\/1\/0/Serial2\/1/gI' \
        -e 's/Serial0\/2\/0/Serial2\/2/gI' \
        -e 's/Serial0\/2\/1/Serial2\/3/gI' \
        -e 's/S0\/0\/0/Serial2\/0/gI' \
        -e 's/S0\/1\/0/Serial2\/1/gI' \
        -e 's/S0\/2\/0/Serial2\/2/gI' \
        -e 's/S0\/2\/1/Serial2\/3/gI' \
        $R > $TEMPFILE
        mv $TEMPFILE $R
done

Status Update

Since I have sat through the IPExpert Video on Demand Course I will very shortly start to go through the Volume 1 Workbook which I think is an important thing from being a spectator to executing tasks on my own.

All in all I think that the Video on Demand course has been good value.  While described as a 4 day course, it is much more than 8 hours per day - I especially recall Day 2 lasting a long time - it covers both lectures and configuration exercises for IGPs and BGP.   While I did like the work of seeing config/show/verify connectivity and the associated troubleshooting skills - sometimes it just took a very long time to resolve issues, because its in recent memory the configuration video for IPv6 which ended up having a multicast issue was somewhat annoying to see Joe spending an hour trying to troubleshoot things of his own design - I guess it was good to show the fundamentals but it frustrating at the same time.  That said I most certainly appreciated that he followed up with what the issue was, how to replicate it and the work around was.  Considering the body of knowledge that Joe was sharing and his professional attitude in describing his thought processes and not getting worked up when things weren't acting immediately as expected - the previously mentioned annoyance I mention is really the only negative I can give for the whole experience and in its own way should be a positive (if a little time consuming)

I am certain I will be revisiting some of these videos through out my study.