cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12377
Views
74
Helpful
37
Replies

Ask the Expert: How to configure and troubleshoot EIGRP, OSPF and BGP.

Cisco Moderador
Community Manager
Community Manager

This topic is a chance to discuss more about about the most widely deployed Routing Protocols in today’s Enterprise Networks, such as EIGRP, OSPF and BGP. The use of dynamic Routing Protocols is necessary in order to keep the network operational, provide scalability and reduce complexity. Routing Protocols are easy to set up, however, inner workings and predicting the network reconverge might be a challenge specially in failover scenarios.

 

To participate in this event, please use the Join the Discussion : Cisco Ask the Expert button below to ask your questions

Ask questions from Monday, August 8 to August 19th, 2016

Featured Expert

Hector Gustavo Serrano is a Customer Support Engineer in the Global Cisco Technical Assistance Center. He is part of the Routing Protocols team, specialized in troubleshooting Routing issues, additionally he educates about best practices of Routing Protocols deployed on customer’s networks. For the last 6 six years he has worked with Cisco platforms for Enterprise Networks, specially focused on US customers. Hector Gustavo also holds a CCIE in Routing & Switching (49102) and a Bachelor’s degree in Telecommunication engineering.

Hector Gustavo might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the  Contact Center Community 

Find other  https://supportforums.cisco.com/expert-corner/knowledge-sharing.

**Ratings Encourage Participation! **
Please be sure to rate the Answers to Questions

37 Replies 37

Awesome. Thank you so much for the detailed explanation.

I will talk to the network engineers at the deployment site and will check with them if its possible for the Router to monitor the link between the router and the server and advertise the routes accordingly. If its not possible,  we may need to run a routing protocol at the server itself!!

I am glad the information has been useful for you and thanks for participating in this event.

Best Regards.

Hello

BGP supports now route refresh capability, soft reconfiguration is an option when IOS does not support that route refresh capability, with this you can update inbound route policies without interrupting the adjacency, as an example, after applying a route-map.


In the inbound direction, it will process routes to determine those going to Loc-RIB table, this won't purge Adj-RIB-in table because this table contains the unedited information received from peers, in this way it allows to process again the route policies. Because that, the feature consumes a significant amount of memory, since the Adj-RIB-in must remain in memory.


Now, you mention other tables, so let's recall what every one does:

  • Adj-RIB-in contains NLRIs as they are sent by BGP neighbors after routing policies are applied to save memory, but if you use soft reconfiguration it will contain all NLRIs before applying any routing policy, that's the difference.
  • Loc-RIB contains local NLRIs, and also contains NLRIs from neighbors after processing validity check, next-hop reachability and the best path selection algorithm.
  • Adj-RIB-out contains NLRIs after outbound routing policies are processed.

If you need to explore deeper into this, I think should be included in the CCIE R&S books since it's a topic:

3.7 BGP

 3.7.h Implement and troubleshoot other features                   

    • 3.7.h [i] Multipath
    • 3.7.h [ii] BGP synchronization
    • 3.7.h [iii] Soft reconfiguration, route refresh
CCIE 52804

Thanks lespejel, I am studying exactly those topics that you pointed out above

This is the detail that I did not know about:

  • Adj-RIB-in contains NLRIs as they are sent by BGP neighbors after routing policies are applied to save memory, but if you use soft reconfiguration it will contain all NLRIs before applying any routing policy, that's the difference.

So to conclude, the Adj-RIB-in table is used in a different way by "BGP Software reconfiguration" and "BGP Route refresh" features and there is no "other copy" of the Adj-RIB-in as I mistakenly believed Correct?

I could not find any reference to the text marked in blue above. All the docs that I could read seem to place this table before the policy engine on the input path. 
If a route has made it through the policy engine it will be stored in the loc-RIB.  

The information can indeed be found in the Summary section of Chapter 10 in the book:

"IP Routing on Cisco IOS, IOS XE, and IOS XR: An Essential Guide to Understanding and Implementing IP Routing Protocols"

Moving forward, as per RFC4271:

Adj-RIB-In
The Adj-RIBs-In contains unprocessed routing information that has
been advertised to the local BGP speaker by its peers.

As you mention, the behaviour differs depending on the BGP command:

  • neighbor Neighbor-IP soft-reconfiguration inbound

exists on the configuration or not.

Let's see both scenarios:

1) The command is missing.

There are 2 commands that can help us to see what networks our Router is receiving from the BGP peer.

  1. show ip bgp neighbor Neighbor-IP routes
  2. show ip bgp neighbor Neighbor-IP received-routes

The 1st command will tell you the routes that are received from the specified peer AND are passing the filter inspection that may be configured inbound for that peer in the BGP section (like a Route-Map, Prefix-list, etc.)

Being that said, the command will only show the unfiltered inbound routes.

The 2nd command will not work without the soft-reconfiguration inbound command in place, as the Adj-RIB-in data structure would be missing (It is gone after the processing of creating the NLRIs in the BGP Loc-RIB).

Router2#show ip bgp neighbors 10.1.2.1 received-routes 
% Inbound soft reconfiguration not enabled on 10.1.2.1
Router2#

Furthermore, the command 'clear ip bgp 10.1.2.1 soft in' will trigger a Route-REFRESH Message (compliant with RFC2918) that will make the peer to re-send a BGP UPDATE message destined to us and containing the networks (aka NLRIs) it should be advertising.

BGP_peers_01

2) Using the 'soft-reconfiguration inbound' command.

Once the command is in place, the Adj-RIB-in data structure persists.

It is important to remark that the command 'show ip bgp neighbor Neighbor-IP received-routes'  now shows an output.

For instance:

R2#show ip bgp neighbors 10.1.2.1 received-routes 
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.1.2.1 0 0 1 i
* 192.168.1.0 10.1.2.1 0 0 1 i

Total number of prefixes 2
R2#

As the RFC4271 mentions, this is "unprocessed" routing information. These are the NLRIs advertised by the peer, filtered or not on its way to the BGP Loc-RIB.

Keeping the Adj-RIB-in data structure means more RAM will be required of course.

Upon a new execution of the  'clear ip bgp 10.1.2.1 soft in' command (let's say to commit the configuration of a new filter in the BGP section) the Router will now look at the Adj-RIB-in for the routes, there is no need now to request the information to the BGP peer since we keep that unfiltered information on our Adj-RIB-in.

I hope this information has been useful for you.

Best Regards.

Hi Hector

Thanks for diving into details for us.

Can you please detail the reasons behind the temporary existence of the Adj-RIB-in in the first situation? Why is it used if later it it is not needed anymore? What would be the advantage of temporarily using it?

The 2nd command will not work without the soft-reconfiguration inbound command in place, as the Adj-RIB-in data structure would be missing (It is gone after the processing of creating the NLRIs in the BGP Loc-RIB).

Hello 1001QA.Net, I am glad the information has been useful for you.

From the point of view of the implementation/source code, I'd say it has more sense to keep using the same flow of code with the 'soft-reconfiguration' feature being enabled or not.

I hope this information has been useful for you.

Best Regards.

Hi Hector

Reusing the code is a thing that is not important to us as network engineers. What is important to understand is why the table is temporarily populated and then it is gone. 

After all they could have chosen not to use it at all. There must be a reason why they use it and then they destroy it. 

Hi 1001QA.Net

Adj-RIB-In is not "retained" when the 'soft-reconfiguration inbound' is not configured, the content is "deposited" or "moved" to the Loc-RIB.

In order to keep a copy of all the routes advertised by a specific peer (filtered or not) use the 'soft-reconfiguration inbound' command.

For BGP troubleshooting, you can use:

  1. show ip bgp neighbor Neighbor-IP routes
  2. show ip bgp neighbor Neighbor-IP received-routes (only available with 'soft-reconfiguration inbound' configured)
  3. show ip bgp
  4. show ip bgp neighbor Neighbor-IP advertised-routes

The use of those is as follows:

1) It shows the routes that, passing the inbound filters, are received from a specific BGP peer.

2) It shows a full copy of all the routes received from a specific BGP peer.

3) It shows all the routes received from all the BGP peers (after passing the inbound filters) and the ones the Router itself is inserting into BGP.

4) It shows all the routes the Router is advertising via BGP to a specific peer (after filtered outbound).

Best Regards.

Hi Hector

Yes the above were already clarified earlier, the part that I do not understand is why it is temporarily used and then trashed. Since it not used anymore that means that from a certain point forward the IOS can manage without it. Why? What changed?

With BGP, after initially received on the Adj-RIB-In ("unprocessed routing information"), the NLRIs are filtered and stored in the Loc-RIB, which is their final destination (in the BGP protocol). Those NLRIs can be shown with the command  'show ip bgp'.

Later on, if BGP is the only routing protocol running on the device, it is highly possible those will get into the RIB (Routing Table) as well.

There is no need for Adj-RIB-In to keep using memory as already explained. Entries on that data structure are simply "not retained".

OK Hector, many thanks for the above! 

Anytime 1001QA.Net.

I hope the information has been useful for you and thanks for participating.

Best Regards.

Hi Hector,

In a scenario when having multiple redistribution points what are your suggestions to avoid sub-optimal paths or routing loops?

In such scenarios the routing decisions are based on the best AD received and then only if there is a thigh the metric is compared, correct? 

Thanks!

Andrea

The use of Route tagging and filters are suggested to avoid sub-optimal paths and/or Routing loops in scenarios with Multiple 'mutual' Redistribution points.

Let's take a quick look at the below example:

  • R3 is receiving the 192.168.1.0/24 as EIGRP External (AD 170).
  • The route is forwarded to R1 and R2 via EIGRP.
  • R1 and R2 are mutual redistributing EIGRP & OSPF, so now the 192.168.1.0/24 exists in the OSPF domain.
  • One of the Routers will prefer the 192.168.1.0/24 via OSPF due to the fact that OSPF AD is 110 while EIGRP External is AD 170 (knowing which Router will have the OSPF entry might be unpredictable as it would be a 'race condition').

# Sub-optimal path example.

R1#show ip route
<Snippet>

D EX  192.168.1.0/24 [170/3072] via 10.1.23.3 (to R3), 00:01:33, GigabitEthernet0/0
R1#


R2#show ip route
<Snippet>

O E2 192.168.1.0/24 [110/20] via 10.1.2.1 (to R1), 00:01:34, GigabitEthernet0/1
R2#

Another possibility is that, for some reason, R1 or R2 calculates the path towards the 192.168.1.0/24 network via one of the Routers doing the redistribution and not via R3.

The outcome would be similar to:

# Routing loop example:

R1#show ip route
<Snippet>

D EX  192.168.1.0/24 [170/28416] via 10.1.23.2 (to R2), 00:01:33, GigabitEthernet0/0
R1#


R2#show ip route
<Snippet>

O E2 192.168.1.0/24 [110/20] via 10.1.2.1 (to R1), 00:01:34, GigabitEthernet0/0
R2#

R1#trace 192.168.1.0
Type escape sequence to abort.
Tracing the route to 192.168.1.0
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.23.2 40 msec 48 msec 44 msec
2 10.1.2.1 32 msec 52 msec 52 msec
3 10.1.23.2 88 msec 88 msec 92 msec
4 10.1.2.1 92 msec 44 msec 120 msec
5 10.1.23.2 176 msec 148 msec 180 msec
6 10.1.2.1 160 msec 200 msec 176 msec
7 10.1.23.2 208 msec 244 msec 240 msec
8 10.1.2.1 236 msec 240 msec 240 msec
9 10.1.23.2 308 msec 160 msec 52 msec
10 10.1.2.1 64 msec 56 msec 56 msec
11 10.1.23.2 68 msec 72 msec 68 msec
12 10.1.2.1 72 msec 72 msec 72 msec
13 10.1.23.2 80 msec 80 msec 84 msec
14 10.1.2.1 112 msec 156 msec 92 msec
15 10.1.23.2 92 msec 92 msec 96 msec
16 10.1.2.1 92 msec 104 msec 96 msec
17 10.1.23.2 104 msec 100 msec 156 msec
18 10.1.2.1 108 msec 124 msec 112 msec
19 10.1.23.2 140 msec 116 msec 120 msec
20 10.1.2.1 120 msec 120 msec 116 msec
21 10.1.23.2 132 msec 132 msec 128 msec
22 10.1.2.1 132 msec 128 msec 128 msec
23 10.1.23.2 140 msec 140 msec 156 msec
24 10.1.2.1 260 msec 152 msec 140 msec
25 10.1.23.2 256 msec 148 msec 152 msec
26 10.1.2.1 176 msec 152 msec 156 msec
27 10.1.23.2 188 msec 196 msec 168 msec
28 10.1.2.1 224 msec 164 msec 292 msec
29 10.1.23.2 348 msec 240 msec 308 msec
30 10.1.2.1 296 msec 212 msec 212 msec
R1#

The solution would be to use Route-Tagging or Filters (i.e. Distribute-lists).


A Router/L3 Switch chooses the Routing decision based on:

  1. Prefix length.
  2. Administrative Distance
  3. Metrics

Lets get into more details:

  1. Prefix length. The longest subnet mask is preferred.

For instance:

  • 192.168.10.0/24 entry will be preferred over
  • 192.168.0.0/16 entry. Due to the prefix length.

  2. Administrative Distance (AD). If the Router learns about a destination from more than one routing protocols, the AD is compared and the preference is given to the route with the lower AD.

For instance, with default AD values, EIGRP (internal) has precedence over OSPF which has precedence over EIGRP (External)

EIGRP (internal)       90
OSPF                      110
EIGRP (external)    170


  3. Metrics. Once both previously mentioned conditions are tied and there are multiple paths to the same destination from a single routing protocol, then the multiple paths would have the same administrative distance and the best path is selected based on the metrics.

The path with the lower metric is elected. If there are multiple pats with equal lowest metrics, those can be elected for ECMP (Equal Cost Multi-Path) which is Load Balancing.

Route Selection in Cisco Routers


I hope this information has been useful for you.

Best Regards.

Review Cisco Networking for a $25 gift card