Tejas Jain

BGP communities are optional transitive attributes They are used mainly to associate an administrative tag to a BGP route In spite of the communities being transitive, Cisco IOS routers do not pass them across the BGP sessions by default. The feature needs to be activated using the command “neighbor send-community” To display the community in the structured notation, you need to enter the global configuration command “ip bgp-community new-format” In order to set a community value, use the route-map command “ set community etc” or to add the community value on the existing community values use “set community additive ” The routes with communities assigned to them can be matched using “community-list” and which can then be referenced in a route-map later. There are two types of community lists : standard and extended. For eg. ip community-list 1 permit 101:1 101:2 ip community list 1 deny no-export Std community list NO-ADVERTISE community attribute: The well-known NO_ADVERTISE

Check if the next-hop is reachable. If yes, then proceed The path which has the highest WEIGHT The path which has the highest LOCAL_PREF The path which has been locally originated via a “network” or “aggregate” BGP command or through redistribution from an IGP The path which has the shortest AS_PATH The path which has the lowest origin type The path which has the lowest MED EBGP is preferred over IBGP Prefer the path which has lowest IGP metric to the BGP next hop Determine if multiple paths require installation in the routing table for “BGP multipath” In case both the paths are external, prefer the path which was received first (the oldest one) Prefer the route which comes from the BGP router with the lowest router ID If the originator or router ID is the same for multiple paths, prefer the path which has minimum cluster list length. (This is only present in BGP RR environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be awa

BGP attributes are broadly divided into two parts: Well Known attributes Optional attributes Well-known attributes : "MUST" be recognized by all BGP implementations Optional attributes : May or may not be supported by the BGP implementations Transitive attributes : BGP process has to accept the path in which it is included and should pass it on to other peers even if these attributes are not supported. Meaning if any optional attribute is not recognized by a BGP implementation, then BGP looks to check if the transitive flag is set. If the transitive flag is set then BGP implementation should accept the attribute and advertise it to its other BGP Peers. Non-transitive attributes : If the BGP process does not recognize the attribute then it can ignore the update and not advertise the path to its peers. If the transitive flag is not set then BGP implementation can quietly ignore the attribute, it does not have to accept and advertise this attribute to its other peers. Well kno