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

When your neighbor's router is on fire, your internet is not at stake! Wish the same were true in the EIGRP universe as well (unless you have a well designed redundant network, which unfortunately is not very often the case!) EIGRP works if and only if your router establishes an 'amicable' EIGRP neighborship with the adjacent EIGRP router. Well, this is not an issue in most cases. Of importance, here, is how do you quantify the 'amicability' of the EIGRP adjacency. Let's inspect various fields in the "show ip eigrp neighbor" output show ip eigrp neighbor Autonomous System (AS) number - Here, visible as "Process 100" - EIGRP uses the concept of  autonomous systems . An autonomous system is simply a group of EIGRP-enabled routers that should become EIGRP neighbors and exchange routes. Address: IP address of the EIGRP neighbor Interface : Which interface is this EIGRP adjacency is formed upon Hold timer: Hold down timer is the number of secon

While configuring Cisco router you must have run into issues where the console tried to mess with your commands. (I have faced this more often than I am ready to accept!) Something like below: Cisco IOS - logging synchronous At a first glance, everything seems OK.. but wait.. where are my last three octets of the subnet mask?? The "link" and "line protocol" logs have kicked my three octets out.. What do I need to ensure that this doesn't happen? Disable console logging -- This, of course works! However, for someone who likes to feel the heat of his deeds, in the real time, it might not be very enjoying. Enable "logging synchronous" -- This needs to be done below the "line <console/vty> The latter is definitely desirable as it allows me to get the real-time logs along with, not messing up with my commands. Cisco IOS - logging synchronous configuration Of course, if you are telnet ing the device remotely, do this configuration under "line