Network Working Group Girish Venkateswaran Internet Draft Infosys Technologies Ltd Expiration Date: August 2003 February 2003 File name: draft-venkateswaran-idr-bgp4-sync-00.txt Synchronization in Border Gateway Protocol draft-venkateswaran-idr-bgp4-sync-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract BGP (Border gateway Protocol) is a routing protocol, which shares the information of its routing table on incremental basis. BGP needs to interact with the IGP peers within the autonomous system when all the routers inside the autonomous system do not run BGP. This document provides a detailed implementation of synchronization in BGP. This document specifies some implementation specifics of synchronization and also throws some of the pros and cons involved in implementing synchronization. This also reveals the points to be taken care when transition happens from synchronization to No synchronization and vice versa. Some of the precautions that are to be taken before implementing synchronization in BGP are also highlighted here. draft-ietf-idr-bgp4-sync-00.txt [Page 1] Internet Draft draft-ietf-idr-bgp4-sync-00.txt February 2003 1. Introduction All transit AS's must be able to carry traffic which originates from and/or is destined to locations outside of that AS. Certain degree of interaction and coordination between BGP and the Interior Gateway Protocol (IGP) is required, when an AS is destined to serve as a transit AS. The interior routers receive information about external routes from one or more of the border gateways of the AS via the IGP.[Ref1] 1.1 Black-Holes Special care must be taken to ensure consistency between BGP and the IGP, since changes in state are likely to propagate at different rates across the AS. In figure (1), Router A and Router C in AS 600 are IBGP peers. Router B does not run BGP and is available in the same AS as that of A and C. Router E located in AS 200 is having a BGP session with Router C. Router A, which is present in AS 500, has a BGP session established with the router D. Consider Router E advertises that network 192.25.0.0 is reachable having the NextHop as 1.1.1.1. Router C forwards the information to the router A without changing the NextHop, as the NextHop of EBGP routes are unaltered, while sending to IBGP peers. Now Router A has in its routing table an entry that 192.25.0.0 is reachable via next hop 1.1.1.1. Assume that Router C has not redistributed the network 192.25.0.0 to IGP. So Router B has no idea that a network 192.25.0.0 even exists. Router A then sends an update message to router D, advertising the network 192.25.0.0 with the NextHop as 1.1.1.3. Now when traffic comes from Router D for the destination 192.25.0.0 to router A, it is just routed to router B as that is the only interface available. But since Router B does not have an entry about the network 192.25.0.0 in its routing table, it just drops the packet. This is termed as "Black Holes". Enabling Synchronization can solve the problem of black holes. If an autonomous system serves as a transit AS, passing traffic from one AS to another, then a BGP router in that AS should not advertise a route before all the IGP routers inside the AS have learned that route. draft-ietf-idr-bgp4-sync-00.txt [Page 2] Internet Draft draft-ietf-idr-bgp4-sync-00.txt February 2003 ------------------ | (AS 500) | | ---------- | | |Router D| | | | | | | -----+---- | | |1.1.1.4 | --------+--------- ------------------------------------ | | (AS 600) (1.1.1.3) | | | (160.42.0.0) ---------- | | | +----------|Router A|----+------------+ | | | | | | | -----+---- | | ----+----- | | | |Router B| |<-------+------- (logical link) | |(No BGP)| | | | ----+----- | | | | -----+---- | | | |Router C| | | +----------| |----+------------+ | ---------- | | | (1.1.1.2) | | ------------------------------------ | --------+--------- | |1.1.1.1 | | -----+---- | | |Router C| | | | | | | ---------- | | (AS 200) | | (192.25.0.0) | ------------------ A BGP router will advertise the route to the external peers (peers belonging to external AS) only after receiving an IGP route to the same destination. So if synchronization is enabled in the above scenario, then the router A waits for a non-BGP route from router B for the destination 192.25.0.0 before advertising the route to the external router D. draft-ietf-idr-bgp4-sync-00.txt [Page 3] Internet Draft draft-ietf-idr-bgp4-sync-00.txt February 2003 2. Synchronization Enabled Synchronization is enabled under two conditions, (i) All routers inside the Autonomous system do not run BGP (ii) When the AS serves as a Transit AS 2.1 Marking routes as Un-Synchronized The routes to a particular destination, learned from different BGP routers, are marked as Un-Synchronized using some flags unless convergence is confirmed. These routes will be processed when a non-BGP route to the same destination comes. The non-BGP route, which is used for synchronizing the BGP route, must be active. A small example of this may be that the interface for this non-BGP route might not be up. In some cases there may be one more non-BGP route available for the same destination with less preference compared to the earlier one. So a complete search is done for any other non-BGP route before making the route as unsynchronized. When a non-BGP route for the same destination comes, then the BGP route is synchronized and advertised to the external peers. Now the non-BGP route becomes the "Depended By" route and the BGP route becomes "Depended On" route. when this non-BGP route goes down then the dependencies are modified and the BGP route is withdrawn from the EBGP peers. 2.2 Preference value of Non-BGP route Generally BGP has much higher preference value compared to IGP routes and as a result IGP routes are given more priority. (The protocol with less preference is given more priority). Suppose an IGP learned route is available with a preference greater than BGP route's preference. Then in that case the IGP route will not be considered as an active route. But still this route can be used to synchronize the BGP route. 2.3 Routes with Invalid Next-Hop When synchronization is disabled and a BGP route is received with invalid Next-Hop, then that route is not considered as the best route. The route will not be advertised to the peers. But when synchronization is enabled, the Next-Hop is not checked whether it is valid or invalid. When a non-BGP route for the same destination comes, the route is synchronized and advertised to the peers. draft-ietf-idr-bgp4-sync-00.txt [Page 4] Internet Draft draft-ietf-idr-bgp4-sync-00.txt February 2003 3 Synchronization Disabled Synchronization should be disabled when all the routers inside the autonomous system do not run BGP. But in this case if synchronization is enabled, then the BGP speaker starts waiting for a non-BGP route for the same destination, which will never come. 3.1 Marking routes as Unsynchronized When routes with unreachable Next-Hop are received from an EBGP peer, the routes are rejected. But when the routes are received from an IBGP peer, the routes are not rejected; they are marked as unsynchronized and. When another route with its destination as the invalid Next-Hop comes, this BGP route is synchronized and advertised to its peers. The BGP route becomes "Depended On" route and the route that is used to synchronize the BGP route becomes "Depended By" route. When this "Depended By" route goes down the dependencies are changed to default and the BGP route is withdrawn from the peers. 3.2 Non-BGP route with less prefix The "Depended By" route need not have the exact prefix match with the BGP route's invalid Next-Hop. The BGP route is synchronized and advertised to the peers when a route with less prefix comes. ---------------------------- ------------------ | (1.1.1.2) | | (AS 100) | | ---------- | | ---------- | | |Router A|-------+-----------+--|Router C| | | | | | | | | | | ------+--- | | ---------- | | | | | (1.1.1.3) | | (AS 600) | | ------------------ | (160.42.0.0) | | | | | | -----+---- | | |Router B| | | | | | | ---------- | | (1.1.1.1) | ---------------------------- draft-ietf-idr-bgp4-sync-00.txt [Page 5] Internet Draft draft-ietf-idr-bgp4-sync-00.txt February 2003 This is explained using a scenario. Router A and Router B are IBGP peers. Router A has an EBGP session with Router C that is in AS 100. Router B advertises a route 192.25.20.0 to the router A with the Next-Hop as 5.0.0.1. This route is not advertised to the Router C, as the Next-Hop is unreachable. Now configure a static route with the destination as 5.0.0.1 and mask as 32 in router A. The BGP route gets synchronized and gets advertised to the router C. The route 192.25.20.0 is the "Depended On" route and 5.0.0.1 is the "Depended By" route. If this static route is deleted from router A, BGP route is withdrawn from router C. configure a new static route with the destination as 5.0.0.0 and mask as 8. Again the BGP route is advertised to the router C, this time using 5.0.0.0 to get synchronized. The route 5.0.0.0 becomes the "Depended By" route. If another static route with the destination as 5.0.0.1 and mask as 32 is configured, the dependency of the route 192.25.20.0 is changed. Now 5.0.0.1 becomes the "Depended By" route. In this case the dependency is alone changed and the route 192.25.20.0 is neither withdrawn nor advertised to the router C. 4 Transition from Synchronization to No-Synchronization When Synchronization is changed to No-synchronization the following conditions should be taken care: (i) During synchronization, though the routes are valid (with reachable Next-Hop), they will not be advertised to EBGP peers if there is no Non-BGP route for the same destination. These routes are advertised to the EBGP peers when the transition happens from Synchronization Enabled to Synchronization disabled. (ii) There may be routes with valid Next-Hop and also a Non-BGP route to the same destination exists. These routes would have been advertised to the EBGP peers, when synchronization was enabled. Such routes must not be re-advertised when synchronization is changed to No-synchronization. (iii)During Synchronization enabled case, the routes with invalid Next-Hop are advertised to the EBGP peers, provided a non-BGP route to the same destination exists. When synchronization is disabled, such routes are withdrawn from the external peers, as the Next-Hop is unreachable and marked as unsynchronized. draft-ietf-idr-bgp4-sync-00.txt [Page 6] Internet Draft draft-ietf-idr-bgp4-sync-00.txt February 2003 But if a route is available with its destination as the invalid Next-Hop, then in that case the BGP routes are not withdrawn from the EBGP peers. In this case the dependencies are alone modified. 5 Transition from No-Synchronization to Synchronization When transition occurs from No-Synchronization synchronization the following conditions are considered: (i) When synchronization is disabled the routes with valid Next- Hop are advertised to the EBGP peers. But when synchronization is changed to enable case, the availability of non-BGP routes to the same destination is checked. If such non-BGP routes are not available, then the BGP routes are withdrawn from the EBGP peers. (ii) If such non-BGP route exists, then the BGP routes are neither advertised nor withdrawn from the EBGP peers. But the dependencies are altered. (ii) The routes with the invalid Next-Hop (Next-Hop not reachable) are not advertised to the EBGP peers when Synchronization is disabled. When transition occurs from No-Synchronization to Synchronization, the existence of non-BGP route to the same destination is verified. If such non-BGP route exists, then the BGP routes are advertised to the external peers 6 Performance Issues The routes can be marked as unsynchronized, under both synchronization enabled and disabled cases, by having a flag in the route structure. But when a non-BGP route comes to synchronize the BGP routes, the entire Loc-Rib is searched to find the route that is having the same destination. This leads to serious performance degradation when the number of routes in the Loc-Rib increases. This also happens when the "Depended By" route gets withdrawn. To avoid this problem the routes that are marked as Un- Synchronized can be shifted to a separate list, by doing so, the search for a particular route becomes easier. Similarly another list could be maintained for routes that are synchronized. This solution also has a disadvantage. When the number of routes becomes more, the memory occupied to maintain separate lists should be taken into consideration. So a proper usage of both the above said methods would give a proper solution. draft-ietf-idr-bgp4-sync-00.txt [Page 7] Internet Draft draft-ietf-idr-bgp4-sync-00.txt February 2003 Generally, when the number of routes is more, it is always better to avoid processing all the routes at a stretch. The number of routes taken to process can be reduced, thus allowing time for other protocols also to run. But if this kind of scheduling is implemented, then immediate switches from one state to another will lead to confusion in the processing logic. 7 Acknowledgements This draft would have not been completed without the help of the following people (in first name alphabetical order) Aijaz Ahmed, Guruprasad Karanth, Ishwar Halali, Kelvin, Narayan B, Ramanan Raghavan, Rajagopalan, Senthil Kumar MV, Shubha Mahesh, VijayKumar Ramanujam. 8 References [1] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [2] Rekhter Y., and P. Gross, "Application of the border gateway protocol in the internet", RFC 1772, March 1995. 9 Authors' Addresses Girish V Infosys Technologies Ltd., 138, Old Mahabalipuram Rd, Chennai, Tamil Nadu, India 600119 EMail: girish_v@infosys.net 91-44-24509530 - x80729 draft-ietf-idr-bgp4-sync-00.txt [Page 8]