OSPF : "34 Things to remember"

Open Shortest Path First (OSPF) is a routing protocol for Internet Protocol (IP) networks. It uses a link state routing algorithm and falls into the group of interior routing protocols, operating within a single autonomous system (AS). It is defined as OSPF Version 2 in RFC 2328 (1998) for IPv4.[1] The updates for IPv6 are specified as OSPF Version 3 in RFC 5340 (2008).

OSPF is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks. IS-IS, another link-state dynamic routing protocol, is more common in large service provider networks. The most widely used exterior gateway protocol is the Border Gateway Protocol (BGP), the principal routing protocol between autonomous systems on the Internet.

OSPF is an internal entranceway protocol (IGP) for routing web Protocol (IP) packets alone among one routing domain, like associate autonomous system. It gathers link state info from on the market routers and constructs a topology map of the network. The topology is bestowed as a routing table to the net Layer that routes datagrams based mostly alone on the destination information science address found in information science packets. OSPF supports web Protocol Version four (IPv4) and web Protocol Version half-dozen (IPv6) networks and options variable-length subnet masking (VLSM) and egalitarian Inter-Domain Routing (CIDR) addressing models.

OSPF detects changes within the topology, like link failures, and converges on a brand new loop-free routing structure among seconds. It computes the shortest path tree for every route employing a methodology supported Dijkstra's formula, a shortest path initial formula.

The OSPF routing policies for constructing a route table square measure ruled by link value factors (external metrics) related to every routing interface. value factors is also the gap of a router (round-trip time), knowledge outturn of a link, or link convenience and dependableness, expressed as easy unit less numbers. This provides a dynamic method of traffic load equalization between routes of equal value.

An OSPF network is also structured, or divided, into routing areas to change administration and optimize traffic and resource utilization. Areas square measure known by 32-bit numbers, expressed either merely in decimal, or usually in octet-based dot-decimal notation, acquainted from IPv4 address notation.

The 34 Things which you should remember are as follows:-

1. The IP header of an OSPF packet specifies protocol number 89.

2. To establish OSPF neighbor adjacency, hello/dead timers, MTU (otherwise have to use "ip ospf mtu-ignore") must match. Unique router-id is also required.

3. Routers in stub area can only be adjacent with the routers in stubs or totally stubby area. Routers in NSSA can only be adjacent with the routers in NSSA or totally NSSA.

4. OSPF sees secondary networks as stub networks and cannot make adjacencies over secondary addresses. OSPF will advertise a secondary network or subnet only if it is also running on the primary network or subnet and OSPF routes of secondary addresses must be in same area as the primary address to be advertised. To learn routes from a neighbor connected to the secondary network, another routing protocol such as RIP should be running and redistributed into OSPF. Another solution to this kind of problem is to create dot1q sub interfaces.

5. The only time that OSPF will form adjacencies between neighbors that are not on the same subnet is when the neighbors are connected through point-to-point links using "ip unnumbered".

6. The primary interface and IP unnumbered interface will have OSPF enabled if a network statement matches the IP address of the primary interface.

7. An OSPF external route cannot use another OSPF external route as its next hop.

8. Inside an area, OSPF uses Link State logic, but between areas OSPF acts much like a Distance Vector (DV) protocol in some regard. For example, the advertisement of a Type 3 LSA from one area to another hides the topology in the original area from the second area, just listing a destination subnet, metric (cost), and the ABR through which the subnet can be reached—all DV concepts.

9. Only broadcast and non-broadcast network elect DR/BDR based on priority or router-id (in case of a tie in the priority).

10. In non-broadcast network, DR/BDR must have layer 2 connectivity to all other routers in the same area.

11. With OSPF network types broadcast and non-broadcast, next hop values are not modified when updates are transmitted across an NBMA media. Both point-to-multipoint and point-to-multipoint non-broadcast network type update the next-hop value of routes learned on partially meshed networks to the directly connected neighbor, and advertise the network as a set of endpoints instead of a transit network.

12. OSPF network point-to-point is the default option for point-to-point interfaces such as HDLC, PPP, or point-to-point NBMA subinterfaces.

13. As only broadcast and non-broadcast network type elects DR/BDR, they are compatible with each other, but they are not compatible with any other network types.

14. OSPF cost can be modified using (i) interface "bandwidth ..." command, (ii) interface "ip ospf cost ..." command, (iii) process "auto-cost reference-bandwidth ..." command, or (iv) "neighbor ... cost ..." command on point-to-multipoint non-broadcast network.

15. Only OSPF point-to-multipoint and point-to-multipoint non-broadcast network types support OSPF cost value on a per neighbor basis. On point-to-multipoint broadcast networks, if the "neighbor..." command is used, a cost to that neighbor must be specified.  But on point-to-multipoint non-broadcast networks, the "neighbor ..." command must be used to identify neighbors, assigning a cost to a neighbor is optional.

16. The internal OSPF routes can only be summarized on ABRs whereas the external (redistributed) routes can only be summarized on ASBRs.

17. "area default-cost ..." command is used to specify a cost for the default summary route (default cost 1) that is sent into a stub area or NSSA.

18. In NSSA, ABR with the highest router-id does the LSA 7 to 5 conversion.

19. In NSSA, “default-information originate” command cannot be used, since it generates Type-5 LSA, which is prohibited in NSSA area.

20. NSSA ASBR can generate a default only when it has a default route in its routing table whereas NSSA ABR can generate a default route with or without a default route in its own routing table.

21. Virtual links are not allowed in the stubby area or NSSA. In this case OSPF can be tunneled over a stub area using GRE tunnel (tunnel must be connected to area 0).

22. If the authentication is wrong on the virtual-link, the virtual-link interface will not go down immediately. As the virtual-link does not support periodic hellos, “clear ip ospf process” command should be issued if the authentication is enabled on the virtual link.

23. The virtual link will not come up if the only interface to reach the other end of the virtual link has a cost that is maximized (65535).

24. For BGP to redistribute routes into OSPF, the router-id must be identical, in OSPF and in BGP.

25. OSPF filtering using "distribute-list ...", "route-map ..." (match route-type, match ip route-source, match ip next-hop), and "distance ..." commands can only block route from entering into local RIB, but cannot stop LSAs propagation into the OSPF database.

26. OSPF filtering using "area ... filter-list prefix ...", "area ... range ... not-adv", “summary-address … not-adv”, “ip ospf database-filter all out”, or “neighbor … database-filter all out”  commands can filter LSAs from OSPF database.

27. If the “area … range …” and "area ... filter-list prefix ... out" both commands are configured for an area, then type 3 LSAs that correspond to the area range are sent to all other areas, only if at least one prefix in the area range matches an entry in the prefix list.

28. OSPF defaults to cost 20 when redistributing from an IGP, and 1 when redistributing from BGP.

29. “neighbor … database-filter all out” only works on point-to-multipoint network types.

30. If “distribute-list out” command is configured on an ASBR, then the ASBR generates Type 5 external LSAs only for those networks that are explicitly permitted in the distribute list.

31. OSPF demand circuit sets “do not age” flag on all LSAs learned and will only send updates when there is a change in the OSPF topology. The command must be configured in a point-to-point link and is needed only on one side. If the router is part of a point-to-multipoint topology, only the multipoint end must be configured with this command.

32. The main difference between flooding reduction ("ip ospf flood-reduction") and demand circuits ("ip ospf demand-circuit") is that former suppresses only periodic LSA refreshes; it does not suppress periodic hello packets. Thus, the flooding reduction feature does not impair the detection of a neighbor router going down.

33. OSPF stub router (“max-metric router-lsa”) advertises all non self-originated routes/LSAs with maximum metric.

34. When "redistribute maximum-prefix ..." command is configured, the redistribution limit does not apply to default routes or prefixes that are generated as a result of Type-7 to Type-5 translation.

Administrative Distance

 

OSPF Neighbor States

When OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent with its neighbor. Those states are defined in the OSPF RFC 2328 leavingcisco.com, section 10.1. The states are Down > Attempt > Init > 2-Way > Exstart > Exchange > Loading > Full.

 

Down

This is the first OSPF neighbor state. It means that no information (hellos) has been received from this neighbor, but hello packets can still be sent to the neighbor in this state.

During the fully adjacent neighbor state, if a router doesn't receive hello packet from a neighbor within the RouterDeadInterval time (RouterDeadInterval = 4*HelloInterval by default) or if the manually configured neighbor is being removed from the configuration, then the neighbor state changes from Full to Down.

 

Attempt

This state is only valid for manually configured neighbors in an NBMA environment. In Attempt state, the router sends unicast hello packets every poll interval to the neighbor, from which hellos have not been received within the dead interval.

 

Init

This state specifies that the router has received a hello packet from its neighbor, but the receiving router's ID was not included in the hello packet. When a router receives a hello packet from a neighbor, it should list the sender's router ID in its hello packet as an acknowledgment that it received a valid hello packet.

 

2-Way

This state designates that bi-directional communication has been established between two routers. Bi-directional means that each router has seen the other's hello packet. This state is attained when the router receiving the hello packet sees its own Router ID within the received hello packet's neighbor field. At this state, a router decides whether to become adjacent with this neighbor. On broadcast media and non-broadcast multiaccess networks, a router becomes full only with the designated router (DR) and the backup designated router (BDR); it stays in the 2-way state with all other neighbors. On Point-to-point and Point-to-multipoint networks, a router becomes full with all connected routers.

At the end of this stage, the DR and BDR for broadcast and non-broadcast multiacess networks are elected. For more information on the DR election process, refer to DR Election.

Note: Receiving a Database Descriptor (DBD) packet from a neighbor in the init state will also a cause a transition to 2-way state.

 

Exstart

Once the DR and BDR are elected, the actual process of exchanging link state information can start between the routers and their DR and BDR.

In this state, the routers and their DR and BDR establish a master-slave relationship and choose the initial sequence number for adjacency formation. The router with the higher router ID becomes the master and starts the exchange, and as such, is the only router that can increment the sequence number. Note that one would logically conclude that the DR/BDR with the highest router ID will become the master during this process of master-slave relation. Remember that the DR/BDR election might be purely by virtue of a higher priority configured on the router instead of highest router ID. Thus, it is possible that a DR plays the role of slave. And also note that master/slave election is on a per-neighbor basis.

 

Exchange

In the exchange state, OSPF routers exchange database descriptor (DBD) packets. Database descriptors contain link-state advertisement (LSA) headers only and describe the contents of the entire link-state database. Each DBD packet has a sequence number which can be incremented only by master which is explicitly acknowledged by slave. Routers also send link-state request packets and link-state update packets (which contain the entire LSA) in this state. The contents of the DBD received are compared to the information contained in the routers link-state database to check if new or more current link-state information is available with the neighbor.

 

Loading

In this state, the actual exchange of link state information occurs. Based on the information provided by the DBDs, routers send link-state request packets. The neighbor then provides the requested link-state information in link-state update packets. During the adjacency, if a router receives an outdated or missing LSA, it requests that LSA by sending a link-state request packet. All link-state update packets are acknowledged.

 

Full

In this state, routers are fully adjacent with each other. All the router and network LSAs are exchanged and the routers' databases are fully synchronized.

Full is the normal state for an OSPF router. If a router is stuck in another state, it is an indication that there are problems in forming adjacencies. The only exception to this is the 2-way state, which is normal in a broadcast network. Routers achieve the FULL state with their DR and BDR in NBMA/broadcast media and FULL state with every neighbor in the remaining media such as point-to-point and point-to-multipoint.

Note: The DR and BDR that achieve FULL state with every router on the segment will display FULL/DROTHER when you enter the show ip ospf neighbor command on either a DR or BDR. This simply means that the neighbor is not a DR or BDR, but since the router on which the command was entered is either a DR or BDR, this shows the neighbor as FULL/DROTHER.

OSPF Area and LSAs Propagation

The link-state advertisement (LSA) is a basic communication means of the OSPF routing protocol for the Internet Protocol (IP). It communicates the router's local routing topology to all other local routers in the same OSPF area. OSPF is designed for scalability, so some LSAs are not flooded out on all interfaces, but only on those that belong to the appropriate area. In this way detailed information can be kept localized, while summary information is flooded to the rest of the network. The original IPv4-only OSPFv2 and the newer IPv6-compatible OSPFv3 have broadly similar LSA types.

The LSA types defined in OSPF are as follows:

• Type 1 - Router LSA - the router announces its presence and lists the links to other routers or networks in the same area, together with the metrics to them. Type 1 LSAs are flooded across their own area only. The link-state ID of the type 1 LSA is the originating router ID.

• Type 2 - Network LSA - the designated router (DR) on a broadcast segment (e.g. Ethernet) lists which routers are joined together by the segment. Type 2 LSAs are flooded across their own area only. The link-state ID of the type 2 LSA is the IP interface address of the DR.

• Type 3 - Summary LSA - an Area Border Router (ABR) takes information it has learned on one of its attached areas and summarizes it before sending it out on other areas it is connected to. This summarization helps provide scalability by removing detailed topology information for other areas, because their routing information is summarized into just an address prefix and metric. The summarization process can also be configured to remove a lot of detailed address prefixes and replace them with a single summary prefix, helping scalability. The link-state ID is the destination network number for type 3 LSAs.

• Type 4 - ASBR-Summary LSA - this is needed because Type 5 External LSAs are flooded to all areas and the detailed next-hop information may not be available in those other areas because it may be using a different routing protocol. This is solved by an Area Border Router flooding the information for the router (i.e. the Autonomous System Boundary Router) where the type 5 originated. The link-state ID is the router ID of the described ASBR for type 4 LSAs.

• Type 5 - External LSA - these LSAs contain information imported into OSPF from other routing processes. They are flooded to all areas unchanged (except stub and NSSA areas). For "External Metric Type 1" LSAs routing decisions are made using the Type 1 metric cost sent, as the total cost to get to the external destination and includes the cost to the ASBR; while for "External Type 2" LSAs the metric sent is the cost from the ASBR to the External destination network and must be added to the OSPF cost to the ASBR advertising the Type 5. The link-state ID of the type 5 LSA is the external network number.

• Type 6 - Group Membership LSA (Only supported on a few routers) - this was defined for Multicast extensions to OSPF (MOSPF), a multicast OSPF routing protocol which was not in general use. MOSPF has been deprecated since OSPFv3 and is not currently used. It may be reassigned in the future.

• Type 7 - Routers in a Not-so-stubby-area (NSSA) do not receive external LSAs from Area Border Routers, but are allowed to send external routing information for redistribution. They use type 7 LSAs to tell the ABRs about these external routes, which the Area Border Router then translates to type 5 external LSAs and floods as normal to the rest of the OSPF network.

• Type 8 - A link-local only LSA for OSPFv3. A Type 8 LSA is used to give information about link-local addresses and a list of IPv6 addresses on the link. In OSPFv2, however, the Type 8 was originally intended to be used as a so-called External-Attributes-LSA for transit autonomous systems where OSPFv2 could replace the internal Border Gateway Protocol (iBGP). In these networks, the BGP destinations would be carried in LSA Type 5 while their BGP attributes would be inserted into LSA Type 8. Most OSPFv2 implementations never supported this feature.

• Type 9 - a link-local "opaque" LSA (defined by RFC2370) in OSPFv2 and the Intra-Area-Prefix LSA in OSPFv3. It is the OSPFv3 LSA that contains prefixes for stub and transit networks in the link-state ID.

• Type 10 - an area-local "opaque" LSA as defined by RFC2370. Opaque LSAs contain information which should be flooded by other routers even if the router is not able to understand the extended information itself. Typically type 10 LSAs are used for traffic engineering extensions to OSPF, flooding extra information about links beyond just their metric, such as link bandwidth and color.
• Type 11 - an AS "opaque" LSA defined by RFC 5250, which is flooded everywhere except stub areas. This is the opaque equivalent of the type 5 external LSA

BGP Path Selection Process

 1. Largest Weight

- Cisco proprietary. Only valid on the router it is configured on. It is not passed to other routers.

2. Highest Local Preference

- Highest Local Pref is preferred. Local Pref does not get passed between different ASs
- Due to the above reason, customers are sending/using BGP community string with their announcements
- Local Pref does get passed between confederations (sub-ASs).

3. Locally Originated

- Prefer the path that was locally originated via a network or aggregate BGP subcommand, or through redistribution from an IGP. Local paths sourced by network or redistribute commands are preferred over local aggregates sourced by the aggregate-address command.

4. Shortest AS Path

- An AS_SET counts as 1, no matter how many ASs are in the set
- The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.
- (**Confederation hops ARE NOT counted as hops)

5. Lowest Origin Type

- Prefer the path with the lowest origin type: IGP is lower than EGP, and EGP is lower than INCOMPLETE. (IGP < EGP < Incomplete)
- IGP origin is created when there is a network statement
-EGP origin is created via ‘redistribute
-Incomplete origin is created via redistribute

6. Lowest MED(multi-exit discriminator)

- Only compared when the AS path entering our network is the same. EX. 777 2 33 and 777 2 44 - metrics compared¦.777 2 44 and 777 3 44
- metrics NOT compared. NOTE  MED is different than IGP metric. MED is assigned by the end-user, the IGP metric is determined via the ISIS settings on our backbone.

7. eBGP over iBGP

- Routes are preferred over iBGP routes. eBGP routes are those learned via eBGP sessions (ie different ASs). iBGP routes are learned via iBGP sessions (same AS).

8. Lowest IGP metric

- IGP metrics are the internal routing protocols that BGP uses to reach the next-hop ip address(MCI backbone uses ISIS and MPLS).
- Prefer the path with the lowest IGP metric to the BGP next hop. Continue, even if bestpath is already selected.

9. Maximum paths

- Check if multiple paths need to be installed in the routing table for BGP Multipath. Continue, if bestpath is not selected yet

10. Oldest one(External)

- When both paths are external, prefer the path that was received first (the oldest one). This step minimizes route-flap, since a newer path will not displace an older one, even if it would be the preferred route based on the next decision criteria

11. Lowest Router ID

- Prefer the route coming from the BGP router with the lowest router ID
-If a path contains route-reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process
- The router ID is the highest IP address on the router, with preference given to loopback addresses. It can also be set manually using the bgp router-id command.

12. Minimum Cluster ID/list length

- This will only be present in BGP route-reflector environments

13. Lowest IP

- Prefer the path coming from the lowest neighbor address. This is the IP address used in the BGP neighbor configuration, and corresponds to the remote peer used in the TCP connection with the local router.

BGP

• BPG Attributes
• BGP Path Selection
• BGP ASN
  
• BGP ASN - AS-PLAIN to AS-DOT (and AS-COLON) calculator and back
  
• 
  

OSPF

 OSPF

• OSPF Cheat Sheet

• OSPF Neighbor States

• OSPF Area and LSAs Propagation

• OSPF Special Area Types (video)

• Configuring OSPF Special Area Types (video)

• OSPF Design Guide

• OSPF Area Types

• OSPF LSAs

BGP 16-bits and 32-bits ASN

 A complete table of 16-bits and 32-bits ASN

Number	Bits	Description	Reference
0	16	Reserved for RPKI unallocated space invalidation[11]	RFC6483, RFC7607
1 - 23455	16	Public ASNs
23456	16	Reserved for AS Pool Transition	RFC6793
23457 - 64495	16	Public ASNs
64496 - 64511	16	Reserved for use in documentation/sample code	RFC5398
64512 - 65534	16	Private ASNs	RFC1930, RFC6996
65535	16	Reserved	RFC7300
65536 - 65551	32	Reserved for use in documentation and sample code	RFC4893, RFC5398
65552 - 131071	32	Reserved
131072 - 4199999999	32	Public 32-bit ASNs
4200000000 - 4294967294	32	Private ASNs	RFC6996
4294967295	32	Reserved	RFC7300

Understanding BGP 4-byte ASN

BGP Autonomous System Number (ASN) is a 2-byte (16-bits) entity. 2-bytes give 65536 possible numbers, of which, 0, 23456, 65535 and 64512- 65534 (private ASN) are reserved by IANA. Of the remaining, 39000+ ASNs are already used.

RFC 4893 discusses about 4-byte ASN. 4-bytes provide ASNs ranging from 0 to 4294967296. 0-65535 are called mappable-ASN. The 4-byte ASN can be represented in one of three ways-

1. asplain - simple decimal representation of the ASN. For example, ASN 7747 will be represented as 7747, while 123456 will be represented as 123456.

2. asdot+ - breaks the number up in two 16-bit values as low-order and high-order, separated by a dot. All the 2-byte ASNs can be represented in the low-order value. For example, ASN 65535 will be 0.65535, 65536 will be 1.0, 65537 will be 1.1 and so on. The last ASN 4294967296 will be 65535.65535.

3. asdot - it is a mixture of asplain and asdot+. Any ASN in the 2-byte range is represented as asplain and any ASN above the 2-byte range is represented as asdot+. For example, 65535 will be 65535 while 65536 will be 1.0. Cisco uses this form of implementation.

ASN role in BGP

BGP carries ASN in-

    - OPEN messages

    - AS_PATH attribute

    - AGGREGATOR attribute

    - COMMUNITY attribute

Terminology

Old BGP Speaker- BGP Speaker running 2-byte ASN

New BGP Speaker- BGP Speaker running 4-byte ASN

BGP: 51 Points to Remember for BGP

  A path vector protocol could be a network routing protocol that maintains the trail data that gets updated dynamically. Updates that have coiled through the network and came to a similar node square measure simply detected and discarded. This algorithmic program is typically utilized in Bellman–Ford routing algorithms to avoid "Count to Infinity" issues.

It is completely different from the space vector routing and link state routing. every entry within the routing table contains the destination network, ensuing router and also the path to succeed in the destination.

Path Vector Messages in BGP: The autonomous system boundary routers (ASBR), that participate in path vector routing, advertise the reachability of networks. every router that receives a path vector message should verify that the publicized  path is in line with its policy. If the messages go with the policy, the ASBR modifies its routing table and also the message before causation it to ensuing neighbor. within the changed message it sends its own AS variety and replaces ensuing router entry with its own identification.

There are some things we need to remember for BGP

1. BGP uses TCP port 179 for transport. Router with the higher BGP router-id initiates BGP session from a random port.

2. The interface from which the BGP router ID is taken does not have to be running BGP. Any valid IP address can be used as BGP router-id, even an address that is not locally configured on the router.

3. The BGP router-id must be the same as the OSPF router-id for redistributing the routes from OSPF to BGP or vice versa.

4. If the 'network …' command is configured with the 'mask' option under the BGP process, then an exact match (network/mask) must exist in the IP routing table in order to advertise this route into BGP regardless of 'auto-summary' / 'no auto-summary' command. But the 'network …' command configured without the 'mask' assumes the default classful mask and if 'auto-summary' is configured then BGP will advertise a classful network only if any subnets of the classful network exist in the IP routing table. Again if the 'network …' command is configured without the 'mask' option and if 'no auto-summary' is configured, then that router must have the exact classful network in the IP routing table in order to advertise it in BGP.

5. To accept and attempt BGP connections to the external peers residing on networks that are not directly connected, we need to use either 'neighbor ebgp-multihop …' or 'neighbor ttl-security …' command. These two commands are mutually exclusive. We can use another command 'neighbor disable-connected-check' to accomplish the same task if the BGP neighbor is one-hop away.

6. The synchronization rule states that an iBGP learned prefix cannot be considered best unless there is a matching IGP route for that BGP prefix. BGP only advertises what it considers the best path. This issue can be resolved (1) by redistributing BGP routes into the IGP, (2) by creating a full-mesh of IBGP routers and disabling the synchronization, or (3) by creating a GRE tunnel. When BGP is synchronizing with OSPF, the router ID must match in both protocols in order to make it work.

7. When a prefix is received from an eBGP neighbor, it is advertised to both eBGP & iBGP neighbors. When a prefix is received from an iBGP neighbor, it is advertised ONLY to eBGP neighbors and not to any iBGP neighbors. To advertise iBGP leaned routes to other iBGP peers requires the use of route-reflectors or confederations or a full-mesh of iBGP peers.

8. While sending BGP updates, EBGP peers modify the next-hop value to its own IP address. But iBGP peers do not modify it.

9. The ‘default-information originate’ command, however, requires explicit redistribution of the route 0.0.0.0. . Default routes can be injected into BGP in one of three ways: (1) using the 'network …' command (default route must exist in the local routing table), (2) using the 'default-information originate' command (a redistribution statement must also be configured to redistribute the default route from the local routing table to the BGP table), and (3) using the 'neighbor … default-originate [route-map route-map-name]' command (this method does not even check for the existence of a default route in the IP routing table). The 'default-information originate' command should not be configured with the 'neighbor … default-originate' command on the same router.

10. 'weight' and 'local-preference' are set inbound and they affect outbound traffic. But 'as-path' and 'med' are set outbound and they affect inbound traffic.

11. The weights assigned with the 'set weight …’ route-map command overrides the weights assigned using the 'neighbor…  weight …' command.

12. Origin code 'i' is default on the BGP routes advertised by 'network ...', 'aggregate-address ...' (if all subnet has 'i'), and 'neighbor … default-originate' commands. And origin code '?' is default on the BGP routes advertised by 'redistribute ...', 'aggregate-address ...' (if any single subnet has '?', but can be changed using ‘attribute-map’ option), 'default-information originate', and 'bgp inject-map ...' commands.

13. When BGP originates a route with the ‘network …’ command, MED is copied from the metric of the original route.

14. BGP MED values are not passed beyond the receiving (neighbor) AS.

15. Enabling the ‘bgp deterministic-med’ command ensures the comparison of the MED variable when choosing routes advertised by different peers in the same autonomous system. Enabling the ‘bgp always-compare-med’ command ensures the comparison of the MED for paths from neighbors in different autonomous systems.

16. The default behavior of BGP routers that run Cisco IOS software is to treat routes without the MED attribute as having a MED of 0, making the route that lacks the MED variable the most preferred. The 'bgp bestpath med missing-as-worst' command can be configured to treat the route that missing MED as the least preferred one.

17. ‘bgp bestpath as-path ignore’ is a hidden command in Cisco IOS which allows BGP to not consider the AS path during best path route selection.

18. There are two ways to create an aggregate address under BGP. The first is to create a static route to null interface in the routing table for the aggregate address and then advertise it with the ‘network …’ command. The second way is to use the ‘aggregate-address …’ command.

19. By default when aggregation is configured in BGP, the 'atomic-aggregate' attribute is attached to the aggregate address if the 'as-set' argument is not used in the 'aggregate-address …' command. The 'as-set' argument reveals the AS numbers which can prevent a routing loop, and once 'as-set' is configured along with the 'aggregate-address …' command, the 'atomic-aggregate' attribute is automatically removed.

20. A router reflector and its clients are known collectively as a cluster. If the cluster contains a single route reflector, the cluster ID is the router ID of the route reflector. If the cluster contains multiple route reflectors, each RR must be manually configured with a cluster ID.

21. A client router in a route reflection cluster can peer with external neighbors, but the only internal neighbor it can peer with is a route reflector in its cluster or other clients in the cluster. Clients cannot peer with routers outside of their own cluster. However, the RR itself can peer with both internal and external neighbors outside of the cluster and can reflect their routes to its clients.

22. In case of route reflection, (1) routes from EBGP are advertised to EBGP, client, non-client (2) routes from client are advertised to EBGP, client, non-client (3) routes from non-client are advertised to EBGP, client.

23. When the 'no bgp client-to-client reflection' command is configured the RR does not reflect routes from one client to another. It does, however, continue to reflect routes from clients to peers outside of the cluster, and from peers outside of the cluster to clients.

24. Standard and extended BGP communities are removed from the reflected routes unless the 'neighbor ... send-community [both]' is configured on the route reflector. The link bandwidth community is removed from reflected route if the route-reflector performs IBGP multipath load-sharing for that route.

25. The “neighbor … nexthop-self” on router reflectors only affects the next hop of eBGP learned routes because the next hop of reflected routes should not be changed. To avoid a common configuration error for reflected routes, the “set ip next-hop” command should not be used in a route map to BGP route reflector clients.

26. Unlike route reflector environments in which only the route reflector itself has to support route reflection, all routers within a confederation must support the confederation functionality.

27. EBGP routes external to the confederation are preferred over EBGP routes to member autonomous systems, which are preferred over iBGP routes.

28. AS_PATH types are AS_SEQUENCE, AS_CONFED_SEQUENCE, AS_SET, and AS_CONFED_SET. AS_SEQUENCE is an ordered set of AS numbers, and AS_SET is an unordered set of AS numbers. AS_CONFED_SEQUENCE and AS_CONFED_SET are the same as AS_SEQUENCE and AS_SET but are used only within BGP confederations.

29. When 'bgp bestpath med confed' command is configured, the router picks the confederation-internal path with the lowest MED and ignores the path with the external AS number.

30. BGP private autonomous system numbers are from 64,512 to 65,535

31. BGP prefixes can be filtered using (1) 'distribute-list', (2) 'prefix-list', (3) 'filter-list', (4) 'policy-list', (5) community/extended community lists, (6) 'route-map' .

32. For BGP, the ‘distance …’ command sets the administrative distance of the External BGP (eBGP) route. This command only affects the routing table and not the BGP table.

33. The 'network … backdoor' command has the same effect as the 'network …' command. The EBGP route is treated as a local BGP route, and the administrative distance is changed to 200. The difference is that the address specified by the network backdoor command is not advertised to EBGP peers.

34. iBGP routes are not redistributed into an IGP unless you use "bgp redistribute-internal" command under BGP routing process.

35. 'bgp inject-map ... exist-map ...' command injects prefixes in the local BGP RIB when a valid parent route exists. Only prefixes that are equal to or more specific than the aggregate route (existing prefix) can be injected. exist-map (route-map) must contain a 'match ip address prefix-list ...' command statement to specify the aggregate prefix and a 'match ip route-source prefix-list ...' command statement to specify the route source. If the parent route is a default route, we can inject any route out of it.

36. A BGP neighbor cannot be configured to work with both peer groups and peer templates. BGP peer templates and BGP peer groups are mutually exclusive.

37. Peer session template can inherit only one session template directly, but peer policy template can inherit multiple policy templates.

38. When the maximum number (as set by the ‘neighbor … maximum-prefix ...’ command) of prefixes are reached, the string "PfxRcd" appears in the entry, the neighbor goes to shutdown  state, and the connection becomes idle.

39. No penalty is applied to a BGP peer reset when route dampening is enabled. Although the reset withdraws the route, no penalty is applied in this instance.

40. In case of iBGP multipath load sharing, when multiple iBGP paths installed in a routing table, a route reflector will advertise only one of the paths (one next hop).

41. For multiple paths to the same destination to be considered as multipaths, all attributes including weight, local preference, autonomous system path (entire attribute and not just length), origin code, MED, and IGP distance must be same. But if 'bgp bestpath as-path multipath-relax' command is configured, the AS paths still have to be the same length, but don't have to be identical.

42. Though BGP Multipath allows the installation of multiple BGP paths (for load sharing purpose) into the IP routing table for the same prefix, it does not affect the bestpath selection. A router still designates one of the paths as the best path and advertises this best path to its neighbors.

43. 'neighbor … dmzlink-bw' command can be used with eBGP and iBGP multipath features to enable unequal cost load balancing over multiple links. BGP can originate the link bandwidth community only for directly connected links to eBGP neighbors.

44. The 'bgp update-delay ...' command is used to tune the maximum time the software will wait after the first neighbor is established until it starts calculating best paths and sending out advertisements.

45. The routers configured with the “neighbor … local-as …” command prepend local-AS in inbound EBGP updates and prepend both actual AS number and local-AS number in outbound EBGP updates

46. The “neighbor … local-as …” command is valid only if the peer is a true eBGP peer. It does not work for two peers in different sub-ASs in a confederation.

47. In a route-map, a continue clause can be executed, without a successful match, if a route map entry does not contain a match clause. But if a match clause exists, the continue clause is executed only if a match occurs. If no successful matches occur, the continue clause is ignored. The continue statement proceeds to the specified route map entry only after configured set actions (if any) are performed.

48. When multiple values are configured in the same community list statement, a logical AND condition is created. All community values must match to satisfy an AND condition. When multiple values are configured in separate community list statements, a logical OR condition is created. The first list that matches a condition is processed.

49. While redistributing OSPF into BGP, by default only OSPF intra-area and inter-area routes are redistributed into BGP.

50. When a BGP router with synchronization enabled has also a OSPF route (redistributed from BGP) for a iBGP-learned route, then the OSPF ASBR router-id must match the originating BGP router-id in order to synchronize BGP route with OSPF route.

51. An “update group” is a group of peers with a common outbound policy which will be converged as if they are in a peer-group