Tejas Jain

OSPF Options Field DN = Down bit : used in MPLS Layer 3 VPNs. If a route learnt from a customer network via OSPF is advertised across a BGP / MPLS VPN using Multiprotocol BGP, and is advertised back to a customer network via OSPF, there is a possibility of a loop to occur in which the OSPF route is redistributed back to the VPN service provider network via BGP. The DN bit prevents this type of routing loop. O = The “O” bit is set when the originating router supports Type 9,10 and 11 opaque LSAs. Not used in normal OSPF implementations DC = The “DC” bit is set when the originating router supports OSPF over Demand Circuits. Not used in normal OSPF implementations L = Indicates whether the OSPF packet contains a LLS (Link-Local signalling) data block. This bit is set only in Hello and DBD packets. N = The N bit is used only in Hello packets. The N bit is set when the originating router supports Type-7 NSSA-External-LSAs. Neighboring routers with mismatched N bit value will not form ...

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...

The ultimate variables that decide whether a particular metric component should contribute towards EIGRP metric calculation or not are the EIGRP K-values. There are 5 in all, K1 to K5 with K1 (in conjunction with Bandwidth) and K3 (in conjunction with Delay) used primarily for EIGRP metric calculation. The K-values are not interface specific but router specific, meaning, the same set of K-values would be applicable to all the interfaces of a particular EIGRP router. Of course, changes can be done under "router eigrp ASN" command and not under interface. The command "show ip protocols" would display the current K-values. show ip protocols (EIGRP K-values) Let us now modify the K-values.. EIGRP metric weights The excerpt shows that the moment K values are modified, the EIGRP adjacency goes down due to the mismatch of K-values with the neighboring router. The changes are reflected again by using the command : show ip protocols