INE Workbook Vol 1 BGP

There is a difference between the 'neighbor ebgp-multihop x' and the 'neighbor disable-connected-check'.The disable connected check prevents cases where the EBGP session between two routers is routed over another transit router. This is useful when creating a neighbor relationship based on the loopback interface of two routers, but they are still directly connected. The TTL is still one but it does not count the loopback interface as a hop. When compared to ebgp multihop, the disable-connected-check can reduce redundant routing information in the BGP table.

Here is the output from the BGP table when using ebgp-multihop. Since R5 has multiple hops to R4 (directly connected and across the frame-relay to R1).


R5(config-router)#do sh ip bgp
BGP table version is 11, local router ID is 150.1.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete


   Network          Next Hop            Metric LocPrf Weight Path
*  28.119.16.0/24   150.1.4.4                              0 100 54 i
*>                  155.1.0.1                              0 100 54 i
*  28.119.17.0/24   150.1.4.4                              0 100 54 i
*>                  155.1.0.1                              0 100 54 i
*  112.0.0.0        150.1.4.4                              0 100 54 50 60 i
*>                  155.1.0.1                              0 100 54 50 60 i
*  113.0.0.0        150.1.4.4                              0 100 54 50 60 i
*>                  155.1.0.1                              0 100 54 50 60 i
*  114.0.0.0        150.1.4.4                              0 100 54 i
*>                  155.1.0.1                              0 100 54 i
*  115.0.0.0        150.1.4.4                              0 100 54 i
*>                  155.1.0.1                              0 100 54 i
*  116.0.0.0        150.1.4.4                              0 100 54 i
*>                  155.1.0.1                              0 100 54 i
*  117.0.0.0        150.1.4.4                              0 100 54 i
*>                  155.1.0.1                              0 100 54 i
*  118.0.0.0        150.1.4.4                              0 100 54 i
   Network          Next Hop            Metric LocPrf Weight Path
*>                  155.1.0.1                              0 100 54 i
*  119.0.0.0        150.1.4.4                              0 100 54 i
*>                  155.1.0.1                              0 100 54 i
R5(config-router)#


Here is the output using disable-connected-check instead. You will notice that there is only one next-hop listed because the TTL is still 1, disregarding the local "hop" to the loopback interface. Now we can't route from R5 F/R - R1 Ethernet - R4 Ethernet because the TTL would be expired.



R5#sh ip bgp
BGP table version is 31, local router ID is 150.1.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete


   Network          Next Hop            Metric LocPrf Weight Path
*> 28.119.16.0/24   150.1.4.4                              0 100 54 i
*> 28.119.17.0/24   150.1.4.4                              0 100 54 i
*> 112.0.0.0        150.1.4.4                              0 100 54 50 60 i
*> 113.0.0.0        150.1.4.4                              0 100 54 50 60 i
*> 114.0.0.0        150.1.4.4                              0 100 54 i
*> 115.0.0.0        150.1.4.4                              0 100 54 i
*> 116.0.0.0        150.1.4.4                              0 100 54 i
*> 117.0.0.0        150.1.4.4                              0 100 54 i
*> 118.0.0.0        150.1.4.4                              0 100 54 i
*> 119.0.0.0        150.1.4.4                              0 100 54 i




I've learned exactly what the r in the 'sh ip bgp' output means. I knew it meant RIB failure, but not sure why. It simply means that the bgp route cannot be installed in the routing table, most likely due to the presence of a lower AD route in the route table. By default, 'r' routes will be advertised to other bgp neighbors. This can be disabled by enabling 'bgp suppress-inactive'.


IGP's do not by default redistribute iBGP learned routes. IGPs will only redistribute eBGP learned routes by default. To enable redistribute of iBGP learned routes, you need to add 'bgp redistribute-internal' to the BGP process. Now when routes go from BGP -> IGP, internal routes will be included. But now remember!! The AD for iBGP routes is 200, making it highly unlikely to be used when compared to IGPs. eBGP AD is 20, making it the most preferred when compared to conventional IGPs. So, to prevent loops, you need to change the distance of iBGP or your IGP.


When using auto-summary, you need to do one of two things. One, make sure there is a compatible 'network' statement that is a subset of the summary network. You can also configure redistribute. When you redistribute connected, the redistribute networks are automatically summarized.


Well, this has become a large post, so I will post BGP part II in the coming days. Enjoy!

INE Workbook Vol 1 OSPF

After completing the OSPF section, I realized again that I am pretty well versed in all things OSPF (excluding MPLS which comes later). As such, I've simply collected a few notes below.

• On a broadcast/non-broadcast OSPF interface, the next-hop is not changed. Pay attention to layer 3 to layer 2 F/R mappings.
• Use 'show ip ospf data router 150.1.5.5 self-originate' to show the costs for different neighbors. This can be useful when verifying 'neighbor x.x.x.x cost y' statements under the OSPF process.
• Additionally, 'show ip ospf data summ x.x.x.x' can be used to show the costs in routing to different neighbors for one route.
• Found an important explanation. Cisco utilizes OSPF transit capability by default. What this means is that if a lower cost route exists through a non-zero area, the route will be sent through a transit area and not directly to area 0. You can disable this with 'no capability transit'
• When configuring a virtual link, the VL takes on the cost metrics of the transit interface between the two routers.

Here is how to progress through the OSPF data show commands. 

• 'show ip ospf data (type of LSA) x.x.x.x'. A forward address of 0.0.0.0 means the router must now compute the metric towards the advertising router.
• 'show ip ospf data router x.x.x.x' where x.x.x.x is the advertising router.
• 'show ip ospf data router x.x.x.x' where x.x.x.x is the DR router.
• 'show ip ospf data router y.y.y.y self-originate' where y.y.y.y is the router-id. This will show the links to another routers with cost and interface/router-id addresses.This is a result of the SPF calculation.

When originating type-5 external routes, the forward address is 0.0.0.0, thus the need for the Type-4 LSA. This works differently in NSSA originated external routes where the inter-area forward address is the advertising router.

When multiple ABRs connect the NSSA to area 0, the router with the highest router-id will translate the type-7 to type-5 LSAs.

The 'area 3 nssa no-redistribution' is locally significant and only prevents the router this is configured on from originating type-7 LSAs into the area. This can be useful in conjunction with default-information-originate or no-summary if there is only one exit out of the area. This will still allow routers within the NSSA to redistribe external routes.

When using the distance command, the source is the originator of the route, and not where you learned the route from.

When using a route-map in conjunction with a distribute list, you can match both the route (match ip add ROUTE-ACL) and desination (match ip next-hop ROUTER-ACL).You can also match the outgoing interface of the route, the route source(router-id) and of course, route type, metrics and tag.

Well, that's all for now. BGP is up next, hopefully I will have some time to begin that tomorrow. As always, if anyone has any questions or comments, please let me know. I would love to hear them!

INE Workbook Vol 1 EIGRP part 2

Man, I hate using extended access-list to filter in a routing protocol. Because it's difficult? No. Because I don't understand it? No. Because it is difficult to remember the order of operations? YES. Further more, filtering with an extended ACL differs from BGP and redistributing when using extended ACLs. Even more annoying, is this behavior is not documented in the command reference or anywhere in the DocCD that I can easily find. So the trick here is going to be remembering it. In short, you match the host with the subnet.


Extended IP access list 100
    10 deny ip host 155.1.0.2 host 150.1.7.0
    20 deny ip host 155.1.0.3 host 150.1.7.0 (1 match)
    30 deny ip host 155.1.0.4 host 150.1.7.0
    40 deny ip host 155.1.0.2 host 150.1.9.0
    50 deny ip host 155.1.0.3 host 150.1.9.0 (1 match)
    60 deny ip host 155.1.0.4 host 150.1.9.0
    70 deny ip host 155.1.0.3 host 150.1.4.0 (2 matches)
    80 deny ip host 155.1.0.4 host 150.1.4.0 (1 match)
    90 deny ip host 155.1.0.1 host 150.1.4.0 (2 matches)


So the above, you can see we are denying 150.1.7.0 and 150.1.9.0 from R2, R3 and R4. Additionally, we are denying 150.1.4.0 from R1, R3 and R4. The activity is simple enough, it's just remembering in what order to place things in the extended access list. One caveat - remember to filter all possible sources for a route. So if the scenario instructs you to to send a particular route to only one router, filter that route from all possible sources to prevent any confusion.



R5(config-router)#do sh ip eig topo 150.1.7.0/24
IP-EIGRP (AS 100): Topology entry for 150.1.7.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 640256
  Routing Descriptor Blocks:
  155.1.0.3 (Serial0/0), from 155.1.0.3, Send flag is 0x0
      Composite metric is (640256/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25010 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
  155.1.0.1 (Serial0/0), from 155.1.0.1, Send flag is 0x0
      Composite metric is (640512/128512), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25020 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 3


Before filtering, I can see we are sending 150.1.7.0/24 to R3, but we also have a feasible successor to R1 which is our intended destination. But if you will notice above, I filtered this route from R3, R2 and R4 for good reason. At this moment, no other route meets the feasibility condition. Say another task instructs you to alter some EIGRP metrics and now you have a better route to 150.1.7.0/24 than your intended target. Well, now you have lost your points. This is goes back to being VERY SPECIFIC. Show everyone you know exactly what you are doing.


Interesting note that I did not know, EIGRP uses the router-id field in external routes as a loop prevention mechanism. I knew that router IDs must be unique but not any specifics. So if you want to prevent an external route from being installed, simply set it's router-id to the same as another router. Now neither router will originate external routes.


Well, that is all I have for EIGRP. Again, I didn't pick up much new information, but I always enjoy the opportunity to etch something permanently into my brain! Now I'm off to fix my servers so I can quit using my laptop for Dynamips...