The first 802 is a transparent bridge or a bridge spanning tree bridge. Those who support the primary concern of this design is completely transparent. Their point of view, the unit is equipped with multiple LAN bridge in the buy back after the IEEE standard, simply plug the connector bridge to all problems. Do not need to change hardware and software, no need to set the address switches, or parameters do not need to load routing tables. In short doing nothing, just insert the cable on the bin, not subject to the operation of existing LAN bridge in any way. This is incredible, they finally succeeded.
Certification Zone - Tutorial Page 1 of 23 Tutorial Bridging by David Wolsefer Introduction Assumptions Bridging 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 LAT Access Lists for Non-routable Traffic NetBIOS Access Lists MAC Address Access Lists LSAP Address Access Lists Conclusion Introduction 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 Exam. 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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: http://www.cisco.com/warp/public/625/ccie/rsblueprint.html. (CertificationZone is not associated with Cisco.) Assumptions 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. Bridging 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. http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 algorithm. 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 bridging. 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 bridge." • Let each bridge choose one of its interfaces as its root interface, which gives the best path to the root bridge. • 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 correctly. 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 ... 00000607015AA55800601001 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 ... 08000000C5D9E23800602001 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: http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 bridge. 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 bridging. 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005 Certification Zone - Tutorial Page 7 of 23 Router#sh run . . . interface Ethernet1 ip address 10.1.1.3 255.255.255.0 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 command. 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 Serial0 Not bridging this sub-interface. Serial0.1 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. http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 Router(config)#^z 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 Serial0 Not bridging this sub-interface. Serial0.1 Routed protocols on Serial0.1: ip Bridged protocols on Serial0.1: appletalk clns decnet ip vines apollo ipx xns r1# 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 location. 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. http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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. http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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. http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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: http://www.cisco.com/univercd/cc/td/doc/product/software/ 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 10.1.1.2 local-ack source-bridge remote-peer 10 tcp 10.1.1.1 int s0 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005 Certification Zone - Tutorial Page 16 of 23 ip address 10.1.1.1 255.255.255.0 Router B no ip routing source-bridge ring-group 10 source-bridge remote-peer 10 tcp 10.1.1.1 local-ack source-bridge remote-peer 10 tcp 10.1.1.2 int s1 ip address 10.1.1.2 255.255.255.0 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. http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 DLSW+. • 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 backbone. LAT 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 translate. 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 18.104.22.168 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) r4#22.214.171.124 Trying 126.96.36.199 ... Open Trying CCIE...Open r4#sh trans http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005 Certification Zone - Tutorial Page 20 of 23 Translate From: TCP 188.8.131.52 Port 23 To: LAT CCIE 0/0 users active, 1 peak, 3 total, 2 failures r6# 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 192.168.1.1 host-netbios-out mylist Cisco provides important related information at: http://www.cisco.com/univercd/cc/td/doc/product/software/ ios113ed/113ed_cr/ibm_c/bcprt1/bcsrb.htm#xtocid1315846 (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: dmac-output-list 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 http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 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 172.16.40.4 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 Conclusion 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 certificationzone.com: • 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." http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005 Certification Zone - Tutorial Page 23 of 23 [IE-BRDG-WP1-F03] [2001-09-07-01] http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides... 5/31/2005
Pages to are hidden for
"Bridging"Please download to view full document