-->CISCO技术文档－热点帮助-->Basic RSRB Configurations and Concepts

后一页
前一页
Basic RSRB Configurations and Concepts

Introduction

This document will introduce you to RSRB, or Remote Source-Route Bridging. With Cisco routers, RSRB allows you to bridge traffic between two Token Rings from separate routers. First we will talk about creating virtual rings, or ring groups. Then we'll give you configuration examples for RSRB, using Direct, FST (Fast Sequenced Transport), and TCP encapsulation, including some helpful design guidelines. Finally, you'll get a 888 of indirect bridging, a technique by which two or more ring groups can be bridged together.

All the examples given here only show the parts of the configuration that pertain to the RSRB config. In addition, you may need to add the command source-bridge spanning to the Token Ring interfaces to specify how single-route broadcast traffic should be handled. For more details on how this is configured, see the document on single-route broadcasts and Automatic Spanning Tree.

Virtual Rings

Virtual rings or ring groups are mechanisms for bridging together two or more rings. These virtual rings can be extended between multiple routers, so that all of the rings on multiple routers are able to communicate with each other. This extension is done with source-route remote-peer statements.

There are some things to keep in mind when setting up virtual rings. In order to pass SRB traffic between them, routers must be part of the same ring-group (virtual ring). Also, routers being peered together must have source-route remote-peer statements pointing to each other. For example, picture three routers (A, B, and C) all in a ring-group. A is peered to B, and B is peered to C, but A is not peered to C. Routers A and C will not be able to pass SRB traffic from one to the other, even though they appear to have a path through router B. The peering is not commutative.

Configuration Example - Direct Encapsulation

----------S0  ----------
T0  |        |--- |        | T0
Token-----|Router A| /  |Router B|-----Token
Ring 1    |        | ---|        |     Ring 2
----------  S0----------
// F0
FDDI
F0 //
----------
T1  |        |
Token-----|Router C|
Ring 4    |        |
----------
|T0
|
Token
Ring 3

Direct encapsulation is the simplest type of remote peering. In order to use direct encapsulation, the routers to be peered together must be directly attached to each other (i. e. no intermediate hops) with HDLC- encapsulated serial lines or with LAN media. When serial lines are slow, or not completely clean, FST or TCP are better choices for encapsulation types.

ROUTER A:

source-bridge ring-group 4095
source-bridge remote-peer 4095 interface serial 0


interface serial 0
encapsulation hdlc   {default}


interface tokenring 0
source-bridge 1 1 4095 
source-bridge spanning

ROUTER B:

source-bridge ring-group 4095
source-bridge remote-peer 4095 interface serial 0
source-bridge remote-peer 4095 interface fddi 0 4000.0000.0003

  interface serial 0
encapsulation hdlc {default}

  interface fddi 0
mac-address 4000.0000.0002

  interface tokenring 0
source-bridge 2 1 4095 
source-bridge spanning

ROUTER C:

source-bridge ring-group 4095
source-bridge remote-peer 4095 interface fddi 0 4000.0000.0002

  interface fddi 0
mac-address 4000.0000.0003

  interface tokenring 0
source-bridge 3 1 4095 
source-bridge spanning

  interface tokenring 1
source-bridge 4 1 4095 
source-bridge spanning

NOTES:

You must use HDLC encapsulation when doing direct encapsulation over serial lines. If the line is set up for PPP, X25, or other encapsulation types, direct encapsulation cannot be used. Since HDLC is the default encapsulation, this information will not be included in the configuration file. The router will accept the command encapsulation hdlc at config time but when the commands show config or write term are used, this information will not be displayed. To find this information, use the command show interface.
Since LANs are multi-access media, MAC Addresses must be used when doing direct encapsulation over LAN interfaces. In this case, MAC Addresses were defined for the LAN interfaces for clarity. However, most of the time, the burned-in MAC addresses are preferable. To find these addresses for the FDDI interfaces, use command show interface fddi x.
An FDDI interface was used here to demonstrate direct encapsulation over LANs, but it will also work over Ethernet or Token Ring interfaces. Typically you will not see direct encapsulation over Token Ring, since local SRB is usually a better option.
Even though all three routers are part of ring-group 4095, stations on the token ring off of Router A won't be able to establish sessions with stations on the token ring off of Router C since these two routers are not peered together. Router A and Router C cannot be peered together using direct encapsulation, as there is an intervening hop (Router B). You can either add a direct link between Routers A and C and add the appropriate peer statement, or use one of the other two encapsulation methods (FST, TCP) to peer routers A and C.

Configuration Example - FST (Fast Sequenced Transport) Encapsulation

FST encapsulation's major advantage over direct encapsulation is that it allows you to extend over multiple hops. However, it does require a bit more protocol overhead than direct encapsulation (FST encapsulates SRB packets into an IP packet), and it relies on a level 3 protocol (IP), while direct encapsulation only needs level 2 connectivity (HDLC, LAN LLC).

FST introduces a new configuration requirement as well. Each router using FST peering must have an fst-peername defined. This name must be an IP address that is in use by an active interface on the router. The remote-peer statements of routers trying to access this router must reference the IP address that has been defined as the fst-peername for the router - using any other IP address on the box will not work. Use either a loopback interface or a LAN interface as the fst-peername for stability.

ROUTER A

source-bridge fst-peername 1.1.1.1
source-bridge ring-group 4095
source-bridge remote-peer 4095 fst 1.2.2.2
source-bridge remote-peer 4095 fst 1.3.3.3

  interface serial 0
ip address 1.255.1.1 255.255.0.0

  interface tokenring 0
ip address 1.1.1.1 255.255.0.0
source-bridge 1 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

ROUTER B

source-bridge fst-peername 1.2.2.2
source-bridge ring-group 4095
source-bridge remote-peer 4095 fst 1.1.1.1
source-bridge remote-peer 4095 fst 1.3.3.3

  interface serial 0
ip address 1.255.1.2 255.255.0.0

  interface fddi 0
ip address 1.254.1.2 255.255.0.0

  interface tokenring 0
ip address 1.2.2.2 255.255.0.0
source-bridge 2 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

ROUTER C

source-bridge fst-peername 1.3.3.3
source-bridge ring-group 4095
source-bridge remote-peer 4095 fst 1.1.1.1
source-bridge remote-peer 4095 fst 1.2.2.2

  interface fddi 0
ip address 1.254.1.1 255.255.0.0

  interface tokenring 0
ip address 1.3.3.3 255.255.0.0
source-bridge 3 1 4095
   source-bridge spanning

  interface tokenring 1
source-bridge 4 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

NOTES:

The router RIP statements and IP addresses on serial and FDDI interfaces show IP connectivity between the routers. If you can't pass IP traffic between the two IP addresses used by the peers, FST RSRB won't work.
In this example, the IP addresses of the Token-Ring interfaces were chosen as the fst-peernames. Any active IP addresses (for instance, the IP addresses on the serial or FDDI interfaces) could have been used instead, as long as the FST peername was referenced consistently by the peers. For instance, if Router A's fst-peername statement was modified to read: source-bridge fst-peername 1.255.1.1, then you would need to replace source-bridge remote-peer 4095 fst 1.1.1.1 with source-bridge remote-peer 4095 fst 1.255.1.1 on Routers B and C.
Even though there are multiple rings bridged off of router C, Routers A and B still require only one peer statement to that router.

Configuration Example - TCP Encapsulation

The most commonly used encapsulation type, is TCP. This encapsulation has greater overhead than direct and FST, both on the network, where every RSRB packet gets encapsulated within a full IP and TCP header, and in the routers, where there is additional processor overhead for maintaining a TCP session for every remote-peer required. The advantage of TCP encapsulation is the reliable delivery of packets, which lessens the recovery responsibility of end stations in the case of a lost or corrupted packet.

TCP configuration is very similar to FST configuration. Instead of a special command to configure the peername, the IP address representing the local router is treated exactly the same as a remote peer. Here is a TCP peering configuration equivalent to the previously presented FST configuration:

ROUTER A:

source-bridge ring-group 4095
source-bridge remote-peer 4095 tcp 1.1.1.1
source-bridge remote-peer 4095 tcp 1.2.2.2
source-bridge remote-peer 4095 tcp 1.3.3.3

  interface serial 0
ip address 1.255.1.1 255.255.0.0

  interface tokenring 0
ip address 1.1.1.1 255.255.0.0
source-bridge 1 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

ROUTER B:

source-bridge ring-group 4095
source-bridge remote-peer 4095 tcp 1.2.2.2
source-bridge remote-peer 4095 tcp 1.1.1.1
source-bridge remote-peer 4095 tcp 1.3.3.3

  interface serial 0
ip address 1.255.1.2 255.255.0.0

  interface fddi 0
ip address 1.254.1.2 255.255.0.0

  interface tokenring 0
ip address 1.2.2.2 255.255.0.0
source-bridge 2 1 4095
   source-bridge spanning

  router rip
network 1.0.0.0

ROUTER C:

source-bridge ring-group 4095
source-bridge remote-peer 4095 tcp 1.3.3.3
source-bridge remote-peer 4095 tcp 1.1.1.1
source-bridge remote-peer 4095 tcp 1.2.2.2

  interface fddi 0
ip address 1.254.1.1 255.255.0.0

  interface tokenring 0
ip address 1.3.3.3 255.255.0.0
source-bridge 3 1 4095 
source-bridge spanning

  interface tokenring 1
source-bridge 4 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

NOTE: In this configuration, the local remote-peer statement is always the first of the configured remote-peers. This makes it easier to understand for troubleshooting.

Configuration Example - Mixed Encapsulations

It is alright to mix encapsulation types within a ring group, but there are some simple rules to be follow.

　
Any router using FST peering must have an FST peername. The FST peername is the IP address of one of the interfaces. Use of an address defined for a loopback interface is permissable.
Any router using TCP peering must have a local remote-peer statement. The source bridge remote peername is the IP address of one of the interfaces. Use of an address defined for a loopback interface is permissible.
When peering two routers, only one encapsulation type can be used. You cannot have a TCP peer statement from A to B, and an FST peer statement from B back to A. Similarly, you cannot peer from A to B with more than one encapsulation type.

The example below shows all three encapsulation types within the same ring group. Routers A and B are peered using direct encapsulation, routers A and C use TCP encapsulation, and routers B and C use FST encapsulation.

ROUTER A:

source-bridge ring-group 4095
source-bridge remote-peer 4095 tcp 1.1.1.1
source-bridge remote-peer 4095 tcp 1.3.3.3
source-bridge remote-peer 4095 interface serial 0

  interface serial 0
ip address 1.255.1.1 255.255.0.0

  interface tokenring 0
ip address 1.1.1.1 255.255.0.0
source-bridge 1 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

ROUTER B:

source-bridge fst-peername 1.2.2.2
source-bridge ring-group 4095
source-bridge remote-peer 4095 interface serial 0
source-bridge remote-peer 4095 fst 1.3.3.3

  interface serial 0
ip address 1.255.1.2 255.255.0.0

  interface fddi 0
ip address 1.254.1.2 255.255.0.0

  interface tokenring 0
ip address 1.2.2.2 255.255.0.0
source-bridge 2 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

ROUTER C:

source-bridge fst-peername 1.3.3.3
source-bridge ring-group 4095
source-bridge remote-peer 4095 fst 1.2.2.2
source-bridge remote-peer 4095 tcp 1.3.3.3
source-bridge remote-peer 4095 tcp 1.1.1.1

  interface fddi 0
ip address 1.254.1.1 255.255.0.0

  interface tokenring 0
ip address 1.3.3.3 255.255.0.0
source-bridge 3 1 4095
   source-bridge spanning

  interface tokenring 1
source-bridge 4 1 4095 
source-bridge spanning

  router rip
network 1.0.0.0

Configuration Example - Indirect Bridging

So far we have only dealt with situations with one ring-group, but there are times when we might want to bridge multiple ring-groups together. There is no command which directly bridges two ring-groups together, but we can accomplish this with indirect bridging. Through the use of multiple token ring interfaces on the same segment, two or more ring groups can be indirectly bridged together. Here's an example:

Token
Ring 2
T0|    |T1
|    |
----------S0  ----------S1  ----------
T0  |        |--- |        |--- |        | T0
Token-----|Router A| /  |Router B| /  |Router C|-----Token
Ring 1    |        | ---|        | ---|        |     Ring 3
----------  S0----------  S0----------

ROUTER A:

source-bridge ring-group 4095
source-bridge remote-peer 4095 interface serial 0

  interface serial 0
encapsulation hdlc

  interface tokenring 0
source-bridge 1 1 4095 
source-bridge spanning

ROUTER B:

source-bridge ring-group 4095
source-bridge remote-peer 4095 interface serial 0
source-bridge ring-group 4094
source-bridge remote-peer 4094 interface serial 1

  interface serial 0
encapsulation hdlc

  interface serial 1
encapsulation hdlc

  interface tokenring 0
source-bridge 2 1 4095 
source-bridge spanning

  interface tokenring 1
source-bridge 2 1 4094
   source-bridge spanning

ROUTER C:

source-bridge ring-group 4094
source-bridge remote-peer 4094 interface serial 0

  interface serial 0
encapsulation hdlc

  interface tokenring 0
source-bridge 3 1 4094 
source-bridge spanning

NOTES:

In the above configuration, physical ring 2 (connected to the two token ring interfaces of Router B) is being used for indirect bridging of ring groups 4095 and 4094. This ring can be used by other devices as well, but be aware that there may be a heavy load on this ring as it is handling broadcast traffic from both ring groups.
Because of the indirect bridging, stations on the token ring off of Router A can communicate with stations on the token ring off of Router C, even though they are not peered together. If the indirect bridging commands were removed from Router B, this connectivity would be lost.
Indirect bridging is a mechanism for joining two existing ring groups without having to reconfigure all of the routers within one of the groups. It's more of a patch than a design feature, and it is not regarded as a good design practice. When designing a network from the start, multiple ring-groups joined in this manner should not be designed intothe same RSRB network.

后一页
前一页

回首页