We are going to talk about RFC 1998 which is a traffic engineering RFC and it's about using communities to set local pref on a remote autonomous system. RFC 1998 is an informational RFC which means it doesn't describe a particular standard; however, it has recommendations on how you can implement load sharing and backup on multiple inter-AS links. And the way it works is you use BGP communities to determine what the remote AS is going to set the local preference as on each of these links in this way you give control to the customers so the customer doesn't have to call the upstream provider with instructions on what to do for each prefix that is sent to the upstream provider and it also simplifies the upstream configuration because they can use the same template to many different different customers and the main guest of the RFC 1998 was certain community values were defined to have particular meanings for example s and in the s number and then the community 100 would mean to the upstream provider to set a local preference of a hundred and this would be the preferred path if you had an S number then community value of 90 then you'd set a local preference to 90 or if you had 80 then you set up a local preference to 80 and similarly if you had 70 then you set the local preference to 70 and this has certain implications so if it's a hundred then this is the preferred path if it's 90 then this is the backup if it's your home don't do that particular s if you see an 80 then it indicates that the main link is probably on another ISP with the same s path length and if it's a 70 then the main link is to another is V now the upstream ISP is the one who defines which communities are going to be used and the customers then attach those communities they want to the prefix announcements they are making and as a simple example if you have your upstream as a s100 and you want to declare a particular path as a bucket path what your customer would do is create a community 100 : 70 and send that to is 100 attached to a particular prefix s 100 receives the prefix with that community 170 tagged and then set the local preference on that particular prefix for that particular announcement to be 70 this next slide shows you the sample router configuration for the customer so the customer is in s 130 so you have Rooter BGP 130 and for this example let's look at IP v4 the neighbor would be the IP address of the upstream provider and we are using a route map and the name is s 100 - out in the outbound direction now we have an S path list that we are going to use later inside a route map and the filter list just says permit and then the empty s path which means permit anything that has been originated from this particular Network and then inside the route map in the route map s 100 we have a permit statement permit 10 and then we match this s path list that we've just created with a number reference there and then we say we are going to set the community to 100 : 70 on the ISP side which is this slide that you can see by looking at a route Abhijeet e 100 so this is a routine s 100 and they have the neighbor with a remote a s 130 which is a customer that we just configured and we have a route map customer - policy - in in the inbound direction note that this customer policy on the inbound direction does not have to be unique for each customer you could apply the same route map to many different customers so inside the community lists that you create with an IP community list seven you say permit 170 and then if something means home to another is with eco es path length you can say committee list 8 permit 180 and then you could have backup routes which is community list 9 per meter hundred 90 and this is a way you can easily tell which local preference you want to apply by just the number of the community list that you're going to be using so this slide shows you the configuration that we should apply to the route map to match these communities so the first statement matches the community 7 the community list 7 which we saw in the previous slide is to permit 100 : 70 and it's going to set the local preference on any advertisement that matches this to 70 and we haven't looked at examples of the customers sending different communities but if it matched community 8 who set a local preference 80 if in much community 9 would set the local preference 90 and lastly we set the local preference to 102 anything that doesn't match any of the ones above so your default local preference is 100 a local preference of 100 is is the default local preference but it helps to have it explicitly configured in the route map so that somebody who's debugging can tell what the intent is so RFC 1998 was an inspiration for a way of making these many different community policies work and they are no standard communities what is we are going to do but best practices today consider that is reduce bgp communities for the multihoming support of traffic engineering and what most of the larger ISPs are going to document this inside there as objects inside the internet routing registries that have their documentation about how they plan to use these communities so last we have a simple example we have two links to an isp one link is primary there on is backup which is what we just went through quickly and on the left of this diagram you can see s 100 with routers C D and E and on the right you have as 6 5 5 3 4 with route as a and B the link between routers a and C's meant to be the primary and the link between B and D is to be the backup and the plan is s 100 is going to aggregate for es 6 5 5 3 4 so how do you implement this you are not the slash 19 aggregate on each link the premiere link makes the standard announcement of the slash 19 the backup link sends a community that signals s 100 that the local preference should be lower so in one link fails the announcement of the slash 19 aggregate and continues on the other link and that ensures continued connectivity so for ruta a which is the customer ruta in s 6 5 5 3 4 you have this configuration so we're setting a prefix list to make sure that we are noun Singh just the aggregate and nothing else and we are accepting the default route from our upstream on router B we do the same thing we have the aggregate which is being announced out we are accepting the default route in but we additionally have a route map router D dash out set on the how to bound additionally to that we also have a route map on the inbound which we shall look at in the next slides so for the outbound routes our D dash out we have a permit 10 which matches the aggregate and sets the community to to a hundred : 90 hundred is is the s over upstream and 90 is what we want them to set a local preference and then we have a second statement which is permit 20 so if anything doesn't match the aggregate you want it to be permitted but you don't want to set a community on anything else so for the inbound route route map wrote a deep ammeter 10 you want to set your local preference to 90 because they're going to send you the same default route that they sent to the router router a now router sees configuration this is the ISPs router on the main link has customer in default out the default who permits just the default route so there's no le or GE it's just my mid 0.02 0 / 0 and then for router D which is the backup link in addition to having the default out you have the prefix list for the customer which is inbound but importantly you have the route map that applies the local preference which is on the knees next slide inside that route map you're going to match a community list 90 which says permit the particular community 100 : 90 and so the route map the first statement says if you match that community set the local preference to 90 the next statement does not have a March statement so it's going to match every other prefix that did not match above and it's going to set the local preference there to 100 which is the default but again it's good to be explicit so this summarizes how this could be done and you can make things a little bit more complicated which you shall see in the next videos.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.