Method to scale hierarchical route reflectors using automated outbound route filtering-list mechanism

BACKGROUND

0001The Border Gateway Protocol (BGP) is an interautonomous system routing protocol. An autonomous system (AS) is a network or group of networks under a common administration and with common routing policies. BGP is used to exchange routing information for the Internet and is the protocol used between Internet Service Providers (ISPs). Customer networks usually employ an Interior Gateway Protocol (IGP) such as Routing Interior Protocol (RIP), which specifies how routers exchange routing table information. With RIP, routers periodically exchange entire tables. Another IGP is known as Open Shortest Path First (OSPF) protocol. In OSPF the routers use link-state algorithms to send routing information to all nodes in an internetwork by calculating the shortest path to each node based on a topography of the network constructed by each node. Each router sends the particular portion of the routing table that describes the state of its own links, and it also sends the complete routing structure (topography). An advantage of OSPF is that it results in smaller more frequent updates everywhere. The updates converge quickly, thus preventing such problems as routing loops and Count-to-Infinity (when routers continuously increment the hop count to a particular network). This makes for a more stable network.

0002Customers connect to ISPs, and ISPs use BGP to exchange customer and ISP routes. When BGP is used between autonomous systems the protocol is referred to as External BGP (EBGP). If a service provider is using BGP to exchange routes within an AS, then the protocol is referred to as Interior BGP (IBGP). BGP neighbors exchange full routing information when the TCP connection between neighbors is first established. When changes to the routing table are detected, the BGP routers send to their neighbors only those routes that have changed. BGP routers do not send periodic routing updates, and BGP routing updates advertise only the optimal path to a destination network.

0003BGP uses many route parameters to define routing policies and maintain a stable routing environment. Routes learned via BGP have associated properties (also referred to as attributes) that are used to determine the best route to a destination when multiple paths exist to a particular destination. These attributes include: Weight, Local Preference, Multi-Exit Discriminator, Origin, AS_Path, Next Hop and Community.

0004BGP also has mechanisms such as Outbound Route Filtering (ORF) which enable the proper set of Virtual Private Network (VPN) routing distribution constraints to be dynamically distributed. This reduces the management burden of setting up the constraints, and results in improved scalability.

0005Within a single routing domain it is common to have the IBGP routers peer directly with one or two route reflectors (described below), rather than having them peer directly with each other. This greatly reduces the number of IBGP adjacencies which any one router must support. Further, a route reflector does not merely redistribute routing information, it “digests” the information first, by running its own decision processes. Only routes which survive the decision process are redistributed.

0006A route reflector reflects routes between the two groups: client peers and all the other routers in the autonomous system (non-client peers). The route reflector and its client peers form a cluster. The non-client peers are fully meshed with each other, but the client peers need not be fully meshed. When the route reflector receives an advertised route from an external BGP speaker, the route is advertised to all clients and non-client peers. When the route reflector receives an advertised route from a non-client peer, the route is advertised to all clients. When the route reflector receives a route from a client, the route is advertised to all clients and non-client peers. Hence, the clients need not be fully meshed.

0007As a result, when route reflectors are used, the amount of routing information carried around the network, and in particular, the amount of routing information which any given router must receive and process, is greatly reduced. This greatly increases the scalability of the routing distribution system.

0008An Automated ORF-list mechanism that provides the ability to filter routes at the Route Reflector (RR) is described in co-pending patent application, attorney docket number CIS04-14, filed May 27, 2004, titled AUTOMATIC ORF-LIST CREATION FOR ROUTE PARTITIONING ACROSS BGP ROUTE REFLECTORS, the disclosure of which is incorporated by reference herein. The result of the mechanisms described in the above-identified co-pending application number is the aggregation of route filters (ORF lists) at the RRs and the scaling of Provider Edge (PE) routers through filtering of unwanted route information. This filtering is done by the RRs by not advertising unwanted routes to the PEs.

SUMMARY

0009Conventional mechanisms such as those explained above suffer from a variety of deficiencies. The ability to filter routes at the RR level has been useful, however such a mechanism imposes a restriction of a single route-reflection hierarchy. The RRs still end up storing all the routes received from their clients. As the RR hierarchy grows, each RR located higher in the hierarchy ends up storing a lot of routes (complete view of an AS and its transit routes if any). This is so because the Automated ORF-list filtering works from the PE (RR-Client) to RR and not vice versa.

0010Embodiments of the invention significantly overcome such deficiencies and provide mechanisms and techniques that provide a method to scale hierarchical route reflectors using an automated ORF-list mechanism. The present invention identifies RRs which are in turn configured as RR-Clients within a RR hierarchy and defines rule-sets to perform RR to RR filtering, thereby allowing the higher level RRs in the hierarchy to prune unwanted route information.

0011In one embodiment a method and rulesets for ORF-lists is extended so as to perform VPN route filtering between RRs. This proposed VPN route filtering takes place at an RR which is higher up in the RR hierarchy and another RR, which is a client of the higher RR. Each BGP RR explicitly configures some of its IBGP neighbors as RR-Clients (clients). This allows an RR to distinguish its IBGP neighbors from its IBGP neighbors who are clients. Furthermore, each RR knows about itself, whether it is an RR or not. Using a new BGP capability, each RR advertises to all its peers that it is an RR router. With the new information from the new BGP capability, each RR knows which of its peers are in turn RRs, and which of its peers are not RRs. From information obtained from its configuration, each RR knows which of its peers are its clients, and which of its peers are not its clients. The above two pieces of information assists a BGP speaker in identifying which of its peers is an RR, and, in addition, which of its peers are its clients. Once this is established, the rule-sets defined in conventional mechanisms such as those described above are modified. An RR creates a common set of Route Target filters received from its all clients. The RR then sends the common set of filters to all its clients, who are also RRs.

0012The mechanism described above provides an RR the ability to recognize which of its clients are in turn RRs in a lower level hierarchy. This way, an RR higher in the hierarchy can distinguish its clients into two groups—those which are RRs and those which are not RRs. Announcing Route Target filters to its lower level RRs, assists the higher level RRs to limit their BGP VPN routing table to only the required set of routes thus pruning unwanted routes.

0013In a particular embodiment of a method for providing a method of scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering (ORF) The method includes identifying, by a first RR, other RRs configured as RR clients within a route reflector hierarchy. Once this is done, a common set of route target filters received from the client RRs is built by the first RR. The first RR then sends the common set of route target filters to the RR clients which results in the higher level RRs limiting their BGP VPN routing table to only the required set of routes.

0014Still other embodiments include a computerized device, configured to process all the method operations disclosed herein as embodiments of the invention. In such embodiments, the computerized device includes a memory system, a processor, communications interface in an interconnection mechanism connecting these components. The memory system is encoded with a process that provides a method of scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering (ORF) as explained herein that when performed (e.g. when executing) on the processor, operates as explained herein within the computerized device to perform all of the method embodiments and operations explained herein as embodiments of the invention. Thus any computerized device that performs or is programmed to perform up processing explained herein is an embodiment of the invention.

0015Other arrangements of embodiments of the invention that are disclosed herein include software programs to perform the method embodiment steps and operations summarized above and disclosed in detail below. More particularly, a computer program product is one embodiment that has a computer-readable medium including computer program logic encoded thereon that when performed in a computerized device provides associated operations providing a method of scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering (ORF) as explained herein. The computer program logic, when executed on at least one processor with a computing system, causes the processor to perform the operations (e.g., the methods) indicated herein as embodiments of the invention. Such arrangements of the invention are typically provided as software, code and/or other data structures arranged or encoded on a computer readable medium such as an optical medium (e.g., CD-ROM), floppy or hard disk or other a medium such as firmware or microcode in one or more ROM or RAM or PROM chips or as an Application Specific Integrated Circuit (ASIC) or as downloadable software images in one or more modules, shared libraries, etc. The software or firmware or other such configurations can be installed onto a computerized device to cause one or more processors in the computerized device to perform the techniques explained herein as embodiments of the invention. Software processes that operate in a collection of computerized devices, such as in a group of data communications devices or other entities can also provide the system of the invention. The system of the invention can be distributed between many software processes on several data communications devices, or all processes could run on a small set of dedicated computers, or on one computer alone.

0016It is to be understood that the embodiments of the invention can be embodied strictly as a software program, as software and hardware, or as hardware and/or circuitry alone, such as within a data communications device.

BRIEF DESCRIPTION OF THE DRAWINGS

0017The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

0018<figref idref="DRAWINGS">FIG. 1</figref> comprises a block diagram of a conventional network environment;

0019<figref idref="DRAWINGS">FIG. 2</figref> comprises a block diagram of the conventional network environment of <figref idref="DRAWINGS">FIG. 1</figref> which further provides automatic ORF-list creation for route partitioning across BGP route reflectors;

0020<figref idref="DRAWINGS">FIG. 3</figref> comprises a block diagram of a particular embodiment of a network environment utilizing a method of scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering (ORF Outbound Route Filtering in accordance with embodiments of the present invention;

0021<figref idref="DRAWINGS">FIG. 4</figref> comprises a flow diagram of a particular embodiment of a method of scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering (ORF); and

0022<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example computer system architecture for a computer system that performs a method of scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering (ORF) in accordance with embodiments of the invention.

DETAILED DESCRIPTION

0023By way of the present method of scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering the rulesets for ORF-lists are extended so as to perform VPN route filtering between RRs. This proposed VPN route filtering happens between an RR which is higher up in the RR hierarchy and another RR, which is a client of the higher RR. Each BGP RR explicitly configures some of its IBGP neighbors as RR-clients. This allows an RR to distinguish its IBGP neighbors from its IBGP neighbors who are clients. Furthermore, each RR knows about itself, whether it is an RR or not. Using a new BGP capability, each RR advertises to all its peers that it is an RR router. With the new information from the new BGP capability, each RR knows which of its peers are in turn RRs, and which of its peers are not RRs. From information obtained from its configuration, each RR knows which of its peers are its clients, and which of its peers are not its clients. Once this is established, an RR creates a common set of Route Target filters received from its all clients. The RR then sends the common set of filters to all its clients, who are also RRs.

0024The mechanism described above provides an RR the ability to recognize which of its clients are in turn RRs in a lower level hierarchy. This way, an RR higher in the hierarchy can distinguish its clients into two groups—those which are RRs and those which are not RRs. Announcing Route Target filters to its lower level RRs, assists the higher level RRs to limit their BGP VPN routing table to only the required set of routes thus pruning unwanted routes.

0025Referring now to <figref idref="DRAWINGS">FIG. 1</figref>, a conventional environment <b>10</b><i>a </i>is shown. The environment includes RRs <b>20</b>, <b>24</b> and <b>26</b>. RR <b>20</b> is in communication with RRs <b>24</b> and <b>26</b>, and RRs <b>24</b> and <b>26</b> are in communication with each other. RR <b>24</b> is also in communication with Provider Edge (PE) router <b>30</b> and PE router <b>32</b>, RR <b>26</b> is in communication with PE <b>34</b> and PE <b>36</b>.

0026A route reflector may have client and non-client peers. A client may be a provider router, and a non-client peer may be another route reflector. On receipt of ORF entries a route reflector may build an outbound route filter (also referred to as a filter list) toward the advertising peer. Outbound Route Filtering (ORF) provides a BGP-based mechanism that allows a router to send to its BGP peers a set of route filters that the peer may use to constrain/filter its outbound routing updates toward the advertising peer. PE-routers advertise ORF messages to route reflectors and the content of the ORFs may be used to filter the routes advertised by route reflectors to PE-routers.

0027An ORF list is a union of all ORF-entries that have been received from clients and ORF lists received from client or non-client peers. An ORF list is only sent to non-client peers of the route reflector unless specifically configured otherwise (such as in the case of an ASBR-router). In this environment <b>10</b><i>a</i>, PE <b>30</b> is interested in addresses having a prefix of 10:1 and 11:1. PE <b>32</b> is interested in addresses having a route-target of 11:1 and 12:1. Similarly, PE <b>34</b> is interested in routes having a route-target of 20:1 and 21:1 while PE <b>36</b> is interested in addresses having a route-target of 21:1, 22:1 and 10:1. It should be noted that only a few routing prefixes are shown for explanation purposes, and that any number of routers and prefixes could be used. These routes are advertised to all the routers. Thus, each PE router stores all the routes in its routing table (RT). RT <b>64</b> for PE <b>30</b> includes all the routes, as does RT <b>62</b> of PE <b>32</b>, RT <b>64</b> of PE <b>64</b> and RT <b>66</b> of PE <b>36</b>. All the routes are stored in each router, even if there is no interest in the routes. For example, PE <b>30</b> has no interest in RT entries 12:1, 20:1, 21:1 and 22:1 even though RT <b>64</b> includes them. This is a waste of space and processing power for each router.

0028Referring now to <figref idref="DRAWINGS">FIG. 2</figref>, a similar environment <b>10</b><i>b </i>is shown. In this environment automatic ORF-list creation for route partitioning across BGP route reflectors has been implemented. As a result, a PE can tell a RR what RT entries it is interested in, so that the RR will build a filter list such that only these routes are directed to the PE. For example, RR <b>24</b> sends only entries having the prefix 10:1 and 11:1 to PE <b>30</b>. Similarly, RR <b>24</b> sends only entries for 11:1 and 12:1 to PE <b>32</b>. Thus, the RR <b>24</b> filter list <b>54</b> only needs to contain the entries for 10:1, 11:1 and 12:1. This results in less processing and resources required for RR <b>24</b>. The same scenario exists for RR <b>26</b>. RR <b>26</b> sends only entries having the prefix 20:1 and 21:1 to PE <b>34</b>. Similarly, RR <b>26</b> sends only entries for 21:1, 22:1 and 10:1 to PE <b>36</b>. Thus, the filter list <b>56</b> of RR <b>26</b> only needs to contain the entries for 10:1, 20:1, 21:1 and 22:1. Note however, the filter list <b>50</b> of RR <b>20</b> has not changed, and still contains entries for all the routes.

0029Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, an environment <b>10</b><i>c </i>is shown in which scaling hierarchical route reflectors (RRs) using automated Outbound Route Filtering (ORF) is performed. The function of RR <b>20</b> is to convey routing information from RR <b>24</b> to RR <b>26</b> and from RR <b>26</b> to RR <b>24</b>. There is only one entry of common interest between RRs <b>24</b> and <b>26</b> (entry 10:1). The other routes are of no interest to either RR <b>24</b> or RR <b>26</b> so RR <b>20</b> does not need to send them. By way of the present invention, if one RR is a peer of another RR, and if the other RR is also a client of the first RR, then the first RR can advertise its filter list to the client RR. RR <b>24</b> and RR <b>26</b> are RR-clients of RR <b>20</b>. RR <b>20</b> builds an intersection of the two filter lists <b>54</b> and <b>56</b>. RR <b>20</b> advertises this filter list to RR <b>24</b> and RR <b>26</b>, in effect notifying then to only send routes having a prefix of 10:1. As a result, RR <b>24</b> will not send routes having a prefix of 11:1 and 12:1 to RR <b>20</b>, and RR <b>26</b> will not send routes of 20:1, 21:1, 22:1 to RR <b>20</b>. Accordingly, the load on RR<b>20</b> is reduced as it now only needs to store routes for 10:1.

0030A flow chart of one embodiment of the presently disclosed method is depicted in <figref idref="DRAWINGS">FIG. 4</figref>. The rectangular elements are herein denoted “processing blocks” and represent computer software instructions or groups of instructions. Alternatively, the processing blocks represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC). The flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required in accordance with the present invention. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the spirit of the invention. Thus, unless otherwise stated the steps described below are unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.

0031Referring now to <figref idref="DRAWINGS">FIG. 4</figref>, a method <b>100</b> of scaling hierarchical RRs using automated ORF is shown. The method <b>100</b> begins with processing block <b>102</b>, wherein a first RR identifies other RRs configured as RR clients within a route reflector hierarchy.

0032In processing block <b>104</b>, an advertisement is sent by the first RR broadcasting itself as a RR. As shown in processing block <b>106</b> the sending further comprises identifying RRs in a lower level of the hierarchy than the first RR, and wherein the sending is done to the RR clients in a lower level of the hierarchy.

0033In processing block <b>108</b>, the first RR builds a common set of route target filters received from the client RRs. In processing block <b>110</b>, the building of a common set of route target filters includes using an intersection of similar target entries received from each RR client. As shown in processing block <b>112</b>, RR routing tables may be limited to a required set of routes within the first RR. In processing block <b>114</b>, the first RR sends the common set of route target filters to the Client RRs.

0034<figref idref="DRAWINGS">FIG. 5</figref> illustrates example architectures of a computer system that is configured as a host computer system <b>240</b>. The computer system <b>240</b> may be any type of computerized system such as a personal computer, workstation, portable computing device, mainframe, server or the like. In this example, the system includes an interconnection mechanism <b>211</b> that couples a memory system <b>212</b>, a processor <b>213</b>, and a communications interface <b>214</b>. The communications interface <b>214</b> allows the computer system <b>240</b> to communicate with external devices or systems.

0035The memory system <b>212</b> may be any type of computer readable medium that is encoded with an application <b>255</b>-A that represents software code such as data and/or logic instructions (e.g., stored in the memory or on another computer readable medium such as a disk) that embody the processing functionality of embodiments of the invention as explained above. The processor <b>213</b> can access the memory system <b>212</b> via the interconnection mechanism <b>211</b> in order to launch, run, execute, interpret or otherwise perform the logic instructions of the applications <b>255</b>-A in order to produce a corresponding process <b>255</b>-B. In other words, the process <b>255</b>-B represents one or more portions of the agent application <b>255</b>-A performing within or upon the processor <b>213</b> in the computer system.

0036It is to be understood that embodiments of the invention include the applications (i.e., the un-executed or non-performing logic instructions and/or data) encoded within a computer readable medium such as a floppy disk, hard disk or in an optical medium, or in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system <b>212</b> (e.g., within random access memory or RAM). It is also to be understood that other embodiments of the invention can provide the applications operating within the processor <b>213</b> as the processes. While not shown in this example, those skilled in the art will understand that the computer system may include other processes and/or software and hardware components, such as an operating system, which have been left out of this illustration for ease of description of the invention.

0037Having described preferred embodiments of the invention it will now become apparent to those of ordinary skill in the art that other embodiments incorporating these concepts may be used. Additionally, the software included as part of the invention may be embodied in a computer program product that includes a computer useable medium. For example, such a computer usable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals. Accordingly, it is submitted that that the invention should not be limited to the described embodiments but rather should be limited only by the spirit and scope of the appended claims.