JP2013078012A - Management method of route table in bgp router and management server - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a management method of a route table for which complicated design or BGP protocol expansion is not required, and a management server.SOLUTION: A route table is received from a router 10 and a prefix is collected by a BGP receiver 2. Destination IP addresses of data packets relayed by the router 10 for a predetermined period are collected by a packet information receiver 3. Each destination IP address is allocated to the prefix and a use frequency as a destination of the prefix for a predetermined period is aggregated by a frequency aggregation part 4. A message to delete the prefix whose aggregated frequency is low is transmitted to the router 10 by a message transmitter 5. Further, a default route is set to the router 10 as another router for securing an arrival possibility of the prefix from which the next hop has been deleted.

Description

  The present invention relates to an efficient route table management method and management server in a BGP (Border Gateway Protocol) router.

  Prefixes advertised by BGP on the Internet are increasing year by year, and there is a problem that the number of prefixes observed is approaching the upper limit of the number of prefixes that can be managed in the route table on the router memory. For this reason, efficient management of prefixes is an issue. The prior art described in Non-Patent Document 1 proposes a method for managing a routing table in a distributed manner by a plurality of routers.

  FIG. 4 is a diagram for explaining the related art. Normally, a BGP router connected to a default free zone (DFZ; network without a default route) manages all prefixes observed on the Internet in a route table. In the configuration of FIG. 4, it is assumed that all prefixes observed on the Internet are a total of six from 192.168.0.0/24 to 192.168.5.0/24, and the routers A to C adjacent to each other have routing tables TA1 to TC1 respectively. As shown below, all these prefixes are managed in association with the next hop.

  In contrast to this configuration, in the prior art, the routing table prefix is distributed and managed by the plurality of routers A to C by the following method. That is, 6 prefixes are distributedly managed in the router A and the router B having connection with other AS (Autonomous System). For example, the router A manages three of 192.168.0.0/24 to 192.168.2.0/24, and the router B manages three of 192.168.3.0/24 to 192.168.5.0/24. However, since it is necessary to guarantee reachability for prefixes held by other routers, as shown in Table T2, prefixes that are aggregated within a range that can be aggregated are managed. As a result, the number of prefixes managed by each router can be reduced to 5 (reduced to 5/6) as shown in the route tables TA2 and TB2 for the routers A and B, respectively. In the router C in the own AS, which has no connection with other ASs, all the aggregated prefixes are managed, so that it can be reduced to 4 (reduced to 4/6) as shown in the route table TC2.

FIB Suppression with Virtual Aggregation, Internet Draft, http://tools.ietf.org/id/draft-ietf-grow-va-05.txt

  However, in the prior art, in order to efficiently reduce the number of prefixes managed by each router, in addition to the prefix aggregation method according to the above method, the traffic volume flowing to each prefix is reduced according to the actual operation. Since it is necessary to distribute the prefix after consideration, there is a problem that the design is complicated. Furthermore, in order to automate the distribution process, there is a problem that it is necessary to extend the BGP protocol.

  The object of the present invention is to solve the above-mentioned problems of the prior art and efficiently reduce the number of prefixes managed by a BGP router without requiring a complicated design and without requiring an extension of the BGP protocol. An object of the present invention is to provide a routing table management method and management server in a BGP router.

  In order to solve the above-described problems of the prior art, the present invention is a routing table management method in a BGP router, which collects prefixes described as destinations in the routing table from a first BGP router that manages the routing table. Collecting a destination IP address of each packet relayed by the first BGP router over a predetermined period, assigning the collected destination IP address to the collected prefix, A step of aggregating the frequency used as a destination over a predetermined period, and deleting a prefix satisfying a predetermined criterion relating to the low frequency from the route table in the first BGP router, and a route in the first BGP router A step of setting a default route having the second BGP router as the next hop in the table; and Setting a prefix satisfying the predetermined criterion as a destination in a routing table.

  In order to solve the above-described problems of the prior art, the present invention provides a routing table management server in a BGP router, and a prefix described in the routing table as a destination from a first BGP router that manages the routing table. A BGP receiving unit for collecting, a packet information receiving unit for collecting a destination IP address of each packet relayed by the first BGP router over a predetermined period, and the collected prefix for the collected destination IP address A frequency counting unit that counts the frequency at which each prefix was used as a destination over the predetermined period, and a BGP that deletes a prefix that satisfies the predetermined criterion regarding the low frequency from the routing table in the first BGP router A BGP message that sets a default route with the second BGP router as the next hop in the route table of the first BGP router; A message transmission unit configured to transmit a BGP message in which a prefix satisfying the predetermined criterion is set as a destination in the route table in the second BGP router.

  According to the present invention, the number of prefixes in the first BGP router is reduced by managing only the prefixes with a transfer record that requires packet transfer by the first BGP router, and even if there is no transfer record. A prefix that may newly need to be transferred after the predetermined period is managed by the second BGP router, thereby ensuring reachability. In addition, each of the effects can be achieved by a simple design that does not require extension of the BGP protocol.

It is a functional block diagram of the management server of a routing table. It is a flowchart of the management method of a routing table. FIG. 3 is a diagram for explaining FIG. 2. It is a figure for demonstrating a prior art.

  FIG. 1 shows a functional block of a routing table management server according to the present invention including communication with a BGP router. The management server 1 includes a BGP receiving unit 2, a packet information receiving unit 3, a frequency counting unit 4, and a message transmitting unit 5, and performs various communications with a BGP router 10 including a mirror port 11. Set and manage.

  FIG. 2 shows a flowchart of a routing table management method according to the present invention. FIG. 3 is a diagram for explaining the flowchart, and the network configuration example here is the same as the example shown in FIG. That is, as an example of the BGP router 10, there are routers A, B, and C assigned IP addresses 11.0.0.1, 11.0.0.2, and 11.0.0.3, respectively, within the local AS. The total number of prefixes to be managed is 192.168.0.0/24 to 192.168.5.0/24, and in a state where the present invention is not applied, the routers A to C do not have the default route shown in FIG. Managed by TA1 to TC1. Further, in another AS, there is a router Z to which an IP address 10.0.01 is assigned as an example of a next hop router, and is connected to routers A and B.

  In the present invention, the management server 1 (IP address 11.0.0.5) is arranged in the self-AS having such a configuration (only one is required), and is newly one of the BGP routers 10 as necessary. Router D (IP address 11.0.0.6) is installed. In addition, between each of the routers A to C and the management server 1 or the router D, between the management server 1 and the router D, and between the management server 1 or the router D and the router Z are adjacent to each other in BGP. To do. That is, the management server 1 has the function of a BGP router like the routers A to D.

  In this example, there is only one other AS in FIG. 3 for the own AS, and only one router Z is connected to the own AS as the next hop in the other AS. More generally, even when there are a plurality of routers Zi that are the next hops in other ASs and / or other ASs (i = 1, 2,..., N), each router Zi of each other AS is the management server 1 or router D. The present invention is generally applicable by being adjacent to each other.

  Hereinafter, each step of FIG. 2 started from step S1 will be described. In step S2, the BGP receiving unit 2 establishes a BGP session by exchanging necessary BGP messages with the adjacent BGP router 10 and acquires a route table such as TA1 to TC1 in FIG. Collect all prefixes (192.168.0.0/24 to 192.168.5.0/24) listed as destinations. In step S3, the packet information receiving unit 3 receives information on the data packet relayed by the BGP router from the mirror port 11 of the BGP router 10 for a predetermined period such as one day or one month, particularly the destination IP of each packet. Receive and collect address information.

  In steps S2 and S3, only one arbitrary router among the routers A to C may be selected and communicated as the BGP router 10 to be communicated. For example, in FIG. In step S2, not all of the routing table may be received, but only the prefix described as the destination may be received and collected. In step S3, it is not necessary to receive the same information directly from the mirror port 11 in real time as long as the same information is acquired or stored in advance as a database or the like.

  In step S4, the frequency counting unit 4 maps the prefix of the routing table collected in step S2 and the destination IP address collected in step S3 according to the longest match algorithm, and the number of packets observed for each prefix. Are counted. That is, the frequency at which each prefix was used as the destination of each packet over the predetermined period of step S3 is totaled. A tabulation example of step S4 is shown in a table T30 in FIG.

  In step S5, an identification counter i for executing the subsequent steps is set to an initial value 1 for each prefix collected in step S2. As will be described below and described in FIG. 2, processing corresponding to the corresponding case among the cases (1) to (3) is performed for each prefix i.

  In step S6, the frequency counting unit 4 determines whether the i-th prefix is a deletion target. Here, when the prefix i corresponds to the predetermined condition on the side with less frequency in the counting result of step S4, it is determined that the object is to be deleted. In the example of FIG. 3, as shown in the table T30, prefixes 192.168.3.0/24, 192.168.4.0/24, and 192.168.5.0/24 that have 0 observation packets and are not actually used are subject to deletion. Determined. As other predetermined conditions, for example, the number of observed packets may be 100 or less within the predetermined period of step S3.

  If it is determined that it is to be deleted in step S6 [Case (1)], a BGP message for deleting the prefix i from the routing table of each BGP router 10 (routers A to C in FIG. 3) in step S7, that is, The message transmission unit 5 transmits a Withdraw message for the prefix i to each BGP router 10. At this time, NO EXPORT is set as the COMMUNITY attribute to prevent the Withdraw message from leaking to the AS.

  In step S7, the next hop described in the routing table at the time point at each router A to C for the deleted prefix i is managed in preparation for the case where the deleted prefix i is to be added in step S10 described later. It is assumed that the server 1 records it.

  In addition, after the entire flow of FIG. 2 is finished, if there is a route change for the deleted prefix i, the following processing is performed to repeat the flow of FIG. Prepare for. That is, when the routers A to C and the management server 1 receive the notification of the route change, the routers A to C first reflect the prefix i in the route table managed and reflect the notified route change. to add. Immediately after the addition, the management server 1 performs the same processing as the step S7 and the later-described step S8 on the prefix i, and changes the next hop in the prefix i in the route table managed by itself. Reflect the route change and update the route table. In this way, the prefix i that has undergone the route change is not described in the route table of each of the routers A to C (by being deleted immediately after addition), and the route change is reflected in the route table of the management server 1. Will be managed.

  In step S8, in order to guarantee reachability to the deleted prefix i, the default route 0.0.0.0/0 is advertised from the message transmission unit 5 to each BGP router 10 (routers A to C). At this time, as the next hop of the default route, when the router D can be additionally used separately from the IP address of the management server 1 itself or the routers A to C that originally managed all the prefixes, The IP address is publicized to the routers A to C.

  In step S8, the message transmitting unit 5 further transmits a BGP message for setting the prefix i deleted by the routers A to C as the destination in the route table of the management server 1 or the router D set as the next hop. . At this time, the next hop of the destination prefix i can be set to the router belonging to the other AS (the router Z having the IP address 10.0.0.1 in FIG. 3) among the next hops recorded in step S7. In addition, when setting to management server 1 itself, you may abbreviate | omit transmission of a BGP message.

  In addition, when the management server 1 is used without additionally using the router D, the management server 1 can be considered to also serve as a BGP router of the router D that can be considered to be additionally used.

  The routing table T3 in FIG. 3 is an example of the routing table set in the management server 1 or the router D when the prefix with the number of packets 0 is to be deleted in the case of the aggregation result shown in the table T30.

  Returning to step S6, when the predetermined condition is not met and the prefix i has a predetermined usage record and is not determined to be deleted [Case (2) or (3)], the prefix i is determined in step S9. The frequency counting unit 4 determines whether it is an addition target.

  It is determined to be an additional target that the entire flow of FIG. 2 is performed twice or more in different predetermined periods in step S3, for example, once in September and again in October. When the prefix i is determined to be a deletion target in step S6 in the immediately preceding time (for example, the time of implementation in September), but this time (for example, the time of the execution in October) is not determined to be a deletion target [ Case (2)].

  The prefix i determined in this way has been deleted from the routing table of the routers A to C in the previous round, and this time needs to be returned to the routing table of the routers A to C, that is, is an addition target. Therefore, in step S10, the message transmission unit 5 transmits a BGP message, that is, an Announce message, which causes each BGP router 10 (routers A to C) to set the prefix i as a destination. In this case as well, as with Withdraw, the NO EXPORT attribute is enabled to prevent the Announce message from leaking to the AS.

  At this time, the next hop of the destination prefix i is deleted in the previous step S7 and recorded by the management server 1, and if there is a route change for the deleted prefix i as described above, The next hop updated in the routing table of the management server 1 is set in each of the routers A to C.

  When the entire flow of FIG. 2 is performed twice or more, the route table of the routers A to C and the route table of the management server 1 or the router D reflecting the route change after the first time are reflected in the second and subsequent times. Holds all the prefixes at that time. Therefore, in the second and subsequent steps S2, the BGP receiving unit 2 collects all prefixes not only from the route table of any of the routers A to C as described above but also from the route table of the management server 1 or the router D. And

  Returning to step S9, if it is not determined to be added [Case (3)], since the prefix i is a prefix that should be described in the route table of each router A to C as it is, neither Withdraw nor Announce is required. Yes, no operation is performed on the prefix i in the routing table.

  When the processing in any of the cases (1) to (3) is completed for the prefix i as described above, in step S11, the frequency counting unit 4 determines whether the processing has been completed for all the prefixes. In step S13, the flow ends. If not completed, the counter i is incremented and the flow is repeated from step S6 again for the next prefix.

  The route tables TA3 to TC3 in FIG. 3 are obtained as a result of the aggregation shown in the table T30 by the flow as described above, and the route table shown in T3 is set in the management server 1 with the IP address 11.0.0.5 (not the router D). It is an example of a route table set in the routers A to C when Furthermore, the flow is performed again, and unlike the initial count result T30, for example, the number of packets of 192.168.3.0/24 is not 0 but a considerable number such as 300 is obtained, and the number of observed packets in other prefixes is the same. If there is no route change before the process is performed again, each route table is updated as follows.

  That is, “prefix 192.168.3.0/24 next hop 10.0.0.1” is added in the route tables TA3 and TB3, and “prefix 192.168.3.0/24 next hop 11.0.0.1” is added in the route table TC3. “Prefix 192.168.3.0/24 Next hop 10.0.0.1” will be deleted.

  Regarding the transmission of each BGP message and the construction of the routing table T3 in steps S7, S8, and S10, the BGP message transmission and the routing table are constructed individually for each prefix i simultaneously with the judgment of cases (1) to (3). Instead, only the determination may be made in advance for all prefixes, and the corresponding prefixes may be stored together in a message and performed in a batch to improve the efficiency of transmission and construction.

  In addition, when the entire flow of FIG. 2 is executed for the second time or later, if the prefix i follows the case (1) this time, the prefix in which a difference has occurred between this time and the previous time, as in the determination in step S9. Only the processing target may be used. That is, steps S7 and S8 are executed only for those prefixes i that follow case (1) this time that last followed case (2) or (3) and now follow case (1). In the same manner, since the case that followed the case (1) in the previous time has already been deleted from the route table of the routers A to C, steps S7 and S8 may be omitted.

  As a simpler embodiment of the present invention, the transmission of the default route in step S8 may be omitted. In the case of the route table created in this case, in the example of FIG. 3, “prefix 0.0.0.0/0 next hop 11.0.0.5” is deleted from the route tables TA3 to TC3, and the destination is the prefix 192.168.3.0/24,192.168. When a packet corresponding to 4.0 / 24 or 192.168.5.0/24 appears after application of the routing table, it is discarded by the routers A to C. Instead, as an advantage, there is no need to construct a network configuration that defines the next hop corresponding to the prefix using the management server 1 or the router D.

  Similarly, although the default route is transmitted, the reachability after the data packet is transferred to the management server 1 or the router D may not be guaranteed. In either case, since the deletion target is determined based on the number of observed packets, if the data is observed over a predetermined period that is statistically valid, the number of data packets that are discarded is small. It is possible to efficiently reduce the routing table while normally transferring a large number of data packets with the network configuration.

  DESCRIPTION OF SYMBOLS 1 ... Management server, 2 ... BGP receiving part, 3 ... Packet information receiving part, 4 ... Frequency totaling part, 5 ... Message transmission part, 10 ... BGP router

Claims (5)

A routing table management method in a BGP router,
Collecting a prefix described as a destination in the routing table from a first BGP router managing the routing table;
Collecting a destination IP address of each packet relayed by the first BGP router over a predetermined period;
Assigning the collected destination IP addresses to the collected prefixes and aggregating the frequency with which each prefix was used as a destination over the predetermined period;
A prefix that satisfies the predetermined criteria regarding the low frequency is deleted from the routing table in the first BGP router, and a default route with the second BGP router as the next hop is set in the routing table in the first BGP router And steps to
A routing table management method in the BGP router, comprising: setting a prefix that satisfies the predetermined criterion in the routing table in the second BGP router as a destination. Performing the steps of collecting the destination IP address and counting the frequency again;
A step of setting a prefix whose frequency counted again does not satisfy the predetermined criterion as a destination in the routing table in the first BGP router and deleting it from the routing table in the second BGP router;
A step of deleting a prefix whose frequency counted again meets the predetermined criterion from the routing table in the first BGP router and setting as a destination in the routing table in the second BGP router; The routing table management method in the BGP router according to claim 1.   The first and second BGP routers belong to a predetermined AS, are deleted from the routing table, and each BGP message when setting as a destination in the routing table is closed and flows in the AS. Item 3. A routing table management method in the BGP router according to item 1 or 2. A routing table management server in a BGP router,
A BGP receiver that collects prefixes described as destinations in the routing table from a first BGP router that manages the routing table;
A packet information receiving unit that collects a destination IP address of each packet relayed by the first BGP router over a predetermined period;
A frequency counting unit that assigns the collected destination IP addresses to the collected prefixes and totals the frequency at which each prefix was used as a destination over the predetermined period;
A BGP message that deletes a prefix that satisfies the predetermined criteria regarding the low frequency from the routing table in the first BGP router, and a default route that has the second BGP router as the next hop in the routing table of the first BGP router A message transmission unit that transmits a BGP message that sets a prefix and a BGP message that sets a prefix that satisfies the predetermined criterion in a route table in the second BGP router as a destination.   The management server according to claim 4, which also serves as the second BGP router.