08-08-2016 03:58 PM - edited 03-05-2019 04:27 AM
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 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
Solved! Go to Solution.
08-19-2016 10:44 AM
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!!
08-19-2016 10:57 AM
I am glad the information has been useful for you and thanks for participating in this event.
Best Regards.
08-11-2016 11:47 AM
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:
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
08-11-2016 12:39 PM
Thanks lespejel, I am studying exactly those topics that you pointed out above
This is the detail that I did not know about:
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.
08-11-2016 03:06 PM
The information can indeed be found in the Summary section of Chapter 10 in the book:
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:
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.
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.
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.
08-12-2016 03:29 AM
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).
08-12-2016 05:54 AM
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.
08-12-2016 07:34 AM
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.
08-12-2016 08:24 PM
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:
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.
08-13-2016 04:53 AM
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?
08-13-2016 05:39 AM
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".
08-13-2016 05:39 AM
OK Hector, many thanks for the above!
08-13-2016 05:51 AM
Anytime 1001QA.Net.
I hope the information has been useful for you and thanks for participating.
Best Regards.
08-10-2016 10:38 PM
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
08-11-2016 08:59 AM
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:
# 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:
Lets get into more details:
1. Prefix length. The longest subnet mask is preferred.
For instance:
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide