JP2020010102A - Relay device - Google Patents

Abstract

To reduce a communication load by effectively using a band by enabling communication through the shortest path in a redundant network.SOLUTION: RT bridges 1-1, 1-2, ..., relay communication between terminals through the shortest path on the basis of an FDB 4. The entry of the FDB 4 is obtained from a MACRIB 6. The MACRIB 6 is synthesized from a root path vector DB 7 and a MAC subnet DB 8. When both DB 7 and 8 are constructed, a neighbor table 9 is referred to. The neighbor table 9 is created when exchanging an RT-BPDU 10 with an adjacent RT bridge.SELECTED DRAWING: Figure 2

Description

  The present invention relates to a relay device that relays communication between terminals on a network.

  STP (Spanning Tree Protocol) is a protocol standardized by IEEE802.1D, and is used in a layer 2 (hereinafter, referred to as L2) network that is made redundant in a loop (circular).

  In a network in which the STP is not enabled, all ports of each node (bridge) connected in a loop are in a state where frame transfer is possible. On the other hand, in a network in which STP is enabled, an arbitrary port of a node is automatically put into a blocking state, a specific link is closed, and the port is automatically enabled only when a failure occurs. Note that Patent Literature 1 describes a switching hub used for an STP node.

JP 2010-171468 A

  Although STP is often used for controlling a transmission path in an L2 network, since a closed link does not contribute to transmission, the transmission path may be wasted, and the communication load may be increased. In particular, the waste is regarded as a problem in a network having a high bandwidth consumption rate such as a data center.

  An example will be described with reference to FIG. Here, twelve nodes 1 to 12 are connected in a loop, and node numbers are assigned according to the time positions of the clock. In this case, if the STP is enabled, one point on the loop is closed.

  Since the link between the nodes 6 and 7 is closed at 6: 00-7 hours, the terminals A and B need not communicate between the nodes 6-7 but the nodes 6-5-4-. .. Must detour with 9-8-7.

  Therefore, although the communication load is not applied to the other links through the link between the nodes 6 and 7, the communication load is applied to all the links due to the detour, and if the communication amount is large, the adverse effect of the communication load increases.

  SUMMARY OF THE INVENTION The present invention has been made to solve such a conventional problem, and an object of the present invention is to make it possible to use a shortest path in a redundant network to effectively use a band and reduce a communication load.

(1) The present invention is a relay device including a storage unit that relays communication between terminals in a redundant network and stores route information to each terminal,
The route information includes a MAC address of each terminal,
A route path vector having a relay device as a route that relays the terminals,
Is retained in the control,
The communication between the terminals is relayed based on the route information.

(2) In one aspect of the present invention, when a plurality of the root path vectors exist, the root path vector having the minimum route path cost to the route is selected,
If there are a plurality of route vectors having the minimum route path cost, one is arbitrarily selected.

  (3) Another aspect of the present invention is characterized in that a port number closest to the root is associated with the MAC address and the root path vector.

  (4) In still another aspect of the present invention, the root path vector having the minimum root path cost is obtained by transmitting and receiving a protocol data unit in which the root path vector is described between adjacent relay apparatuses.

(5) According to still another aspect of the present invention, the identification information for each port according to the presence / absence of reception of the data unit is associated with information of the adjacent relay device connected to the port and stored. A first storage unit;
A second storage unit that stores a MAC address of the terminal connected to each port of each of the relay devices;
A third storage unit in which the root path vector is stored,
When creating the storage information of the second storage unit and the storage information of the third storage unit, the storage information of the first storage unit is referred to,
The path information is created by combining the storage information of the second storage unit and the storage information of the third storage unit.

(6) Still another aspect of the present invention is to periodically transmit the data unit to the adjacent relay device and create data to be stored in the first storage unit,
In the data unit, the route vector having the source relay device as a route is described,
The data unit is transmitted / received to / from the adjacent relay device to obtain the root path vector having the minimum root path cost.

(7) According to still another aspect of the present invention, when the information of the MAC address is entered in the second storage unit, the entry is flagged,
As a result of searching the first database when transmitting the data unit, if the flag is found,
The information of the entry is added to the data unit and transmitted, and the flag is lowered after the transmission.

  ADVANTAGE OF THE INVENTION According to this invention, since communication by the shortest path | route is enabled, a band can be utilized effectively and a communication load can be reduced.

FIG. 2 is a network configuration diagram showing a loop connection. FIG. 1 is a configuration diagram of an RT bridge according to an embodiment of the present invention. (A) is a data configuration diagram showing an encoding example of an RT-BPDU, and (b) is a data configuration diagram of the end-host advertisement of (a). (A) is an implementation example of the host addition advertisement to the end host advertisement, and (b) is an implementation example of the host deletion advertisement. (A) is an implementation example of the hash advertisement to the end host advertisement, and (b) is an implementation example of the hash advertisement request. FIG. 2 is a network configuration diagram of the RT bridge group. FIG. 4 is a chart showing a processing procedure of the RT bridge.

  Hereinafter, a relay device according to an embodiment of the present invention will be described. Here, the relay device of the present invention is applied to a router-like bridge (hereinafter, referred to as an RT bridge) used in an L2 network that is made redundant in a loop.

≪Configuration example≫
(1) First, a configuration example of the RT bridge will be described with reference to FIG. Here, 1-1 and 1-2 in FIG. 2 indicate the RT bridges 1 adjacent to each other on the network.

  Specifically, the RT bridge 1 is a switching hub (hereinafter, referred to as a switch), and includes a switch engine 3, an FDB (Forwarding Database) 4, a LAN port P, and a protocol process in the same manner as a general switch. And a central processing unit (CPU, etc.) 2 for performing such operations. Here, the LAN port P is shown as an eight-port configuration as an example, but the number of ports can be arbitrarily determined.

  In addition, for controlling a route in the MAC layer, each data of the MAC RIB 6, the route path vector DB 7, the MAC subnet DB 8, and the neighbor table 9 is held. These data are maintained by a protocol executed by the central processing unit 2.

  Here, the final goal of data processing is to inject an entry (a combination of a MAC address and a transfer port number) into the FDB 4 and hold it. The entry to the FDB 4 is obtained from the information held in the MACRIB 6.

  The information held in the MACRIB 6 is synthesized from the information stored in the root path vector DB 7 and the information stored in the MAC subnet DB 8. The neighbor table 9 is referred to when the storage information of the route path vector DB 7 and the MAC subnet DB 8 is constructed.

  Further, the route information necessary for the calculation of the route is obtained by exchanging the RT-BPDU (protocol data unit) 10 between the adjacent bridges 1-1 and 1-2 and propagating the packet into the network as a so-called bucket brigade. In FIG. 2, only the RT bridges 1-1 and 1-2 are shown, but the number of the RT bridges 1 is not limited to two, and n (the RT bridges 1-1, 1-2, and 1-3 ... 1-n).

  (2) Next, a configuration example of the RT-BPDU 10 will be described with reference to FIGS. FIG. 3A shows an encoding example of the RT-BPDU 10. In this encoding example, the data structure from the protocol ID to the version length 1 indicates the definition of IEEE 802.1D, and an end host advertisement field for calculating the route is added to the end of the data structure.

  This field is made up of one or more data sets. As shown in FIG. 3B, each data set has at least (A) data type, (B) data size / number, and (C) data body (variable length). At this time, in order to confirm the validity of the advertisement itself, a CRC32 (Cyclic Redundancyk) of the entire advertisement and the entire advertisement is added to the head of the end host advertisement. Here, it is referred to as CRC32.

  FIG. 4A shows a host addition advertisement in the end host advertisement field, and FIG. 4B shows the host deletion advertisement. Here, the data type “03” indicates host addition, the data type “04” indicates host deletion, and the port ID and MAC address of the host to be added / deleted are described.

  FIG. 5A shows a hash advertisement in the end host advertisement field, and FIG. 5B shows the host advertisement request. Here, the data type “01” indicates a hash advertisement, the data type “02” indicates a host advertisement request, and a port ID and a CRC 32 are described respectively. Note that the formats shown in FIGS. 3 to 5 are merely examples of the RT-BPDU 10, and other formats may be used.

≪Basic operation≫
The basic operation of the RT bridge 1 will be described below.

  (1) Forwarding is performed based on a MAC address instead of an IP address.

  (2) The FDB 4 is used as an FIB table, that is, a table for handling packet transfer destinations. Here, the normal FIB table is created from a routing information base (hereinafter abbreviated as RIB), that is, a table-like data tree type data structure that holds a list of routes to destinations of individual networks. . In this regard, the FDB 4 of the RT bridge 1 is created from the MACRIB 6 as described above.

  (3) Do not perform flooding (transfer the received frame to all ports other than the receiving port).

  (4) Calculate the root path of each RT bridge 1 without performing the root bridge selection of the STP. Here, a route calculation equivalent to a routing protocol (RIP) is performed.

  (5) Do not use the closed port of the STP.

  (6) Local / remote host is identified by local host discovery (described later), and the identification result is stored in the MAC subnet DB8.

  (7) Broadcasting performs distribution via a spanning tree or flooding that depends on RDB (Reverse Path Forwarding) of FDB4.

≫Comparison with conventional switch≫
(1) Operation A of conventional L2 switch: The conventional L2 switch basically floods.
B: However, if the transfer destination port of the unicast frame is known, it is transferred only to that port. This transfer operation is called "switching".
C: The transfer destination of the unicast frame is learned by associating the transmission source MAC address of the reception frame with the reception port and registering it in a MAC address table (corresponding to FDB4) (autonomously learned). .
D: The entries learned as part of the autonomous learning are aged (life management) in the MAC address table. That is, even if the learning is performed once, a process of deleting the entry is performed when a predetermined time comes after the subsequent frame does not come.

(2) Operation of the RT bridge 1 a: The RT bridge 1 basically does not perform flooding. That is, a unicast frame whose transfer destination has not been learned is transferred to only the central processing unit 2 without transferring to the LAN port P.
b: The unicast frame whose transfer destination has been learned by the FDB 4 is switched by the switch engine 3 as in the conventional type.
c: The transfer destination of the unicast frame is learned by the processing of the local host discovery, and independent learning by the FDB 4 is prohibited.
d: The entry is not aged because independent learning by the FDB 4 is prohibited.

≪ Details of operation ≪
Hereinafter, the operation of the RT bridge 1 will be described in detail. Here, the operation processing (processing steps) will be described based on the network configuration in FIG.

  The RT bridges 1 to 23 in FIG. 6 indicate the RT bridge 1 connected to the redundant L2 network, respectively, and relay communication between the terminals 101 to 104 and 121 to 125.

  Also, 16-digit hexadecimal values “8000: XXXXXX0000021” to “8000: XXXXXX000025” indicate the bridge ID of the RT bridge 1, and a small numerical value is set to high priority. The lower 6 bytes of this bridge ID indicate the MAC address, and the value of the upper 3 bytes “XXXXXX” of the MAC address indicates the manufacturer's OUI (unique identification number).

(1) At the time of starting the RT bridge 1 At the time of starting the RT bridge 1, that is, the initial state is listed below.
A: Only its own entry is registered in FDB4.
B: Nothing is recorded and stored in the MACRIB 6, the root path vector DB 7, the MAC subnet DB 8, and the neighbor table 9.
C: The unicast frame whose destination is unknown is transferred to the central processing unit 2 without flooding (this setting is not changed).
D: Broadcast frames are not flooded (only the central processing unit 2 is received in the initial state).
E: A frame whose source (source) MAC address has not been learned is transferred to the central processing unit 2 (this setting is not changed).
F: The FDB 4 does not autonomously perform address learning (this setting is not changed).
G: The FDB 4 does not execute address aging (this setting is not changed).
(2) FDB4 entry procedure The FDB4 entry procedure (step) will be described with reference to FIG. First, the existence of the adjacent RT bridge 1 is confirmed by the neighbor discovery (S01). The result of this neighbor discovery is recorded in the neighbor table 9.

  Next, the local host discovery (S02) is executed with reference to the record information of the neighbor table 9, and the host information is searched. The host information obtained here is piggybacked on the route advertisement (S03) and distributed in the network, and the MAC subnet DB8 of each of the RT bridges 1 is configured (S04).

  After that, a route path vector DB7 is configured by storing the result of the route advertisement & calculation (S03) (S05). MACRIB 6 is obtained by combining these two databases 7 and 8 (S06).

  An entry of the FDB4 is obtained from the MACRIB 6, and the FDB4 is set (S07). The RT bridge 1 relays communication between terminals based on the route information of the FDB 4. Hereinafter, each procedure will be described.

(3) Neighbor Discovery First, details of the neighbor discovery (S01) will be described. That is, the RT bridge 1 detects the presence of a neighbor prior to all operations. Here, the neighbor is defined as the adjacent RT bridge 1 directly connected to itself.

  For this neighbor detection, the RT bridge 1 periodically sends out the RT-BPDU 10 from all LAN ports P. In this RT-BPDU 10, a root path vector always having the root as its own is described. In this point, if a bridge ID having a higher priority than itself is detected, this is different from a normal STP having a specification in which a root path vector having the root as its own is not advertised.

  Next, the adjacent RT bridge 1 identifies the LAN port P that has received the RT-BPDU 10 as a “transit port” and the other LAN ports P as “edge ports”.

  When receiving “RT-BPDU10” from the neighbor, that is, when receiving “RT-BPDU10” with the root path cost = 1, the RT bridge 1 displays the received LAN port P number field. The bridge ID described in “RT-BPDU10” is registered in the neighbor table 9.

  Tables 1 to 5 show the state after neighbor discovery in the network configuration of FIG. Specifically, Table 1 shows a neighbor table 9 of the RT bridge 21 after the neighbor discovery is performed, Table 2 shows a neighbor table 9 of the RT bridge 22, and Table 3 shows a neighbor table of the RT bridge 23. 9, Table 4 shows the neighbor table 9 of the RT bridge 24, and Table 5 shows the neighbor table of the RT bridge 25.

  According to Tables 1 to 5, the identification of “transit port / edge port” and the bridge ID of the neighbor are registered and stored in the neighbor table 9 for each LAN port number. Here, only the LAN port numbers “1 to 3” are shown, but the LAN port numbers “4 to 8” are also registered in the same manner. Although the bridge ID of the neighbor is omitted in only the upper two bytes indicating the priority, the bridge ID of a hexadecimal value is actually described in the neighbor table 9.

(4) Local Host Discovery The RT bridge 1 monitors the transmission source MAC address of the Ethernet (registered trademark) frame received at the LAN port P, and if the MAC address is unknown, registers it in the MAC subnet DB8. This process is called local discovery (S02).

  More specifically, when an Ethernet (registered trademark) frame with an unknown source MAC address arrives at the LAN port P, it is transferred to the central processing unit 2 by the switch engine 3 (this function is implemented by a modern switch engine). If it is 3, it is provided.)

  The central processing unit 2 that has received the transfer registers the unknown MAC address in the MAC subnet DB 8 according to the identification information (the edge port / transit port in Tables 1 to 5) of the LAN port P that has received the unknown MAC address. Hereinafter, the processing content will be described with the unknown MAC address X and the receiving LAN port P1.

(A) When the receiving LAN port P1 is an edge port The entry of the MAC subnet DB8 is identified in the format of "bridge ID: connection port". Here, when the receiving LAN port P1 is an edge port, if there is no entry of “bridge ID: local port P1” in the MAC subnet DB 8, an unknown MAC address X is associated with the entry. The host registered in this way is called a “local host”.

(B) When the receiving LAN port P1 is a transit port When the receiving LAN port P1 is a transit port, if there is no entry of “bridge ID: transit port P1” in the MAC subnet DB8, an unknown MAC address is created in the entry. Associate X. The host registered in this way is called a “transit host”.

  If the frame received at this transit port is actually transferred via the other RT bridge 1, the registration as a transit host does not conform to the actual situation and is erroneous. However, by making the local host advertisement have higher priority than the transit advertisement in the route advertisement by the RT-BPDU 10, the registration is naturally corrected to the correct one.

  Tables 6 to 10 show the state after the execution of the local discovery in the network configuration of FIG. Specifically, Table 6 shows the MAC subnet DB8 of the RT bridge 21 after the local discovery is performed, Table 7 shows the MAC subnet DB8 of the RT bridge 22, and Table 8 shows the MAC subnet DB of the RT bridge 23. Table 9 shows the MAC subnet DB 8 of the RT bridge 24, and Table 10 shows the MAC subnet DB 8 of the RT bridge 25.

  In Tables 6 to 10, unknown MAC addresses are registered in units of “bridge ID: connection port”. However, at the stage after the local host discovery is performed, only the host that the RT bridge 1 has found is registered in the MAC subnet DB 8.

  Note that the entries learned by the other RT bridges 1 by the processing of the end host advertisement described later are distributed to each of the RT bridges 1. Thereby, finally, all the RT bridges 1 in the network have the same MAC subnet DB8.

(5) Route Advertisement & Calculation As described above, the RT bridge 1 periodically transmits the RT-BPDU 10 from all the ports (numbers 1 to 5) of the LAN port P.

  At this time, in the neighbor discovery (S01), the transmission and reception of the RT-BPDU 10 is for the purpose of confirming the existence of the neighbor. On the other hand, the main role of the RT-BPDU 10 is to distribute route information. The distribution of the route information of the RT-BPDU 10, that is, the aspect of the route advertisement (S03) will be described.

  As shown in FIG. 3A, most of the RT-BPDU 10 has the same definition as CFG-BPDU and RST-BPDU defined by IEEE 802.1D. In this field, a distance vector (distance information) called a “route path vector” is described. When the STP spanning tree algorithm is executed while exchanging this with a neighbor, the shortest path to the root bridge (the path that minimizes the root path cost) is obtained.

  However, in STP, the bridge with the smallest bridge ID (highest priority bridge) is selected as the root bridge. Only the shortest path to this root bridge is calculated, and all redundant links are closed to eradicate closed circuits in the network.

  On the other hand, in the RT bridge 1, the highest priority bridge is not selected, all the RT bridges 1 in the network are regarded as the root bridges, the spanning tree algorithm is individually executed, and the root path is set by the RT-BPDU 10. Perform vector distribution. This corresponds to distance vector type route calculation in RIP or the like.

  As a result, in a normal STP, each bridge holds only one root path vector, whereas each RT bridge 1 holds N root path vectors. Here, “N ≧ the number of the RT bridges 1 in the network” is satisfied. However, when there is no multipath, "N = the number of the RT bridges 1 in the network" is satisfied.

  At this time, one root path vector indicates the direction to a certain bridge. That is, since the transfer destination port is determined by the parameter "root port", holding the root path vectors of all the RT bridges 1 in the network means that the directions to all the RT bridges in the network can be grasped. Means that.

  Finally, the destination of the MAC address of the end host is registered in the FDB 4 using the root path vector (N pieces) and the registered contents of the MAC subnet DB 8. Here, the processing operation of the route advertisement will be mainly described.

(A) Transmission of RT-BPDU 10 at Edge Port Although no neighbor is connected at the end of the edge port and route advertisement is unnecessary, the RT bridge 1 may be connected later. Therefore, the RT-BPDU 10 is periodically transmitted to appeal the existence of the own RT bridge 1.

  However, the edge port transmits only the RT-BPDU 10 describing the root vector having the RT bridge 10 as a root, and does not transmit the RT-BPDU 10 describing the root vector having the other RT bridge 1 as a root. Shall be. Also, it is assumed that the end host advertisement is not added to the RT-BPDU 10 transmitted from the edge port.

(B) Transmission of RT-BPDU 10 in Transit Port The RT bridge 1 periodically transmits an RT-BPDU 10 describing a root path vector having its own root. However, advertising all the hosts every time is a heavy load, and there are cases where all of them cannot be described in one RT-BPDU 10. Therefore, posting in the end-host advertisement is limited to when an entry change occurs. This transmission mode is called “origin transmission” for convenience.

  The RT bridge 1 calculates a root path vector by executing a spanning tree algorithm when receiving an RT-BPDU 10 describing a root path vector rooted at another RT bridge 1 from a neighbor. The calculation result is described in the RT-BPDU 10 and transmitted to the neighbor in the leaf direction. This transmission mode is called “relay transmission” for convenience.

(C) End-host advertisement added to RT-BPDU 10 A method of adding (attaching) the end-host advertisement shown in FIG. 3B to the RT-BPDU 10 will be described.

  First, the end host advertisement can be added to the RT-BPDU 10 only in the case of the origin transmission as described above. On the other hand, in the case of relay transmission, the host advertisement of the RT bridge 1 that has transmitted the origin is transmitted to the RT-BPDU 10 and relayed to the neighbor without modification in this state.

  Next, as described above, the end host advertisement is attached only when the number of hosts increases or decreases due to local host discovery (S02). That is, when the RT bridge 1 detects a host in the local host discovery (S02), the MAC address of the host (terminal) is registered in the MAC subnet DB 8, and an "advertisement required flag" is set in the entry of the registration.

  When transmitting the RT-BPDU 10 next, the RT bridge 1 searches for an entry in which the advertisement required flag is set in the MAC subnet DB 8. Here, when an entry with an advertisement required flag is found, the entry is added to the end host advertisement field, and the advertisement required flag of the entry is withdrawn. As described above, according to the RT bridge 1, a host advertisement (for example, FIGS. 4A and 4B) is added to the end host advertisement field only when a host is detected / disappears, thereby suppressing bandwidth consumption. I have.

  However, there is a case where the RT bridge 1 cannot receive the end host advertisement, for example, the RTB PDU 10 is lost, or the RT bridge 1 enters the system later. Therefore, in the RT bridge 1, a method of synchronizing with the hash value of the host advertisement is introduced.

  That is, the “hash advertisement (FIG. 5A)” advertised by the RT bridge 1 is posted in the end host advertisement field of the RT-BPDU 10 that transmits the origin. The hash value here is a value obtained by sorting the MAC addresses of the advertising hosts in ascending order and calculating the CRC 32 thereof.

  At this time, also in the RT bridge 1 on the receiving side of the host advertisement, the hash value of the advertised MAC address is calculated and compared with the hash value advertised by the RT bridge 1 on the sending side to confirm synchronization. I do. As a result of the confirmation, if the hash values match, synchronization has been established, and no further action is required. On the other hand, if the hash values do not match, it is necessary to resynchronize.

  The RT bridge 1 that has confirmed and detected the mismatch of the hash values once discards all the host advertisements. Thereafter, when the next RT-BPDU 10 is transmitted as a starting point, “host advertisement request (FIG. 5B)” is posted in the end host advertisement field. Here, since the RT-BPDU 10 is received by all the RT bridges 1 in the network, the corresponding RT bridge always receives the RT-BPDU 10.

  The relevant RT bridge that has received this host advertisement request sets the advertisement required flag for all entries of its own local host and transit host registered in the MAC subnet DB8. As a result, the host advertisement is posted the next time the RT bridge 1 transmits the RT-BPDU 10 as a starting point.

  Here, if the number of hosts is too large to be placed in the end-host advertisement field at once, the host advertisement can be distributed over a plurality of origin transmissions and distributed (spread) over the network. After receiving the host advertisement, the RT bridge 1 cannot issue the next host advertisement request until the host advertisement from the relevant RT bridge runs out after the host advertisement request.

  When the connection port is a local port, the value of the port number is unnecessary for the other RT bridge 1. This is because the transfer destination is not known to the other RT bridge 1 even if the end host is connected to any port of the last hop RT bridge 1.

  Then, in order to reduce the processing load, it is better not to sort the host advertisement by the port ID of the local port. Every time a distinction is made, hash synchronization is required each time, and the load is unnecessarily increased. In this regard, the RT bridge 1 does not discriminate the host advertisement by the port ID of the local port, and uses "255 (0xFF)" as a pseudo port number representing the local port. By advertising the pseudo port ID, classification of the host advertisement due to the difference in the local port is avoided.

(6) Configuration of MAC Subnet DB 8 As described above, the end host detected by the local host discovery (S02) is additionally posted at the end of the RT-BPDU 10 in the form of an end host advertisement (FIGS. 3A and 3B). And distributed within the network.

  At this time, the RT bridge 1 that has received the RT-BPDU 10 refers to the end host advertisement added to the end of the RT bridge 1, and if it finds an entry change unknown to itself, adds / deletes it to its MAC subnet DB 8. As described above, when a mismatch between the advertised hash values is confirmed and detected, a host advertisement request for synchronization (FIG. 5B) is made as described above.

  By proceeding with such a process, the host advertisement eventually reaches the network, and all the RT bridges 1 hold the MAC subnet DB 8 having the same contents.

  Table 11 shows the stored contents of the MAC subnet DB 8 after the end host advertisement has converged in the network configuration of FIG. Here, the MAC address of the end host is registered and stored for each “bridge ID: connection port”.

(7) Root Path Vector DB Configuration Each of the RT bridges 1 individually calculates a root path vector for all of the RT bridges 1 in the network as described above. The root path vector calculated here is used when constructing the MACRIB 6, and therefore must always be referred to. The route path vector DB7 is constructed based on the result of the calculation of the route path vector, that is, the result of the route calculation (S05).

  Tables 12 to 16 show the state after the convergence of the route calculation in the network configuration of FIG. Specifically, Table 12 shows a root path vector DB7 of the RT bridge 21 after the path calculation contraction, Table 13 shows a root path vector DB7 of the RT bridge 22, and Table 14 shows a root path vector of the RT bridge 23. Table 15 shows a root path vector DB7 of the RT bridge 24, and Table 16 shows a MAC subnet DB8 of the RT bridge 25.

  In Tables 12 to 16, only the root bridge ID, the root path cost, the representative bridge ID, and the root port in the root path vector are shown for convenience.

  The root bridge ID records the bridge IDs of the RT bridges 21 to 25, the root path cost records the root path cost that regards the RT bridges 21 to 25 as the root bridge, and the representative bridge ID records the root bridge ID up to the root bridge. Is recorded, and the root port records a root port indicating the shortest LAN port number from itself to the root bridge.

  Since it is difficult to imagine this bridge ID as a hexadecimal value, it is represented by a name, and all port path costs are set to "1" for simplicity. The information stored in the root path vector DB 7 is not limited to the above-described elements, and other elements of the root vector shown in FIG. 3A can be similarly recorded.

(8) Synthesis of MACRIB The root path vector DB7 stores all the root path vectors calculated by the respective RT bridges 1. Therefore, by referring to the root path vector DB7, it is possible to know the transfer destination ports to all the RT bridges 1 in the network. Further, by referring to the MAC subnet DB 8, it is possible to know the MAC subnet and the end host connected thereto.

  However, individual end hosts and their transfer destination ports cannot be obtained simply by referring to the root path vector DB7 and the MAC subnet DB8 alone. Therefore, in order to enter the FDB 4 as the route information, a table holding the MAC address and the number of the transfer destination port as a comparison is created as the MAC RIB 6.

  In this MACRIB 6, one entry is composed of a pair of a MAC address and a root path vector. A parameter called a root port included in the root path vector indicates a transfer destination, and it is possible to associate a MAC address with a transfer destination port.

Specifically, the synthesis of MACRIB6 is performed according to the following procedure.
(A) List all the end hosts from the MAC subnet DB8.
(B) List MAC subnets (bridge IDs: connection ports) corresponding to the end hosts listed in the procedure (A).
(C) The root path vector whose root is the bridge ID of the MAC subnet is read from the root path vector DB 7 and is associated with the enumeration information of the procedures (A) and (B).
(D) In step (C), the synthesis of the entry having the MAC address and the root path vector of “1: 1” is completed. Here, when both become "1: many", the root path vector with the minimum root path cost is selected. When there are a plurality of route path vectors having the minimum route path costs, one of them is selected.

  Of the procedures (A) to (D), the same result is obtained in all the RT bridges 1 up to the procedures (A) and (B). On the other hand, after the procedure (C), a different result is obtained for each RT bridge 1. Tables 17 to 21 show the execution results of procedures (A) to (D) in the network and work configuration of FIG.

  Table 17 shows a "MAC address and MAC subnet comparison table" after executing the procedures (A) and (B), and the same result is obtained in all the RT bridges 21 to 25.

  Table 18 shows a "comparison table of MAC addresses and root path vectors" after the procedures (C) and (D) are performed in the RT bridge 21. According to Table 18, a plurality of route path vectors correspond to the MAC addresses “terminals 101 to 104”.

  Table 19 shows a state in which “the comparison table between the MAC address and the root path vector” in Table 18 is narrowed down by the root path cost, and the shaded column indicates the root path vector that has been dropped.

  As a result, all the addresses other than the MAC address “terminal 103” were narrowed down to “1: 1”. On the other hand, since the plurality of root path vectors of the MAC address “terminal 103” are equal cost multipaths (equal cost multipaths), either one may be selected.

  In this case, the STP prefers the smaller bridge ID, but the RT bridge 1 does not need to do so. Rather, if some sort of hash calculation is performed on the MAC address to distribute the selection, load distribution can be easily realized.

  Table 20 shows a state in which the root vector of the RT bridge 22 is selected for the MAC address “terminal 103” in Table 19, and the RT bridge 23 is shaded. As a result, the root path vector is narrowed down to “1: 1” for all MAC addresses.

  Table 21 shows a state where the dropped route vector (shaded column) from Table 20 is removed and the root port is displayed in another column. However, the connection port of the host (local host / transit host) directly connected to itself is to be read from the MAC subnet DB 8 (the root port vector having itself as the root does not include the root port). The connection port read from the MAC subnet DB 8 is indicated by “*” in Table 21.

(9) Setting of FDB4 As shown in Table 21, when the synthesis of MACRIB6 is completed, the relationship between the MAC address and the transfer destination port is obtained. If this is reflected (copied) in the FDB 4, the switch engine 3 performs switching and communication between end hosts is realized. Thereby, the following effects can be obtained.

  (A) It is possible to prevent the frame from infinitely cycling without the closing port. In this respect, the band can be effectively used. Further, since no flooding is used, band consumption can be prevented.

  (B) The frames are switched by the shortest path between any end hosts, and unnecessary detours are prevented in communication in a loop-like redundant network. In this respect, effects such as prevention of band consumption and reduction of transmission delay can be obtained.

  (C) As shown in Tables 19 and 20, when there is an equal-cost multipath root path vector, path distribution can be performed by arbitrary hash calculation or the like. In this regard, the communication load can be distributed.

  (D) The connection configuration of the RT bridge 1 can be easily grasped by referring to the neighbor table 9 and the route path vector DB7. In this regard, maintenance can be improved.

  (E) The existence of the end host can be managed by the protocol, and the maintenance and security are improved in this respect as well. It should be noted that the MTU problem does not occur due to no tagging encapsulation, and the function of the switch engine 3 is low. In this respect, the cost can be reduced (a chip having a special function is generally effective).

1, 21 to 25: RT bridge (relay device)
2. Central processing unit 3. Switch engine 4. FDB (storage unit)
6 MACRIB (storage information)
7. Root path vector DB (third storage unit)
8. MAC subnet DB (second storage unit)
9: Neighbor table (first storage unit)
10 RT-BPDU (protocol data unit)
101-104, 121-125 ... terminal

Claims (7)

A relay device that relays communication between terminals in a redundant network and includes a storage unit that stores path information to each terminal,
The route information includes a MAC address of each terminal,
A route path vector having a relay device as a route that relays the terminals,
Is retained in the control,
A relay device for relaying communication between the terminals based on the route information. If there are a plurality of the root path vectors, the root path vector to the route is selected the root path vector with the minimum,
2. The relay device according to claim 1, wherein when there are a plurality of the route vectors having the minimum route path costs, one is arbitrarily selected. The relay device according to claim 1, wherein a port number closest to the root is associated with the MAC address and the root path vector. 4. By transmitting and receiving the protocol data unit in which the route path vector is described between adjacent relay devices,
3. The relay device according to claim 2, wherein the route path vector having the minimum route path cost is obtained. Identification information for each port according to the presence or absence of the reception of the data unit, a first storage unit that stores the information of the adjacent relay device connected to the port in association with each other,
A second storage unit that stores a MAC address of the terminal connected to each port of each of the relay devices;
A third storage unit in which the root path vector is stored,
When creating the storage information of the second storage unit and the storage information of the third storage unit, the storage information of the first storage unit is referred to,
The relay device according to claim 4, wherein the route information is created by combining the storage information of the second storage unit and the storage information of the third storage unit. While periodically transmitting the data unit between the adjacent relay device and creating data to be stored in the first storage unit,
In the data unit, the route vector having the source relay device as a route is described,
The relay device according to claim 4, wherein the route unit is configured to transmit and receive the data unit to and from the adjacent relay device to obtain the root path vector having the minimum route path cost. When entering the information of the MAC address in the second storage unit, the entry is flagged,
As a result of searching the first database when transmitting the data unit, if the flag is found,
The relay device according to claim 5, wherein the information of the entry is added to the data unit and transmitted, and the flag is lowered after the transmission.

Images