Bridging by bestt571


More Info
									Certification Zone - Tutorial                                                                       Page 1 of 23


                                                                                           by David Wolsefer

    The IEEE / DEC Spanning Tree
   Transparent Bridging (TB)
    Concurrent Routing and Bridging (CRB)
    Integrated Routing and Bridging (IRB)
   Source Route Bridging (SRB)
    Route Information Indicator (RII)
    Route Control Field (RC)
    Route Descriptor Field (RD)
    Source Route Transparent Bridging (SRT)
    Source Route Translational Bridging (SR/TLB)
    Bit Ordering - Canonical vs. Non-Canonical
   Multiport Bridges
   Remote Source Route Bridging (RSRB)
   Data Link Switching Plus (DLSw+)
   Encapsulation Bridging
   Access Lists for Non-routable Traffic
    NetBIOS Access Lists
    MAC Address Access Lists
    LSAP Address Access Lists

   I am writing this paper from the perspective of someone who has taken and passed the written CCIE
   exam in routing and switching. Although the focus of this paper will be on preparation for the written
   exam, I will also discuss some important points for the lab exam, which I recently tested during a trip
   to Halifax for the actual CCIE lab exam. It is with my own experience in mind that I will present this
   material. This paper will cover the material one needs to know in order to correctly understand the
   concepts behind bridging issues. Unless one understands the concepts behind all topics covered on both
   the written and the lab exams, one cannot hope to provide the correct answer. In short, guessing does
   not work very well at the CCIE level. With this in mind, let us examine the CCIE Routing and Switching

   The written qualification exam, 350-001, allows 2 hours to complete 100 questions and the minimum
   passing score is now 70%. A logical question to ask is "how does the written exam differ from the
   practical lab exam?" The answer to this question, however, is not so simple because both exams can
   cover any topic dealing with the Cisco IOS, bridging, routing, and switching. One can make a
   distinction, however, in that the written exam requires a broad knowledge of a wide array of topics,
   while the lab exam requires a more detailed focus on configuration.

   The CCIE certification carries with it a great deal of prestige precisely because Cisco's exams differ from
   other vendors' exams in that one must actually know the material. One cannot memorize answers to
   exam questions provided in "braindumps" and hope to pass. The material covered is too vast and the 5/31/2005
Certification Zone - Tutorial                                                                        Page 2 of 23

   questions too detailed. One simply must know the material. So what is on the test? Luckily, Cisco
   provides the answer on their web site.

   Cisco's Blueprint for the 350-001 CCIE Routing and Switching Qualification Exam breaks down Bridging
   and LAN Switching into four sections. This paper will not only cover the first two sections, but will also
   cover some additional material such as encapsulation bridging and LAT. Cisco provides the entire
   blueprint at the following URL:

   (CertificationZone is not associated with Cisco.)

   Since this is a CCIE-level paper, I am going to make several assumptions. The first assumption is a
   general understanding of what Ethernet and Token Ring are and the basics of how they work. The
   second assumption is that the reader is already proficient at binary and hexadecimal math.

   Why is bridging important? After all, we all know that bridges are outdated devices that have been
   replaced with switches in the production environment. At casual glance, bridging seems to be an
   outdated topic, but it just is not so. Bridging is actually a cutting edge topic due to the advent of layer 3
   switching. A fundamental understanding of bridging will become even more important as more and
   more companies move to wire speed layer 3 solutions. Before we can discuss bridging in depth,
   however, we need to cover some terminology and discuss the IEEE/DEC spanning tree and Bridge
   Protocol Data Units.

   The IEEE / DEC Spanning Tree
   A redundant network design often allows for multiple paths in case of a hardware failure, but this can
   result in a looped topology. Examine Figure 1. 5/31/2005
Certification Zone - Tutorial                                                                     Page 3 of 23

                                                   Figure 1.

   With transparent bridging configured on R1, R3, and R4 above, we can see a looped topology. When R1
   bridges a packet, will it reach R3 directly or via R4? Luckily, there is an excellent solution to this
   problem, namely the "Spanning Tree Protocol."

   Radia Perlman and others developed the spanning tree protocol to provide a loop free topology in a
   bridged or switched network. Her original work resulted in the DEC spanning tree algorithm, but the
   IEEE 802.1 committee made some changes to the algorithm and produced the 802.1d specification.

   While this paper focuses on bridging as done on Cisco router platforms, it's a point of interest that
   Cisco's PortFast feature, used on switching products, in many respects is a return to Perlman's original

   The spanning tree protocol works by blocking some bridged or switched interfaces and forwarding from
   others to form a classic data structure known as a tree structure with roots, nodes, and leaves. The
   word "blocking" can't be emphasized enough. Bridges effectively start by learning all possible routes
   and blocking some of them until a loop-free topology is left. Routing, however, has more intelligence for
   loop prevention, so routing can deal with multiple paths and parallel paths beyond the scope of

   Although spanning tree allows bridged and switched networks to continue functioning in the event of a
   failure with multiple physical paths, spanning tree is not without its drawbacks. Spanning tree does not
   allow for load balancing over equal paths and is slow to converge following a link failure.

   The spanning tree protocol has four basic operation steps:

   1. Electing a root bridge among a bridge/switch group

   2. Calculating the shortest path to the root bridge/switch by all non-root bridges

   3. Blocking highest cost paths to the root bridge/switch for loop avoidance 5/31/2005
Certification Zone - Tutorial                                                                       Page 4 of 23

   4. Maintaining and recalculating the spanning tree with BPDUs, but what is a BPDU?

   A BPDU is a Bridge Protocol Data Unit. A BPDU contains enough information so that all bridges can
   perform the following during spanning tree operation:

   • Select a single bridge to act as the "root" of the spanning tree

   • Calculate the distance of the shortest path from itself to the root bridge

   • For each LAN segment, designate one of the bridges as the closest one to the root. That bridge will
   handle all communication from that LAN to the root bridge and will be known as the "designated

   • Let each bridge choose one of its interfaces as its root interface, which gives the best path to the root

   • Allow each bridge to mark the root interface and any other interfaces on it that have been elected as
   designated bridges for the LAN to which it is connected as being included in the spanning tree.

   You can monitor BPDUs by using the debug spanning tree command as shown in the trace below.
   This can be very helpful in verifying correct bridging operation as well as troubleshooting bridging and
   spanning tree operation in bridged and switched networks.

   In the debug trace below, I shut the serial 0 interface of R1 in the diagram above. I have debug
   spanning tree and debug spanning events enabled so you can see both BPDUs being exchanged,
   but also the different phases an interface goes through when the spanning tree protocol operates

   6d10h: ST: Serial0.1 -> blocking
   6d10h: ST: Serial0.2 -> blocking
   6d10h: ST: Serial0.1 -> listening
   6d10h: ST: Serial0.2 -> listening
   6d10h: ST: Serial0.1 -> learning
   6d10h: ST: Serial0.2 -> learning
   6d10h: ST: Serial0.2 0000000001008000000C5D9E23000000648 ...
   40002000F00 <------------ Here is the BPDU
   6d10h: ST: Heard root   128-0000.0c5d.9e23 on Serial0.2
   6d10h: ST: Serial0.2 00000080
   6d10h: ST: Topology Change rcvd on Serial0.2
   6d10h: ST: Serial0.1 0000000001000000000C1B89F8000100630 ...
   40002000F00 <------------ Here is the BPDU
   6d10h: ST: Serial0.1 00000080
   6d10h: ST: Topology Change rcvd on Serial0.1
   6d10h: ST: Serial0.1 -> forwarding
   6d10h: ST: Serial0.2 -> forwarding
   6d10h: ST: Serial0.1 00000080
   6d10h: ST: Topology Change rcvd on Serial0.1

   The root bridge is elected based on the bridge ID value. The bridge with the lowest bridge ID value will
   be elected the root bridge. It is a good idea to make the root bridge one central to the network by
   manipulating the bridge ID value. In the event of identical bridge priorities, the bridge with the lowest
   MAC address will have the lowest ID value and be elected as the root bridge. How can we change the
   priority? We can manually change the bridge priority by using the following global configuration
   command: 5/31/2005
Certification Zone - Tutorial                                                                      Page 5 of 23

   Router(config)#bridge 1 priority ?
   <0-65535> Priority (low priority more likely to be root)

   On the root bridge, all interfaces are placed in the forwarding state. The IEEE 802.1d specification
   allows for five different states as follows:

   1. Disabled

   2. Learning

   3. Listening

   4. Forwarding

   5. Blocking

   NOTE: Root bridges and designated ports are NEVER in a blocking state. The root port on any
   bridge is NEVER in a blocking state.

   Once the root bridge/switch is elected, it is the only root bridge/switch for the entire spanning tree.
   There are some other important terms used in spanning tree operation. A designated bridge/switch is
   the device closest to the root bridge/switch on a given segment. At a given time, the spanning tree
   process for each segment elects only one designated bridge/switch. This designated bridge will forward
   frames to the root bridge. In addition, each bridge selects a root port, which will be used to forward
   frames toward the root bridge. When a network is initially brought up, the spanning tree process elects
   the root bridge, the designated bridges, the root ports for all other bridges, and identifies a loop free
   topology by placing the selected bridge interfaces into a forwarding state and all others into a blocking
   state. The root bridge maintains the spanning tree by transmitting BPDUs every 2 seconds. When each
   designated bridge receives a BPDU from the root bridge, they transmit their own BPDU. How does this
   process change when there are multiple VLANs?

   When multiple VLANs exist, Cisco's solution for spanning tree management is to run separate instances
   of the spanning tree for each VLAN. This brings up another question. How can we tell that the spanning
   tree process is even in use? To verify spanning tree operation, use the following command:

   Router#show spanning-tree

   Bridge Group 1 is executing the IEEE compatible
      Spanning Tree protocol

   Bridge identifier has priority 20, address 0010.7b38.1901
   Configured hello time 2, max age 20, forward delay 15
   We are the root of the spanning tree

   Notice that the results above show the command was executed on a root bridge. How do the results of
   the show spanning-tree command change when the bridge is not the root bridge? Examine the
   sample output below:

   Router#show spanning-tree

   Bridge Group 1 is executing the IEEE compatible
      Spanning Tree protocol

   Bridge identifier has priority 32768, address 00C0.ab54.8ba2
   Configured hello time 2, max age 20, forward delay 15
   Current root has priority 20, address 0010.7b38.1901 5/31/2005
Certification Zone - Tutorial                                                                       Page 6 of 23

   Notice that in the second case, we can view the present bridge priority, identify which bridge is the root
   bridge and identify the MAC address of the root bridge. Also notice that the timer values are present as
   well as which spanning tree protocol is in use. These timer values can be manipulated for better
   performance. The first line of the output specified that this bridge is executing the IEEE compatible
   protocol, but what other spanning tree protocols are there? There are three available spanning tree
   protocols; ieee, dec, and ibm. Note that the ibm option is only available in a Token Ring network.

   Detailed information about spanning tree performance tuning is beyond the scope of this paper, but
   there are many excellent resources available for further research. Now that we have a basic
   understanding of the spanning tree protocol, let us take a look at some of the different bridging types.

   Transparent Bridging (TB)
   A transparent bridge is a layer 2 device. It is called a transparent bridge because it never alters a frame
   in any way. As a result, an end system using a transparent bridge is never aware of the bridge's
   existence. The transparent bridge is completely "transparent" to the end system. A transparent bridge
   works by receiving a frame and comparing it to an internal table. If the frame's destination MAC
   address is located in the segment the frame came from, then it is simply dropped. If, however, the
   frame's destination MAC address resides on a different segment, then the frame is forwarded across the

   How is this table built though? Each bridge builds its own table independently by examining the source
   address of each arriving frame and associating it with the port on which it arrived.

   What if a host is moved from one segment to another segment? How will the bridge adjust? Like a
   routing table, a transparent bridge table entry has an age or time limit assigned to it. If the maximum
   age is exceeded, the entry is dropped.

   Now that we understand how transparent bridging works, let us take a look at when to use transparent

   A transparent bridge is typically used in an Ethernet environment to further segment a network when
   there are too many hosts present on a given segment. Although transparent bridging is usually used in
   an Ethernet or Fast Ethernet environment, it can also be used in a Token Ring environment, albeit
   rarely. Some important points to remember about transparent bridging are that neither the source nor
   destination MAC addresses are ever changed, so there is NEVER a RIF present.

   Although detailed router configurations are beyond the scope of this article, it is important to be able to
   recognize transparent bridging in a sample configuration when you see it. The minimal configuration for
   transparent bridging requires only two steps as shown below:

   First, a bridge-group must be assigned and a spanning tree algorithm chosen.

   Next, associate a given interface with the bridge-group you created in the first step from the interface
   configuration mode.

   Router#config t
   Router(config)#bridge 1 protocol ieee

   Although we chose the IEEE 802.1 spanning tree protocol, we could also have chosen the DEC protocol.
   The number 1 above is the bridge-group number. How will this appear in the configuration during a
   show run? See the sample output below.

   Router(config)#interface Ethernet 0
   Router(config-if)#bridge-group 1 5/31/2005
Certification Zone - Tutorial                                                                      Page 7 of 23

   Router#sh run
   interface Ethernet1
    ip address
    bridge-group 1
   bridge 1 protocol ieee

   Concurrent Routing and Bridging (CRB)
   Prior to the development of CRB, a system could either route or bridge a given network layer protocol
   out all of its interfaces. Cisco developed Concurrent Routing and Bridging to overcome this limitation.
   CRB allows specific protocols to be bridged on certain interfaces, and routed out others in the same
   device, but the two cannot be mixed. This means that an IP packet, for example, might enter via a
   bridged interface and be sent out via another bridged interface. With CRB, a packet cannot enter via a
   bridged interface and exit via a routed interface.

   To configure CRB, first enable transparent bridging. Once this is completed, enter the following global

   Router#conf t
   Router(config)#bridge crb

   With the default CRB configuration all network layer protocols are bridged by default on every interface
   belonging to the bridge group. You can view which network layer protocols are bridged and which are
   routed over a given interface with the show interface crb command. Use the bridge 1 route
   protocol command to route a given protocol. Notice that when you enter the show interface crb
   command you will never see the same protocol being both routed and bridged on the same interface.

   R1#sh int crb


    Not bridging this sub-interface.


    Bridged protocols on Serial0.1:
     appletalk clns        decnet                ip
     vines      apollo     ipx                   xns

   Cisco's CRB solution improved upon previous limitations, but it was still not an ideal solution because a
   problem remained. What do you do when you need to receive a packet on a bridged interface and send
   it out a routed interface or vice versa? Cisco solved this problem by developing a solution known as
   Integrated Routing and Bridging or IRB.

   Integrated Routing and Bridging (IRB)
   While CRB allows bridging and routing of the same protocol to co-exist on a single router, it does not
   allow the two to mix. Integrated Routing and Bridging allows bridged and routed traffic of the same
   protocol to be interchanged by creating a virtual interface called a Bridge Virtual Interface (BVI), which
   is a logical interface. 5/31/2005
Certification Zone - Tutorial                                                                   Page 8 of 23

   Since IRB is just an extension of transparent bridging, you must also perform basic transparent bridge
   configuration. Here are the commands to configure IRB.

   Router#config t
   Router(config)#bridge 1 protocol ieee
   Router(config)#int e 0
   Router(config-if)#bridge-group 1
   Router(config)#bride irb
   Router(config)#interface bvi 1
   Router(config)#bridge 1 bridge ipx
   Router(config)#bridge 1 route ip
   Router(config)#no bridge 1 bridge ip

   CCIE candidates should know the basic configuration for IRB as well as the show commands associated
   with IRB. You can view the status of the BVI interface with the show interface bvi 1 command. You
   can see which protocols will be bridged and which will be routed on a per interface basis with the show
   interface irb command. A key point to know with the show interface irb command is that with IRB,
   the same protocol may appear under both routed and bridged protocols on the same interface. With
   CRB, the protocol will only appear under bridged protocols or routed protocols, not both.

   r1#sh int irb


    Not bridging this sub-interface.

    Routed protocols on Serial0.1:
    Bridged protocols on Serial0.1:
     appletalk clns        decnet              ip
     vines      apollo     ipx                 xns


   Notice in the debug trace above that with IRB, we can route and bridge the same protocol on a given
   interface. We now have a comprehensive solution for routing and bridging on Ethernet interfaces, but
   what about Token Ring interfaces? Well, Cisco has developed numerous solutions for Token Ring
   networks as well. Let's examine the simplest Token Ring bridging solution, source route bridging, and
   work towards more complex configurations

   Source Route Bridging (SRB)
   Source route bridging was originally developed by IBM and later adopted by the IEEE as a method of
   bridging between multiple Token Ring networks. Historically, Cisco is quite concerned with SRB
   knowledge in the CCIE written and lab tests even though the industry as a whole uses SRB less and
   less. There are several different combinations of SRB available including:

   • SRB - Source Route Bridging

   • SRT - Source Route Transparent Bridging

   • SR/TLB - Source Route Translational Bridging

   • RSRB - Remote Source Route Bridging 5/31/2005
Certification Zone - Tutorial                                                                       Page 9 of 23

   How does SRB work? Examine the situation in Figure 2.

                                                   Figure 2.

   Assume Host A needs to communicate with Host B.

   Host A will ARP for Host B. This ARP broadcast will travel the entire network and to all hosts. Host B will
   ARP reply with its MAC address. At this point Host A knows the MAC address of Host B, but not the

   Host A will then send a local test frame that will travel around Ring 10 in the off chance that Host B
   resides on Host A's local ring. In our case, however, the local test frame will indicate that Host B was
   not found on the local ring.

   Now, Host A will send out an all-routes explorer broadcast frame. As the frame crosses a bridge, the
   bridge will place its bridge ID into the RIF. Eventually, Host B will receive this explorer frame and
   recognize its own MAC address, and then turn the frame around by setting the direction bit to 1. Note
   that host B will receive two explorer frames since this is an all routes explorer, and there are two
   possible routes. Which path will Host A use to get to Host B? Host A will use the first reply it receives
   and ignore all subsequent replies. But, what is a RIF then? What is an RII? What is an A Bit? What is a
   C bit?

   While transparent bridges build and maintain tables of MAC addresses and associated ports, source
   route bridges do not. Instead, a source route bridge examines the contents of each Token Ring frame.
   A SRB will check the first bit of a Token Ring frame's source address to see if it has the value of zero or
   one. The first bit of the source address in a Token Ring frame is called the Routing Information
   Indicator or RII. The value of the RII is set by the source end system of the frame. If the RII is set to
   zero, no source route information exists in the Token Ring frame. If the RII is set to one, then source
   route information is present in the frame. Source route information is located in the Routing
   Information Field or RIF. Two additional bits, the A or Address Recognized, and the C, or Frame Copied,
   bits are contained within the Frame Status byte in a Token Ring frame. When a frame is copied by a
   SRB to be put out onto another ring, the bridge sets these bits, much as if it were actually the
   destination station. Let's examine these concepts in greater detail. 5/31/2005
Certification Zone - Tutorial                                                                     Page 10 of 23

   Route Information Indicator (RII)
   When a Token Ring host receives a returned explorer frame, it needs to know the location of the data.
   The RII bit tips the host off as to whether there is a RIF located within the frame.

   0 no RIF

   1 RIF is present

   The RII is the first bit of the source MAC address. If we do the binary-to-HEX conversion, any source
   MAC address that begins with an A-F or 8-9 has a RIF present. If the RII bit is 0, the data immediately
   follows the source address. If the RII bit is 1, the data follows the RIF. For example, if the MAC address
   is 44 45 53 54 61 6F then the source address will appear as C4 45 53 54 61 6F for a frame with a RIF.

   The RIF itself consists of the Routing Control Field (2 bytes) and multiple Route Descriptor Fields (each
   2 bytes). Note that the RIF is represented in HEX. Let us look at a sample RIF:

   The above RIF represents a possible path from Host A to Host B. In this case, the Route Control Field
   (RC) is represented by the 0830, while the Route Descriptor Fields are represented by 00B1.0162.0210.

   Route Control Field (RC)
   The RC field breaks down as follows:

   Bits 15-13 describe the type of packet (Broadcast Indicators)
    0xx Non broadcast
    10x all-routes broadcast
    11x Single route broadcast (spanning explorer)

   Bits 12-8 describe the total length of the RIF represented in bytes

   Bit 7 describes the direction the RIF should be read.
    0 means the RIF is read from left to right
    1 means the RIF is read from right to left

   Bits 6-4 describe the largest frame that will be accepted on this route to the designation. 5/31/2005
Certification Zone - Tutorial                                                                     Page 11 of 23

   Bits 3-0 are always Zero (0).

   Route Descriptor Field (RD)
   The Route Descriptor Field consists of two subfields:

   • A ring number (12 bits) with values between 0x001 and 0xfff (1 to 4095 decimal)

   • A bridge number (4 bits) with values between 0x1 and 0xf (1 to 15 decimal)

   In our example above, the RD was 00B1.0162.0210. This decodes to the path the frame took:

   Ring 11 = 00B
   Bridge 1 = 1
   Ring 22 = 016
   Bridge 2 = 2
   Ring 33 = 021

   Note that the RD always ends with a Ring, so the last digit is always a zero. RIFs always end in zero!
   Here are some important points to remember when it comes to SRB:

   • The RIF is represented in Hex.

   • The RIF is comprised of the RC and the RD fields.

   • The RIF will always end in a 0.

   • The RIF does not contain a MAC address.

   • The RD field is always the same regardless of the direction of travel.

   • If a RIF is present, the source address will always begin with an 8-9 or A-F.

   • You cannot have multiple rings with the same number. Each ring must have a unique number, but
   you can have bridges with the same number because each route represents a unique path.

   Let us take a look at another RIF example

   1290 001 1 1f4 1 002 2 300 1 034 2 2f2 3 003 1 f00 0

   This RIF indicates a non-broadcast frame with a RIF of 18 bytes with a maximum frame size of 1500
   bytes with the path read from right to left. The path is ring 3840 (0xf00) bridge 1 to ring 3 bridge 3 to
   ring 754 (0x2f2) bridge 2 to ring 52 (0x34) bridge 1 to ring 768 (0x300) bridge 2 to ring 2 bridge 1 to
   ring 500 (0x1f4) bridge 1 to ring 1. This RIF is the maximum length allowable and goes through seven 5/31/2005
Certification Zone - Tutorial                                                                     Page 12 of 23

   bridges. Notice that you must skip the 0 on the far right and that all bridges and rings are represented
   in hexadecimal, not decimal. The CCIE candidate must be completely comfortable working in
   hexadecimal, decimal, and binary. Notice how the 1290 in hexadecimal breaks down in binary:

   Decoding the RC field yields the following:

   Bits 15-13 = 000 = non broadcast

   Bits 12-8 = 10010 = 18 = length of RIF in bytes

   Bit 7 = 1 = read RIF from right to left

   Bit 6-4 = 001 = MTU size of 1500 bytes

   Bits 3-0 = always 0

   In keeping with our goal of being able to recognize basic bridging configurations, let us take a look at
   the commands to set up SRB. The following command sequence establishes source route bridging
   between ring number 5 and ring number 10 with a bridge number of 1.

   Router#config t
   Router#interface tokenring 0
   Router#no ip address
   Router#ring-speed 4
   Router#source-bridge 5 1 10
   Router#interface tokenring 1
   Router#no ip address
   Router#ring-speed 4
   Router#source-bridge 10 1 5
   Router#^ z

   It is important to be able to recognize that source route bridging is being used by looking at the output
   of commands such as show source or show interface token 0. Look at the sample trace from a
   show interface token 0 command. Notice in line 8 that this router is source route transparent bridge
   capable. Notice in line 9 below that source bridging is enabled with a source ring number of 5, a bridge
   number of 1, and a destination ring number of 10.

   1. Router#show interfaces token 0
   2. TokenRing0 is up, line protocol is up
   3.   Hardware is TMS380, address is 0000.30ba.7944
           (bia 0000.30ba.7944)
   4.   MTU 4464 bytes, BW 16000 Kbit, DLY 630 usec, rely 255/255,
           load 1/255
   5.   Encapsulation SNAP, loopback not set, keepalive set (10 sec)
   6.   ARP type: SNAP, ARP Timeout 04:00:00
   7.   Ring speed: 16 Mbps
   8.   Single ring node, Source Route Transparent Bridge capable
   9.   Source bridging enabled srn 5 bn 1 trn 10
   10. Proxy explorers disabled, spanning explorer disabled,
           NetBIOS cache disabled
   11. Group Address: 0x00000000, Functional Address: 0x08000000
           Ethernet Transit OUI: 0x000000
   12. Last input 00:00:01, output 00:00:02, output hang never 5/31/2005
Certification Zone - Tutorial                                                                   Page 13 of 23

   13.   Last clearing of "show interface" counters never
   14.   Queueing strategy: fifo
   15.   Output queue 0/40, 0 drops; input queue 0/75, 0 drops
   16.   5 minute input rate 0 bits/sec, 0 packets/sec
   17.   5 minute output rate 0 bits/sec, 0 packets/sec
   18.      1615499 packets input, 49359072 bytes, 0 no buffer
   19.      Received 1031275 broadcasts, 0 runts, 0 giants,
               0 throttles
   20.      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored,
               0 abort
   21.      702494 packets output, 50538974 bytes, 0 underruns
   22.      0 output errors, 0 collisions, 1 interface resets
   23.      0 output buffer failures, 0 output buffers swapped out
   24.      11 transitions

   Source Route Transparent Bridging (SRT)
   Source route transparent bridging combines implementations of transparent bridging and source route
   bridging. SRT bridges do not translate between bridging protocols, rather, they let both technologies
   co-exist on the same router at the same time. The key point is that SRT does not provide for Ethernet
   to Token Ring bridging. SRT works by analyzing the RII bit to determine if a RIF is present. If the RII
   bit is 0, then a RIF is not present and the frame is transparently bridged. If, however, the RII bit is 1
   and a RIF is present, then the frame is source routed. Note that SRT bridges do not add or remove RIFs
   to frames. By now, you ought to wonder how to configure SRT.

   To configure SRT, you need to enable transparent and SRB bridging on interfaces used for SRT
   bridging. Here is an example configuration:

   Router(config)#bridge 4 protocol ieee
   Router(config)#source-bridge ring-group 10
   Router(config)#interface tokenring 0
   Router(config-if)#bridge-group 4
   Router(config-if)#source-bridge 500 1 10
   Router(config-if)#source-bridge spanning
   Router(config-if)#interface tokenring 1
   Router(config-if)#bridge group 4
   Router(config-if)#source-bridge 501 1 10
   Router(config-if)#source-bridge spanning

   Source Route Translational Bridging (SR/TLB)
   Source route translational bridging is a Cisco IOS feature that allows you to combine SRB and
   transparent bridging networks without the need to convert all your existing source route bridges to SRT
   nodes. There are a number of issues that need to be dealt with when it comes to SR/TLB. The issues
   are as follows:

   • No RIFs can be passed into the Ethernet environment. For example, when bridging from an SRB
   domain to the transparent bridging domain, SRB information is removed.

   • The MTU sizes are different. Ethernet's MTU is approximately 1500 bytes, but a Token Ring's MTU is
   much larger at around 4-18 KB.

   • The internal representation of MAC addresses differs between Ethernet and Token Ring. Ethernet
   transmits the least significant bits first and Token Ring transmits the most significant bit first.
   Translation bridges reorder source and destination address bits when translating between Ethernet and
   Token Ring frame formats. 5/31/2005
Certification Zone - Tutorial                                                                     Page 14 of 23

   Bit Ordering - Canonical vs. Non-Canonical
   We know that the bit order is opposite for Ethernet vs. Token Ring, but how do we convert one form to
   the other? The answer is that we go byte by byte and flip the raw bits, then reassemble them into a
   new address. For example, take the following MAC address: 0000.28A8.4800. If this MAC address is the
   Ethernet address, what will it be when it is translated to a Token Ring MAC address?

   First, take the address and separate it into bytes, i.e., 5C02.0001.4322 becomes 5C 02 . 00 01 . 43 22.
   Then convert these bytes to binary. In our example 5C 02 . 00 01 . 43 22 becomes

   Lets try another example using 0000.28A8.4800

   Referring to the output of the show interface token 0 command in the SRB material, notice the
   phrase "Ethernet Transit OUI" in line 11. OUI stands for Organizational Unique Identifier. What is OUI
   used for, however?

   According to Cisco, there are three different OUIs available using the ethernet-transit-oui command,
   standard, cisco, and 90-compatible. The cisco keyword is reserved for future use. If you are using
   all Cisco devices, then you will want to use the 90-compatible keyword because it offers more
   flexibility as described on the Cisco web pages. Only use the standard keyword if you need inter-
   vendor compatibility.

   Cisco provides some important related information at: ios100/rpcr/66007.htm

   (CertificationZone is not associated with Cisco.)

   Multiport Bridges
   Notice that in our previous discussion of SRB the bridges were always two-port bridges. What happens
   if a bridge has more than two ports? In this case where we have more than the two standard ports, we
   must define a virtual ring. This virtual ring will encompass all of the interfaces so that all locally
   connected Token Ring interfaces will forward non-local traffic to the virtual ring, which will then forward
   the traffic to the correct outbound ring. The concept of the virtual ring becomes critical when we discuss
   the next two types of bridging, RSRB and DLSw+.

   Remote Source Route Bridging (RSRB)
   Source route bridging was intended to be a LAN bridging technique, but with the increase in the number 5/31/2005
Certification Zone - Tutorial                                                                  Page 15 of 23

   of WANs, it was soon obvious that a technique was needed to extend source route bridging to WAN
   interfaces. Cisco's proprietary solution is known as Remote Source Route Bridging or RSRB. RSRB
   encapsulates SRB traffic into TCP/IP, FST/IP or HDLC tunnels and transports it over an IP WAN. A
   simpler way of thinking about RSRB is that it is Cisco's way of connecting Token Ring networks over
   non-Token Ring segments. See the example in Figure 3.

                                                 Figure 3.

   In the example in Figure 3, the non-Token Ring segment is the serial connection between ring 25 and
   ring 35. Note that this technique is not very scalable to large networks because RSRB places a
   limitation of seven total bridges between the source and destination. The example above shows that we
   have two bridges, bridge 1 and bridge 2, connected by a virtual ring, ring 10. Although each bridge has
   a different number, they could also have the same bridge number. This is possible because each ring
   must have a unique number, and each bridge will always be located between two unique ring numbers.
   With RSRB we establish a virtual ring by configuring it on both routers. Note that the virtual ring
   number must be the same on both routers! You need to be very aware of whether you are working
   in decimal or hexadecimal and be able to work in both. Remember, for example, that ring 0x019 is not
   the same as ring 019, but ring 0x013 is the same as ring 019. It should be obvious that, like SRB,
   RSRB maintains the RIF from end-to-end.

   When configuring RSRB, an additional statement needs to be configured to identify all the remote
   neighbors. That statement is the source-route remote-peer statement. Here is a sample
   configuration for RSRB using the diagram above:

   Router A

   no ip routing
   source-bridge ring-group 10
   source-bridge remote-peer 10 tcp local-ack
   source-bridge remote-peer 10 tcp

   int s0 5/31/2005
Certification Zone - Tutorial                                                                     Page 16 of 23

   ip address

   Router B

   no ip routing
   source-bridge ring-group 10
   source-bridge remote-peer 10 tcp local-ack
   source-bridge remote-peer 10 tcp

   int s1
   ip address

   Notice some of the additional parameters specified in the source-bridge remote-peer command. The
   number 10 identifies the virtual ring number. The tcp parameter specifies the transport protocol. It
   could just as easily have been FST, for example. Notice how each side of the virtual ring identifies all
   the participating peers.

   Data Link Switching Plus (DLSw+)
   Data Link Switching (DLSw) is a method for transporting SNA and NetBIOS traffic over an IP network
   described in RFC 1795. We have all heard that there are certain RFCs that simply must be read. Well,
   this is one of them. This RFC is extremely well written and is easy reading. Upon examining RFC 1795,
   we learn that DLSw is an alternative to RSRB that can be used to overcome some of the problems
   inherent in RSRB, including: the SRB and RSRB hop count limit of seven bridges, excessive broadcast
   traffic from SRB explorer frames or NetBIOS name queries, unnecessary traffic from ACKs and
   keepalives, DLC timeouts, lack of flow control and prioritization. DLSw+ will be the topic of a future
   Tutorial, but some background is necessary to understand what is happening to the RIF with DLSw+.

   Before two routers can switch SNA or NetBIOS traffic, they must establish two TCP connections
   between them. After the TCP connections are established, the routers exchange their capabilities.
   Capabilities include the DLSw version number, initial pacing windows (receive window size), NetBIOS
   support, lists of supported link service access points (SAPs), and the number of TCP sessions
   supported. MAC address lists and NetBIOS name lists can also be exchanged at this time, and if
   desired, a DLSw partner can specify if it wants to receive search frames. It is possible to configure the
   MAC addresses and NetBIOS names of all resources that will use DLSw, and avoid any broadcasts.
   Following the capabilities exchange, DLSw partners are ready to establish circuits between SNA or
   NetBIOS end systems.

   Establishing circuits between a pair of end systems requires locating the target end system and setting
   up data link control connections between each end system and its local router. SNA and NetBIOS are
   handled differently. SNA devices on a LAN find other SNA devices by sending an explorer frame (either
   a TEST or an XID frame) with the MAC address of the target SNA device. When a DLSw router receives
   an explorer frame, the router sends a "canureach" frame to each of its DLSw partners. If one of its
   DLSw partners can reach the specified MAC address, the partner replies with an "icanreach" frame.

   At this point, the DLSw partners establish a circuit that consists of multiple connections: the data link
   control connection between each router and the locally attached SNA end system, and the TCP
   connection between the DLSw partners. This circuit is uniquely identified by the source and destination
   circuit IDs. Each circuit ID includes the MAC address, link service access point (LSAP), and a data link
   control port ID. The priority assigned to this circuit is negotiated at the time the circuit is set up. In
   addition to prioritization, the circuit can be used for management and error processing. Once the circuit
   is established, SNA information frames can flow over this circuit.

   NetBIOS establishes circuits in similar fashion, except instead of forwarding a "canureach" that specifies
   a MAC address, DLSw routers send a Name Query (NetBIOS NQ) that specifies a NetBIOS name.
   Instead of an "icanreach," there is a name recognized (NetBIOS NR) frame. 5/31/2005
Certification Zone - Tutorial                                                                     Page 17 of 23

   As we discussed above, one of the drawbacks of RSRB is the limit of seven total bridges. Cisco needed
   a more scalable solution to overcome this limitation, so they developed DLSw+ or Data Link Switching
   +. The DLSw standard is documented in RFC 1795, but Cisco developed their own proprietary
   enhancements, hence the +. Note that DLSw+ is fully backwards compatible with both RSRB and
   DLSw. Look at the example below and you will notice some immediate differences over RSRB. Notice
   that the virtual ring number is different on each router. This is possible because with DLSw+, the RIF is
   terminated at each router. This also means that there will be a different RIF on each side of the serial
   connection. Examine the diagram in Figure 4.

                                                      Figure 4.

   How does RIF termination change with DLSw+ compared to RSRB or RSB? With DLSw+, the RIF is
   terminated at the DLSw+ router. This means that we do not need the same virtual ring number on each
   side of the WAN link as with RSRB. What would the RIF be at Router A in the case above? Here is how
   the RIF is built.

   First construct the RC field:

   • Bits 15-13 describe the explorer type; this will differ depending on whether the traffic is NetBIOS or
   SNA. In this case, let's assume a non-broadcast explorer, resulting in 000 in binary.

   • Bits 12-8 describe the length of the RIF in bytes. For DLSw+, this will always be 00110 in binary for

   • Bit 7 describes the direction, in this case left to right or 0 in binary.

   • Bits 6-4 describe the maximum MTU size, assume 4472 in our case, or 011 in binary.

   • Bits 3-0 are always zero.

   Assembling the RC field in binary yields 000 00110 0 011 0000 or 0000 0110 0011 0000, which 5/31/2005
Certification Zone - Tutorial                                                                      Page 18 of 23

   converts to hexadecimal as 0630. Now, construct the RD field:

   • The route is ring 25 to bridge 1 to virtual ring 10 or ring 0x19 to bridge 0x1 to virtual ring 0x00A.

   • The resulting RD is 0191 00A0. Notice that the RD always ends in a zero.

   Assembling the entire RIF, we have 0630 0191 00A0. This local termination makes it easy to recognize
   DLSw+ RIFs. DLSw+ is a complex subject that all CCIE candidates need to master, particularly for the
   lab exam. One of the best ways to do this is to read RFC1795. It is simply a MUST read. For further
   coverage of DLSW+, look for a future Tutorial here on CertificationZone or examine the bridging section
   of Cisco's software configuration guide.

   Encapsulation Bridging
   In many campus situations, a FDDI backbone is used to connect Ethernet segments. This presents a
   special problem when using VLANS because segments on one side of the FDDI backbone need to have
   addresses in the same subnet as segments on the other side of the FDDI backbone if they are to
   remain in the same VLAN. Traditionally, if you needed to send a packet from one media type to
   another, as in this case where you are going from Ethernet to FDDI, you would simply route the packet.
   With the advent of VLANs, however, this is no longer possible because the routing tables would be
   confused. The solution in this case is to bridge across the FDDI backbone. See Figure 5.

                                                   Figure 5.

   Since Ethernet and FDDI frames are different, there are two ways to bridge the two frames. One
   method is translational bridging. Translational bridging works just fine, but it does induce latency
   because it takes time to convert frames from one media to another. The second method is called
   encapsulation bridging, but it is Cisco proprietary so you must have two Cisco routers in order to use
   encapsulation bridging. Since Cisco tends to emphasize Cisco proprietary technologies, it is important to 5/31/2005
Certification Zone - Tutorial                                                                    Page 19 of 23

   at least understand what encapsulation bridging is and what problem it solves. The way encapsulation
   bridging works is by taking an Ethernet frame and enclosing it inside a FDDI frame. You can recognize
   that encapsulation bridging is in use by examining the router configuration and looking for the fddi
   encapsulate command. The final key point with encapsulation bridging is that hosts on an Ethernet
   segment cannot communicate with hosts on the FDDI backbone. Hosts on the Ethernet segment,
   however, can communicate with hosts on an Ethernet segment connected to the far side of the FDDI

   Just as SNA is a non-routable protocol developed for mainframe use by IBM, LAT is a non-routable
   protocol developed by DEC to transport terminal traffic to and from DEC minicomputers. Cisco's
   solutions for handling LAT include bridging LAT as well as taking the non-routable terminal traffic and
   translating it to another protocol such as TCP. IOS can also directly translate LAT into TCP/TELNET
   traffic. To configure LAT translation into TCP/TELNET, perform the following two steps:

   1) In interface configuration mode, enter the command lat enable. Note that with IOS version 11.2 or
   greater, LAT is enabled by default.

   2) In global configuration mode, enter the command translate lat XXX tcp A.B.C.D where XXX is the
   target LAT host name and A.B.C.D is the target IP address to begin a TELNET session at - or to perform
   a translation from - TCP back into LAT.

   Once these commands are entered, all you need to do is type "LAT XXX" and a TELNET session will
   open for the IP address specified in the translate statement.

   Since a lot of people have not configured LAT before, how can you troubleshoot and monitor a LAT to
   TCP translation? There are two primary tools useful for monitoring LAT; show translate and debug

   Since not everyone has a DEC mini computer available to test LAT translation, there is a simple method
   to establish a LAT service on a router. Enter the command lat service XXX enable, where XXX is the
   name of the service. An example might be as follows:

   lat service CCIE

   Here are some debug traces showing LAT in action:

   r4#lat CCIE
   Trying CCIE...Open

   r4#sh translate

   Translate From: TCP Port 23
             To:   LAT CCIE
             0/0 users active, 1 peak, 2 total, 2 failures

   r4#sh lat service
   Service Name      Rating         Interface      Node (Address)
   CCIE                   5         Ethernet0      R6 (0010.7b3a.3d86)
   SHOWRUN                5         Ethernet0      R6 (0010.7b3a.3d86)

   Trying ... Open
   Trying CCIE...Open

   r4#sh trans 5/31/2005
Certification Zone - Tutorial                                                                       Page 20 of 23

   Translate From: TCP Port 23
             To:   LAT CCIE
             0/0 users active, 1 peak, 3 total, 2 failures

   00:33:49: tcplat2: fork started
   00:33:49: LAT2: Connection complete.
   00:33:49: tcplat2: queuemax = 30

   The bottom line is that like SNA, LAT is not dead. As a CCIE candidate you need to understand the
   nature of LAT and how to configure it.

   Access Lists for Non-routable Traffic
   Most of us are familiar with access lists for IP, AppleTalk and IPX, but access lists can be used to filter
   non-routable traffic as well. For example, we can filter non-routable traffic by NetBIOS name, MAC
   address, or LSAP address.

   NetBIOS Access Lists
   Unlike other access lists, NetBIOS access lists do not have a number range assigned to them. They do,
   however share two components of extended access lists: 1) a named access list defined in the global
   configuration mode and 2) the statements to apply the access list to a Token Ring interface or DLSw+
   remote peer connection. How do we configure NetBIOS access lists? Examine the syntax below:

   netbios access-list host name (permit | deny) pattern

   The name following "host" above is the name of the access list, not the name of the NetBIOS host. Note
   that NetBIOS names are case sensitive. We can configure two types of filters: one for source and
   destination station names and one for arbitrary byte patterns in a given packet. Let us look at a sample
   access list designed to

   - deny all three letter NetBIOS names beginning with "MA", any character, then "R"

   - deny any NetBIOS name beginning with the letter "A,"

   - permit all others.

   Here is what that list would look like:

   Router(config)#netbios access-list host mylist deny MA?R*
   Router(config)#netbios access-list host mylist deny A*
   Router(config)#netbios access-list host mylist permit *

   Notice the use of the * wildcard character. The * is used at the end of the string, just as in DOS or
   Unix, to indicate a match with any character or string. The ? is also a wildcard, but is used to match any
   single character. In order to use the ? wildcard, you must first type <ctrl-v> or the IOS will probably
   interpret the ? as a request for help.

   Earlier, we mentioned that there were two components to NetBIOS access list configuration. What is
   the other component? The other component is the application of the access list to a Token Ring
   interface or DLSw+ remote peer connection. Here are a few examples based on our access list above:

   Token Ring Interfaces 5/31/2005
Certification Zone - Tutorial                                                                       Page 21 of 23

   netbios output-access-filter host mylist
   netbios input-access-filter host mylist

   DLSw+ Remote Peers

   dlsw remote-peer 0 tcp host-netbios-out mylist

   Cisco provides important related information at:

   (CertificationZone is not associated with Cisco.)

   NetBIOS access lists are just one of the access lists for non-routable traffic. Let us take a look at the
   next type, MAC address access lists.

   MAC Address Access Lists
   MAC address access lists are available in two forms, standard and extended. The standard form uses
   the number 700, while extended access lists use 1100. The standard access lists filters are based on a
   single MAC address statement, and both types can be applied to filter both inbound and outbound
   bridged traffic only. Access-list 700 can specify either source or destination addresses. Extended MAC
   address access lists are represented by access lists 1100-1199 and filter based on both source and
   destination MAC addresses. How are these access lists applied? Both access lists are applied at the end
   of a bridge-group interface statement using either "input-pattern-list" or "output-pattern-list."

   MAC address access lists present a special problem when used in a mixed Ethernet/Token Ring
   environment. As discussed previously, Ethernet uses canonical addressing, but Token Ring uses non-
   canonical addressing. This is a problem because access lists designed for Ethernet may not work for
   Token Ring. Token Ring also presents an additional problem because we must use the mask
   8000.0000.0000 for the source address of any traffic that requires an exact match and needs to be
   source route bridged to account for the RII. For example, address 0110.2222.3333 on Ethernet is
   8008.4444.CCCC on Token Ring and FDDI. Access lists always use the canonical Ethernet
   representation. Note that bridged packets crossing serial links have Ethernet style addresses. This
   brings up the question of how MAC address access lists are applied. They are applied to the end of both
   transparent and source route bridging statements as follows:

   bridge-group # input-address-list (# = bridge-group number)
   bridge-group # output-address-list (# = bridge-group number)
   source-bridge output-address-list

   MAC address access lists can also be used for DLSw+ remote peer statements as follows:


   MAC address and NetBIOS access lists are just two of the non-routable access list types. The remaining
   type is the LSAP access list.

   LSAP Address Access Lists
   LSAP access lists use the number 200 and allow filtering by logical link control layer or equivalent
   addresses. LSAP addresses are eight-bit addresses using a hexadecimal format. In fact, both MAC
   address and LSAP address access lists use a hexadecimal format to configure addresses and associated
   masks. Many of these addresses are registered with the IEEE. Some sample addresses are described in 5/31/2005
Certification Zone - Tutorial                                                                     Page 22 of 23

   the table below:

   The addresses are paired in a source and destination format. For example, 0x0D0D represents a source
   and destination LSAP pair for SNA. Finally, LSAP access lists also filter only bridged traffic. They are
   applied for Token Ring and DLSW+ as follows:

   For Token Ring, LSAP filters are placed at the end of source-bridge statements, i.e.,

   source-bridge input-lsap-list
   source-bridge output-lsap-list

   For DLSw+, LSAP filters are placed at the end of remote-peer statements, i.e.,

   dlsw remote-peer 0 fst Lsap-output-list 201

   LSAP access lists can also be applied to Ethernet interface by applying them to the end of a bridge-
   group statement. There are also two options for Ethernet interfaces. You can filter LSAP traffic by type
   code or by encapsulation as follows:

   input-lsap-list filter incoming IEEE 802.3 encapsulated packets
   input-type-list filter incoming Ethernet packets by type code

   The road to obtaining a coveted CCIE certification is a long and difficult one, requiring both a depth and
   breadth of routing, switching, and bridging knowledge. It is also made more difficult because the line
   between routing, switching, and bridging becomes more blurred daily with the advent of layer 2, 3, and
   4 switching. I would like to close by pointing out that there is no shortcut method for obtaining the
   CCIE certification. I could give you the entire contents of my own exams, but this would still not help
   because the content changes frequently. I have put in hundreds of hours to master the material for
   both the written and lab exams. You must study hard and master the subjects listed in the Exam
   Blueprint and on Cisco's official web site.

   You will be asked to solve Bridging problems on both the CCIE written and practical exams. Are you
   ready to solve them?

   To help determine if you are, make sure you check out the following self-assessment tools at

   • Twenty-five multiple-choice Bridging questions modeled after those you're likely to encounter on the
   CCIE R/S written exam.

   • Two lab scenarios structured like the one you'll be asked to tackle when you attempt the two-day
   CCIE Lab Exam." 5/31/2005
Certification Zone - Tutorial                                                       Page 23 of 23

   [2001-09-07-01] 5/31/2005

To top