[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
B    10.228.243.0/16 [20/2] via 192.168.48.58
B    10.229.175.0/23 [20/12] via 192.168.14.241
B    10.115.215.0/26 [20/3] via 192.168.5.69
B    10.140.142.0/21 [20/4] via 192.168.81.127
B    10.80.228.0/23 [20/6] via 192.168.115.34
B    10.7.164.0/24 [20/807] via 192.168.38.102
B    10.13.4.0/25 [20/6] via 192.168.24.138
B    10.208.10.0/21 [20/11] via 192.168.44.135
B    10.207.45.0/20 [20/5] via 192.168.69.44
B    10.99.112.0/29 [20/0] via 192.168.80.151
B    10.247.204.0/23 [20/4] via 192.168.183.170
B    10.61.23.0/20 [20/2] via 192.168.52.126
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0

Question: Analyze this routing table for Administrative Distance conflicts.

[Assistant]
<reasoning>
1. Observation: BGP route to 10.7.164.0/24 has MED 807, while all other BGP routes have MED between 0 and 15. The MED deviation is 53x to 807x from the normal range.
2. Analysis: MED (Multi-Exit Discriminator) is used for inter-AS path selection when multiple paths exist from the same neighboring AS. A MED of 807 is atypical—normal MED values reflect IGP cost (usually <1000). This extreme value suggests: (a) IGP metric redistribution without scaling, (b) manual MED policy misconfiguration, (c) AS-path prepending combined with MED, or (d) a BGP community setting MED incorrectly.
3. Context: BGP best-path selection compares MED after weight, local-preference, and AS-path length. An extreme MED makes this path the least preferred among equal AS-path alternatives, effectively black-holing traffic if it's the only path. It also complicates traffic engineering.
4. Recommendation: Verify MED configuration on the advertising router. Check route-maps setting MED based on IGP metric—consider dividing by a factor (e.g., 'set metric igp-cost / 10'). Review BGP communities that manipulate MED. Ensure consistent MED policy across all BGP speakers in the AS.
</reasoning>
<answer>
WARNING: BGP MED skew for 10.7.164.0/24. MED 807 is 53x–807x higher than normal (0–15). Check IGP redistribution scaling, route-map MED policies, and community configurations. Path likely depreferred.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
O    10.40.2.0/24 [110/7] via 192.168.102.214, 06:23:10, FastEthernet1/3
O    10.50.141.0/20 [110/20] via 192.168.19.21, 18:06:24, GigabitEthernet0/3
O    10.40.0.0/24 [110/18] via 192.168.74.183, 01:06:22, GigabitEthernet3/0
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
O    10.40.59.0/24 [110/3654] via 192.168.137.74, 16:29:56, Serial3/0:1
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
O    10.40.6.0/24 [110/7] via 192.168.80.30, 13:01:35, FastEthernet3/1
O    10.130.9.0/16 [110/18] via 192.168.36.193, 09:30:15, GigabitEthernet2/1
O    10.181.249.0/18 [110/6] via 192.168.55.204, 11:29:24, Port-channel4
O    10.40.4.0/24 [110/19] via 192.168.225.240, 02:56:57, Port-channel8
O    10.40.1.0/24 [110/2] via 192.168.131.85, 13:42:27, FastEthernet1/0
O    10.233.245.0/24 [110/12] via 192.168.11.40, 12:05:10, FastEthernet0/0
O    10.40.5.0/24 [110/8] via 192.168.108.190, 22:43:39, GigabitEthernet0/2
O    10.24.167.0/28 [110/4] via 192.168.130.248, 11:34:52, Loopback59
O    10.40.3.0/24 [110/15] via 192.168.216.185, 22:13:19, Loopback46

Question: Identify all potential issues in this routing table and classify them by severity.

[Assistant]
<reasoning>
1. Observation: OSPF route to 10.40.59.0/24 has metric 3654, while all other OSPF routes in the same area have metrics between 2 and 20. The deviation is 182x to 1827x from the normal range.
2. Analysis: OSPF metric is calculated as the sum of interface costs (reference bandwidth / interface bandwidth). A metric of 3654 suggests either: (a) a very low-bandwidth path (e.g., serial link at 64 kbps), (b) manual cost misconfiguration, (c) reference bandwidth mismatch between routers, or (d) a routing loop causing accumulated cost.
3. Context: This skewed metric makes the path appear much longer than it is. Traffic to 10.40.59.0/24 will be routed suboptimally if an alternate path exists. In a hierarchical design, such metrics can break traffic engineering and cause hot-potato routing issues.
4. Recommendation: Verify interface bandwidth settings on all links toward 10.40.59.0/24. Check 'auto-cost reference-bandwidth' consistency across all OSPF routers. If the path includes a low-speed link, consider upgrading or using a tunnel. Verify no manual 'ip ospf cost' override is applied incorrectly.
</reasoning>
<answer>
WARNING: Severe OSPF metric skew for 10.40.59.0/24. Metric 3654 is 182x–1827x higher than area average (2–20). Check interface bandwidth, reference-bandwidth consistency, and manual cost overrides. Suboptimal routing likely.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
D    10.23.90.0/28 [90/392] via 192.168.67.34
D    10.195.175.0/22 [90/288] via 192.168.189.183
D    10.178.99.0/25 [90/723] via 192.168.245.97
D    10.254.255.0/26 [90/330] via 192.168.227.149
D    10.194.228.0/20 [90/950] via 192.168.185.179
D    10.174.120.0/17 [90/141] via 192.168.63.55
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
D    10.47.101.0/24 [90/5749] via 192.168.53.114
D    10.150.234.0/27 [90/448] via 192.168.87.42
D    10.181.221.0/27 [90/143] via 192.168.235.35
D    10.190.30.0/18 [90/481] via 192.168.98.207
D    10.91.238.0/25 [90/743] via 192.168.104.24
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
D    10.227.255.0/29 [90/166] via 192.168.11.18
D    10.45.57.0/25 [90/165] via 192.168.43.162
D    10.196.168.0/29 [90/185] via 192.168.13.13

Question: What routing issues could cause network instability in this configuration?

[Assistant]
<reasoning>
1. Observation: EIGRP route to 10.47.101.0/24 has metric 5749, which is 1154 higher than the expected baseline of 4595. Topology table shows repeated metric increases over the last 5 minutes.
2. Analysis: EIGRP metric increases indicate deteriorating path quality. Possible causes: (a) increasing interface delay due to queue buildup or congestion, (b) bandwidth reduction from auto-negotiation downgrading, (c) a new link with worse characteristics being added to the path, or (d) K-value changes causing recalculation.
3. Context: Unlike OSPF, EIGRP metrics are dynamic and reflect real-time path quality. A steadily increasing metric suggests the path is degrading. If the metric exceeds the feasible distance of the successor, EIGRP will query for a new path, potentially causing SIA if no feasible successor exists.
4. Recommendation: Monitor interface counters on all links toward 10.47.101.0/24 for errors, drops, or queue saturation. Check 'show interface' for bandwidth and delay changes. Verify K-values are consistent across all EIGRP neighbors. If the path includes a WAN link, check SLA metrics and provider circuit health. Consider implementing EIGRP stub to limit query scope.
</reasoning>
<answer>
WARNING: EIGRP metric flapping/increasing for 10.47.101.0/24. Metric rose from 4595 to 5749. Check interface delay/bandwidth, queue congestion, K-values consistency, and WAN link health. SIA risk if no feasible successor.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
O    10.105.135.0/25 [110/15] via 192.168.76.242, 09:28:16, Port-channel8
O    10.212.135.0/16 [110/13] via 192.168.73.198, 03:42:19, Loopback39
O    10.224.164.0/17 [110/8] via 192.168.87.189, 08:11:25, GigabitEthernet0/3
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
O    10.199.197.0/17 [110/19] via 192.168.225.109, 08:17:22, Loopback90
O    10.222.223.0/16 [110/14] via 192.168.65.251, 04:13:35, Loopback91
O    10.35.2.0/24 [110/1921] via 192.168.123.199, 19:38:31, Port-channel8
O    10.39.1.0/24 [110/3] via 192.168.130.11, 20:54:07, Serial1/0:1
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
O    10.101.63.0/22 [110/20] via 192.168.185.236, 18:03:06, Port-channel3
O    10.151.222.0/18 [110/16] via 192.168.244.178, 19:58:54, Port-channel7
O    10.29.137.0/16 [110/16] via 192.168.241.250, 04:03:30, Serial1/0:1

Question: Does this routing table have any routing inconsistencies?

[Assistant]
<reasoning>
1. Observation: Intra-area route 10.39.1.0/24 has metric 3, while inter-area route 10.35.2.0/24 has metric 1921. The inter-area metric is 1918 higher despite both destinations being roughly equidistant.
2. Analysis: OSPF inter-area routes are calculated as the sum of intra-area cost to the ABR plus the cost from ABR to destination. An abnormally high inter-area metric suggests: (a) suboptimal ABR placement, (b) a high-cost link in the backbone (Area 0), (c) virtual link with accumulated cost, or (d) summary LSA (Type 3) advertising a high metric from the ABR.
3. Context: Inter-area metric inconsistency causes suboptimal routing—traffic to 10.35.2.0/24 takes a much longer path than necessary. This can create asymmetric routing if return traffic takes a shorter intra-area path. It also complicates traffic engineering and SLA compliance.
4. Recommendation: Verify ABR placement and backbone topology. Check 'show ip ospf database summary' for the advertised metric of 10.35.2.0/24. Ensure virtual links (if used) are not adding excessive cost. Consider using 'area range' with 'cost' override on ABRs to normalize inter-area metrics. Verify all backbone links have consistent bandwidth settings.
</reasoning>
<answer>
WARNING: OSPF inter-area metric inconsistency. 10.35.2.0/24 metric 1921 is 1918 higher than intra-area 10.39.1.0/24 (3). Check ABR placement, backbone link costs, virtual links, and summary LSA metrics. Suboptimal routing likely.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
D    10.20.159.0/23 [90/132] via 192.168.87.133
D    10.226.88.0/17 [90/176] via 192.168.199.208
D    10.93.69.0/28 [90/379] via 192.168.217.188
D    10.225.253.0/22 [90/395] via 192.168.6.55
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
D    10.50.4.0/19 [90/607] via 192.168.168.24
D    10.28.242.0/24 [90/3379] via 192.168.160.56
D    10.251.77.0/20 [90/333] via 192.168.195.51
D    10.16.219.0/23 [90/167] via 192.168.88.142
D    10.148.103.0/27 [90/471] via 192.168.211.239
D    10.205.239.0/20 [90/343] via 192.168.168.53
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
D    10.132.86.0/23 [90/144] via 192.168.243.37

Question: What routing issues could cause network instability in this configuration?

[Assistant]
<reasoning>
1. Observation: EIGRP route to 10.28.242.0/24 has metric 3379, which is 1408 higher than the expected baseline of 1971. Topology table shows repeated metric increases over the last 5 minutes.
2. Analysis: EIGRP metric increases indicate deteriorating path quality. Possible causes: (a) increasing interface delay due to queue buildup or congestion, (b) bandwidth reduction from auto-negotiation downgrading, (c) a new link with worse characteristics being added to the path, or (d) K-value changes causing recalculation.
3. Context: Unlike OSPF, EIGRP metrics are dynamic and reflect real-time path quality. A steadily increasing metric suggests the path is degrading. If the metric exceeds the feasible distance of the successor, EIGRP will query for a new path, potentially causing SIA if no feasible successor exists.
4. Recommendation: Monitor interface counters on all links toward 10.28.242.0/24 for errors, drops, or queue saturation. Check 'show interface' for bandwidth and delay changes. Verify K-values are consistent across all EIGRP neighbors. If the path includes a WAN link, check SLA metrics and provider circuit health. Consider implementing EIGRP stub to limit query scope.
</reasoning>
<answer>
WARNING: EIGRP metric flapping/increasing for 10.28.242.0/24. Metric rose from 1971 to 3379. Check interface delay/bandwidth, queue congestion, K-values consistency, and WAN link health. SIA risk if no feasible successor.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
O    10.77.70.0/30 [110/3] via 192.168.132.156, 19:33:18, FastEthernet0/1
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
B    10.89.197.0/19 [20/28] via 192.168.119.174
B    10.88.152.0/21 [20/50] via 192.168.80.12
B    10.31.19.0/24 [20/789] via 192.168.172.123
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
B    10.255.238.0/23 [20/40] via 192.168.205.50
O    10.76.106.0/26 [110/4] via 192.168.170.81, 16:37:12, GigabitEthernet3/1
O    10.209.53.0/30 [110/10] via 192.168.239.151, 10:53:33, Serial0/1:1
B    10.129.235.0/30 [20/47] via 192.168.52.141
O    10.124.251.0/26 [110/14] via 192.168.32.54, 05:15:50, GigabitEthernet2/1
O    192.168.172.0/24 [110/35] via 192.168.66.15, 20:47:17, Loopback38
O    10.27.63.0/23 [110/12] via 192.168.75.52, 16:25:24, Serial0/1:0
O    10.231.107.0/26 [110/18] via 192.168.42.106, 22:45:38, FastEthernet1/3

Question: Identify all potential issues in this routing table and classify them by severity.

[Assistant]
<reasoning>
1. Observation: BGP route to 10.31.19.0/24 has MED 789, but the IGP (OSPF) metric to its next-hop 192.168.172.123 is only 35. The MED is 22x to 789x higher than the actual IGP cost.
2. Analysis: MED should ideally reflect the IGP metric from the advertising router to the BGP next-hop. A large discrepancy indicates: (a) MED is manually set without IGP correlation, (b) IGP metric changed after BGP advertisement, (c) redistribution from another protocol with different metric scale, or (d) route-map setting MED based on a static value rather than dynamic IGP.
3. Context: Inconsistent MED-to-IGP mapping breaks hot-potato routing. Traffic may enter the AS at a suboptimal point because MED doesn't reflect true internal cost. This causes inefficient inter-domain traffic patterns and violates BGP best practices (RFC 4451).
4. Recommendation: Configure 'set metric igp-cost' in BGP route-maps to ensure MED matches IGP metric. If using iBGP with next-hop-self, verify the IGP metric to the advertising router, not the original next-hop. Audit all route-maps for static MED values. Consider using 'bgp bestpath med missing-as-worst' for consistent behavior.
</reasoning>
<answer>
WARNING: BGP MED/IGP metric inconsistency for 10.31.19.0/24. MED 789 does not match IGP metric 35 to next-hop 192.168.172.123. Check route-map MED configuration and IGP correlation. MED should reflect true internal cost per RFC 4451.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
O    10.170.133.0/20 [110/20] via 192.168.21.189, 09:34:18, FastEthernet1/2
O    10.33.62.0/24 [110/1648] via 192.168.210.40, 11:52:53, Loopback0
O    10.19.88.0/17 [110/19] via 192.168.153.96, 17:13:54, Serial1/0:0
O    10.33.1.0/24 [110/15] via 192.168.193.62, 17:01:42, FastEthernet1/1
O    10.33.0.0/24 [110/15] via 192.168.154.8, 11:26:24, Port-channel3
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
O    10.182.68.0/22 [110/2] via 192.168.96.250, 13:22:51, Port-channel8
O    10.33.6.0/24 [110/16] via 192.168.235.164, 21:37:19, Port-channel8
O    10.1.191.0/17 [110/8] via 192.168.188.78, 19:39:15, Port-channel3
O    10.33.4.0/24 [110/18] via 192.168.135.88, 15:03:14, Serial0/0:0
O    10.157.22.0/22 [110/18] via 192.168.194.138, 04:46:24, FastEthernet0/0
O    10.87.15.0/18 [110/6] via 192.168.161.139, 16:42:56, FastEthernet0/0
O    10.33.5.0/24 [110/14] via 192.168.77.238, 06:23:22, Serial1/1:1
O    10.33.3.0/24 [110/10] via 192.168.245.107, 17:02:41, Serial1/0:0
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
O    10.33.2.0/24 [110/10] via 192.168.203.228, 00:17:34, FastEthernet1/0

Question: Identify all potential issues in this routing table and classify them by severity.

[Assistant]
<reasoning>
1. Observation: OSPF route to 10.33.62.0/24 has metric 1648, while all other OSPF routes in the same area have metrics between 2 and 20. The deviation is 82x to 824x from the normal range.
2. Analysis: OSPF metric is calculated as the sum of interface costs (reference bandwidth / interface bandwidth). A metric of 1648 suggests either: (a) a very low-bandwidth path (e.g., serial link at 64 kbps), (b) manual cost misconfiguration, (c) reference bandwidth mismatch between routers, or (d) a routing loop causing accumulated cost.
3. Context: This skewed metric makes the path appear much longer than it is. Traffic to 10.33.62.0/24 will be routed suboptimally if an alternate path exists. In a hierarchical design, such metrics can break traffic engineering and cause hot-potato routing issues.
4. Recommendation: Verify interface bandwidth settings on all links toward 10.33.62.0/24. Check 'auto-cost reference-bandwidth' consistency across all OSPF routers. If the path includes a low-speed link, consider upgrading or using a tunnel. Verify no manual 'ip ospf cost' override is applied incorrectly.
</reasoning>
<answer>
WARNING: Severe OSPF metric skew for 10.33.62.0/24. Metric 1648 is 82x–824x higher than area average (2–20). Check interface bandwidth, reference-bandwidth consistency, and manual cost overrides. Suboptimal routing likely.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
B    10.44.184.0/24 [20/1022] via 192.168.73.36
O    10.184.200.0/27 [110/4] via 192.168.135.82, 14:41:46, GigabitEthernet3/2
B    10.180.106.0/19 [20/46] via 192.168.122.68
B    10.72.29.0/30 [20/39] via 192.168.146.46
O    10.112.104.0/17 [110/11] via 192.168.112.21, 13:01:16, Serial2/0:0
B    10.185.223.0/24 [20/48] via 192.168.144.184
O    10.197.18.0/17 [110/8] via 192.168.94.64, 23:50:04, FastEthernet1/0
O    10.25.89.0/17 [110/9] via 192.168.48.211, 20:04:11, Port-channel2
O    10.226.220.0/27 [110/13] via 192.168.227.57, 04:15:42, FastEthernet3/3
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
B    10.106.215.0/23 [20/12] via 192.168.47.172
B    10.175.94.0/30 [20/27] via 192.168.101.233
B    10.54.240.0/16 [20/18] via 192.168.69.102
O    192.168.73.0/24 [110/39] via 192.168.183.114, 19:17:57, Loopback57
O    10.64.66.0/23 [110/6] via 192.168.139.12, 06:10:35, GigabitEthernet3/1

Question: Identify all potential issues in this routing table and classify them by severity.

[Assistant]
<reasoning>
1. Observation: BGP route to 10.44.184.0/24 has MED 1022, but the IGP (OSPF) metric to its next-hop 192.168.73.36 is only 39. The MED is 26x to 1022x higher than the actual IGP cost.
2. Analysis: MED should ideally reflect the IGP metric from the advertising router to the BGP next-hop. A large discrepancy indicates: (a) MED is manually set without IGP correlation, (b) IGP metric changed after BGP advertisement, (c) redistribution from another protocol with different metric scale, or (d) route-map setting MED based on a static value rather than dynamic IGP.
3. Context: Inconsistent MED-to-IGP mapping breaks hot-potato routing. Traffic may enter the AS at a suboptimal point because MED doesn't reflect true internal cost. This causes inefficient inter-domain traffic patterns and violates BGP best practices (RFC 4451).
4. Recommendation: Configure 'set metric igp-cost' in BGP route-maps to ensure MED matches IGP metric. If using iBGP with next-hop-self, verify the IGP metric to the advertising router, not the original next-hop. Audit all route-maps for static MED values. Consider using 'bgp bestpath med missing-as-worst' for consistent behavior.
</reasoning>
<answer>
WARNING: BGP MED/IGP metric inconsistency for 10.44.184.0/24. MED 1022 does not match IGP metric 39 to next-hop 192.168.73.36. Check route-map MED configuration and IGP correlation. MED should reflect true internal cost per RFC 4451.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
B    10.217.142.0/18 [20/34] via 192.168.104.180
B    10.203.245.0/24 [20/5] via 192.168.192.78
O    10.28.129.0/30 [110/19] via 192.168.204.113, 01:36:14, Loopback11
O    10.149.228.0/22 [110/5] via 192.168.38.5, 00:00:04, Loopback86
O    192.168.180.0/24 [110/7] via 192.168.8.110, 01:50:27, Serial2/0:1
O    10.225.180.0/24 [110/4] via 192.168.81.236, 02:01:59, Port-channel4
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
O    10.32.5.0/29 [110/6] via 192.168.2.131, 17:49:01, GigabitEthernet1/2
O    10.141.173.0/19 [110/5] via 192.168.142.161, 01:16:03, Port-channel4
O    10.127.119.0/19 [110/15] via 192.168.36.83, 11:00:02, FastEthernet1/1
B    10.207.140.0/17 [20/31] via 192.168.125.116
B    10.17.57.0/24 [20/975] via 192.168.180.159

Question: Identify all potential issues in this routing table and classify them by severity.

[Assistant]
<reasoning>
1. Observation: BGP route to 10.17.57.0/24 has MED 975, but the IGP (OSPF) metric to its next-hop 192.168.180.159 is only 7. The MED is 139x to 975x higher than the actual IGP cost.
2. Analysis: MED should ideally reflect the IGP metric from the advertising router to the BGP next-hop. A large discrepancy indicates: (a) MED is manually set without IGP correlation, (b) IGP metric changed after BGP advertisement, (c) redistribution from another protocol with different metric scale, or (d) route-map setting MED based on a static value rather than dynamic IGP.
3. Context: Inconsistent MED-to-IGP mapping breaks hot-potato routing. Traffic may enter the AS at a suboptimal point because MED doesn't reflect true internal cost. This causes inefficient inter-domain traffic patterns and violates BGP best practices (RFC 4451).
4. Recommendation: Configure 'set metric igp-cost' in BGP route-maps to ensure MED matches IGP metric. If using iBGP with next-hop-self, verify the IGP metric to the advertising router, not the original next-hop. Audit all route-maps for static MED values. Consider using 'bgp bestpath med missing-as-worst' for consistent behavior.
</reasoning>
<answer>
WARNING: BGP MED/IGP metric inconsistency for 10.17.57.0/24. MED 975 does not match IGP metric 7 to next-hop 192.168.180.159. Check route-map MED configuration and IGP correlation. MED should reflect true internal cost per RFC 4451.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
D    10.59.52.0/21 [90/518] via 192.168.186.184
D    10.189.108.0/28 [90/473] via 192.168.175.12
D    10.151.72.0/28 [90/434] via 192.168.178.218
D    10.194.232.0/29 [90/393] via 192.168.224.98
D    10.106.176.0/27 [90/306] via 192.168.32.220
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
D    10.130.110.0/16 [90/127] via 192.168.126.50
D    10.43.53.0/24 [90/4545] via 192.168.162.175
D    10.162.70.0/23 [90/365] via 192.168.165.193
D    10.56.153.0/27 [90/444] via 192.168.180.2
D    10.46.129.0/23 [90/470] via 192.168.119.251
D    10.21.183.0/18 [90/238] via 192.168.76.93
D    10.133.131.0/25 [90/976] via 192.168.169.78
D    10.238.22.0/20 [90/517] via 192.168.17.40

Question: What routing issues could cause network instability in this configuration?

[Assistant]
<reasoning>
1. Observation: EIGRP route to 10.43.53.0/24 has metric 4545, which is 551 higher than the expected baseline of 3994. Topology table shows repeated metric increases over the last 5 minutes.
2. Analysis: EIGRP metric increases indicate deteriorating path quality. Possible causes: (a) increasing interface delay due to queue buildup or congestion, (b) bandwidth reduction from auto-negotiation downgrading, (c) a new link with worse characteristics being added to the path, or (d) K-value changes causing recalculation.
3. Context: Unlike OSPF, EIGRP metrics are dynamic and reflect real-time path quality. A steadily increasing metric suggests the path is degrading. If the metric exceeds the feasible distance of the successor, EIGRP will query for a new path, potentially causing SIA if no feasible successor exists.
4. Recommendation: Monitor interface counters on all links toward 10.43.53.0/24 for errors, drops, or queue saturation. Check 'show interface' for bandwidth and delay changes. Verify K-values are consistent across all EIGRP neighbors. If the path includes a WAN link, check SLA metrics and provider circuit health. Consider implementing EIGRP stub to limit query scope.
</reasoning>
<answer>
WARNING: EIGRP metric flapping/increasing for 10.43.53.0/24. Metric rose from 3994 to 4545. Check interface delay/bandwidth, queue congestion, K-values consistency, and WAN link health. SIA risk if no feasible successor.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
B    10.125.153.0/24 [20/10] via 192.168.164.17
B    10.111.208.0/17 [20/8] via 192.168.188.12
B    10.183.35.0/26 [20/8] via 192.168.119.206
B    10.139.217.0/29 [20/10] via 192.168.118.185
B    10.43.4.0/24 [20/273] via 192.168.180.169
B    10.196.158.0/26 [20/5] via 192.168.25.253
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
B    10.43.4.0/24 [20/4] via 192.168.200.42
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
B    10.168.163.0/20 [20/4] via 192.168.212.147
B    10.15.94.0/29 [20/15] via 192.168.59.18
B    10.187.74.0/20 [20/7] via 192.168.183.127
B    10.26.17.0/17 [20/8] via 192.168.81.87
B    10.181.189.0/22 [20/9] via 192.168.173.144
B    10.216.186.0/20 [20/7] via 192.168.27.200
B    10.212.55.0/23 [20/4] via 192.168.69.31
B    10.95.51.0/28 [20/2] via 192.168.58.209

Question: Identify all potential issues in this routing table and classify them by severity.

[Assistant]
<reasoning>
1. Observation: Two BGP routes to 10.43.4.0/24 exist with oscillating MED values: 4 via 192.168.200.42 and 273 via 192.168.180.169. The MED difference of 269 causes repeated best-path changes.
2. Analysis: MED flapping between BGP peers indicates inconsistent IGP metric redistribution. Possible causes: (a) IGP metric changes on the path to the next-hop, (b) route-map applying MED based on a dynamic metric (e.g., delay, load), (c) dual-homed peers with different IGP costs, or (d) BGP policy oscillation between two route-maps.
3. Context: BGP best-path selection runs for each prefix when MED changes. With many prefixes, this causes CPU spikes and route churn. The router may also send repeated updates to downstream peers, amplifying the instability. MED oscillation is a known cause of BGP route dampening activation.
4. Recommendation: Stabilize the IGP metric to the BGP next-hop addresses. Use 'set metric' with a fixed value in route-maps instead of dynamic IGP-derived MED. Consider using 'bgp deterministic-med' to ensure consistent comparison. Implement BGP route dampening to suppress flapping prefixes. If using IGP-derived MED, ensure IGP is stable (e.g., OSPF cost not flapping).
</reasoning>
<answer>
WARNING: BGP MED flapping for 10.43.4.0/24. MED oscillates between 4 and 273. Check IGP metric stability, route-map MED policies, and 'bgp deterministic-med'. Implement BGP dampening. CPU impact from repeated best-path selection.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
B    10.1.217.0/17 [20/7] via 192.168.65.37
B    10.122.134.0/20 [20/4] via 192.168.255.69
B    10.226.108.0/16 [20/11] via 192.168.126.115
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
B    10.106.0.0/28 [20/9] via 192.168.174.217
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
B    10.73.211.0/24 [20/15] via 192.168.3.81
B    10.242.207.0/17 [20/7] via 192.168.74.88
B    10.179.40.0/25 [20/5] via 192.168.163.231
B    10.189.166.0/19 [20/8] via 192.168.168.80
B    10.17.87.0/19 [20/4] via 192.168.120.129
B    10.97.84.0/25 [20/0] via 192.168.44.119
B    10.208.26.0/21 [20/6] via 192.168.58.251
B    10.49.99.0/24 [20/1956] via 192.168.208.24

Question: Analyze this routing table for Administrative Distance conflicts.

[Assistant]
<reasoning>
1. Observation: BGP route to 10.49.99.0/24 has MED 1956, while all other BGP routes have MED between 0 and 15. The MED deviation is 130x to 1956x from the normal range.
2. Analysis: MED (Multi-Exit Discriminator) is used for inter-AS path selection when multiple paths exist from the same neighboring AS. A MED of 1956 is atypical—normal MED values reflect IGP cost (usually <1000). This extreme value suggests: (a) IGP metric redistribution without scaling, (b) manual MED policy misconfiguration, (c) AS-path prepending combined with MED, or (d) a BGP community setting MED incorrectly.
3. Context: BGP best-path selection compares MED after weight, local-preference, and AS-path length. An extreme MED makes this path the least preferred among equal AS-path alternatives, effectively black-holing traffic if it's the only path. It also complicates traffic engineering.
4. Recommendation: Verify MED configuration on the advertising router. Check route-maps setting MED based on IGP metric—consider dividing by a factor (e.g., 'set metric igp-cost / 10'). Review BGP communities that manipulate MED. Ensure consistent MED policy across all BGP speakers in the AS.
</reasoning>
<answer>
WARNING: BGP MED skew for 10.49.99.0/24. MED 1956 is 130x–1956x higher than normal (0–15). Check IGP redistribution scaling, route-map MED policies, and community configurations. Path likely depreferred.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
O    10.19.74.0/27 [110/3] via 192.168.24.167, 05:58:25, Loopback0
O    10.115.55.0/18 [110/6] via 192.168.106.199, 13:32:21, Port-channel5
O    10.167.78.0/28 [110/9] via 192.168.83.182, 16:18:33, GigabitEthernet3/3
O    10.27.2.0/24 [110/1865] via 192.168.21.42, 05:05:44, FastEthernet0/3
O    10.2.1.0/24 [110/7] via 192.168.169.8, 23:08:25, Port-channel8
O    10.0.84.0/19 [110/16] via 192.168.68.2, 18:02:57, GigabitEthernet3/2
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
O    10.80.154.0/19 [110/13] via 192.168.91.204, 11:54:51, FastEthernet3/1
O    10.248.233.0/25 [110/4] via 192.168.68.186, 12:37:06, Loopback68
O    10.71.2.0/22 [110/7] via 192.168.46.233, 19:55:46, Port-channel7
O    10.106.184.0/25 [110/3] via 192.168.243.93, 11:29:11, GigabitEthernet3/0
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0

Question: Does this routing table have any routing inconsistencies?

[Assistant]
<reasoning>
1. Observation: Intra-area route 10.2.1.0/24 has metric 7, while inter-area route 10.27.2.0/24 has metric 1865. The inter-area metric is 1858 higher despite both destinations being roughly equidistant.
2. Analysis: OSPF inter-area routes are calculated as the sum of intra-area cost to the ABR plus the cost from ABR to destination. An abnormally high inter-area metric suggests: (a) suboptimal ABR placement, (b) a high-cost link in the backbone (Area 0), (c) virtual link with accumulated cost, or (d) summary LSA (Type 3) advertising a high metric from the ABR.
3. Context: Inter-area metric inconsistency causes suboptimal routing—traffic to 10.27.2.0/24 takes a much longer path than necessary. This can create asymmetric routing if return traffic takes a shorter intra-area path. It also complicates traffic engineering and SLA compliance.
4. Recommendation: Verify ABR placement and backbone topology. Check 'show ip ospf database summary' for the advertised metric of 10.27.2.0/24. Ensure virtual links (if used) are not adding excessive cost. Consider using 'area range' with 'cost' override on ABRs to normalize inter-area metrics. Verify all backbone links have consistent bandwidth settings.
</reasoning>
<answer>
WARNING: OSPF inter-area metric inconsistency. 10.27.2.0/24 metric 1865 is 1858 higher than intra-area 10.2.1.0/24 (7). Check ABR placement, backbone link costs, virtual links, and summary LSA metrics. Suboptimal routing likely.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
D    10.128.53.0/21 [90/139] via 192.168.200.156
D    10.122.232.0/25 [90/169] via 192.168.57.30
D    10.155.232.0/26 [90/311] via 192.168.41.88
D    10.109.183.0/18 [90/119] via 192.168.63.125
D    10.144.244.0/20 [90/600] via 192.168.155.82
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
D    10.89.64.0/29 [90/346] via 192.168.137.178
D    10.95.120.0/26 [90/688] via 192.168.78.120
D    10.223.181.0/22 [90/426] via 192.168.131.79
D    10.45.58.0/18 [90/491] via 192.168.29.141
D    10.16.63.0/24 [90/2532] via 192.168.18.79
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
D    10.125.217.0/17 [90/412] via 192.168.200.180
D    10.162.110.0/23 [90/332] via 192.168.173.112
D    10.143.15.0/23 [90/121] via 192.168.55.131

Question: What routing issues could cause network instability in this configuration?

[Assistant]
<reasoning>
1. Observation: EIGRP route to 10.16.63.0/24 has metric 2532, which is 1080 higher than the expected baseline of 1452. Topology table shows repeated metric increases over the last 5 minutes.
2. Analysis: EIGRP metric increases indicate deteriorating path quality. Possible causes: (a) increasing interface delay due to queue buildup or congestion, (b) bandwidth reduction from auto-negotiation downgrading, (c) a new link with worse characteristics being added to the path, or (d) K-value changes causing recalculation.
3. Context: Unlike OSPF, EIGRP metrics are dynamic and reflect real-time path quality. A steadily increasing metric suggests the path is degrading. If the metric exceeds the feasible distance of the successor, EIGRP will query for a new path, potentially causing SIA if no feasible successor exists.
4. Recommendation: Monitor interface counters on all links toward 10.16.63.0/24 for errors, drops, or queue saturation. Check 'show interface' for bandwidth and delay changes. Verify K-values are consistent across all EIGRP neighbors. If the path includes a WAN link, check SLA metrics and provider circuit health. Consider implementing EIGRP stub to limit query scope.
</reasoning>
<answer>
WARNING: EIGRP metric flapping/increasing for 10.16.63.0/24. Metric rose from 1452 to 2532. Check interface delay/bandwidth, queue congestion, K-values consistency, and WAN link health. SIA risk if no feasible successor.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
O    10.165.89.0/23 [110/2] via 192.168.59.36, 22:31:40, Loopback11
O    10.113.1.0/24 [110/8] via 192.168.255.243, 01:33:29, Loopback93
O    10.113.2.0/24 [110/9] via 192.168.71.76, 08:49:27, Port-channel6
O    10.113.5.0/24 [110/10] via 192.168.100.14, 02:16:10, FastEthernet2/2
O    10.86.239.0/17 [110/4] via 192.168.9.89, 22:09:43, FastEthernet1/3
O    10.113.0.0/24 [110/17] via 192.168.58.151, 15:33:01, Port-channel7
O    10.91.87.0/19 [110/8] via 192.168.84.144, 12:17:41, Port-channel6
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
O    10.116.201.0/23 [110/3] via 192.168.44.63, 17:05:28, GigabitEthernet3/3
O    10.113.52.0/24 [110/1895] via 192.168.59.231, 21:02:22, Loopback70
O    10.113.3.0/24 [110/18] via 192.168.13.91, 06:37:04, FastEthernet0/2
O    10.17.97.0/26 [110/11] via 192.168.246.13, 08:13:00, GigabitEthernet1/0
O    10.146.22.0/23 [110/19] via 192.168.132.19, 01:34:22, FastEthernet1/3
O    10.113.4.0/24 [110/14] via 192.168.87.118, 12:00:15, GigabitEthernet0/3

Question: Identify all potential issues in this routing table and classify them by severity.

[Assistant]
<reasoning>
1. Observation: OSPF route to 10.113.52.0/24 has metric 1895, while all other OSPF routes in the same area have metrics between 2 and 20. The deviation is 94x to 947x from the normal range.
2. Analysis: OSPF metric is calculated as the sum of interface costs (reference bandwidth / interface bandwidth). A metric of 1895 suggests either: (a) a very low-bandwidth path (e.g., serial link at 64 kbps), (b) manual cost misconfiguration, (c) reference bandwidth mismatch between routers, or (d) a routing loop causing accumulated cost.
3. Context: This skewed metric makes the path appear much longer than it is. Traffic to 10.113.52.0/24 will be routed suboptimally if an alternate path exists. In a hierarchical design, such metrics can break traffic engineering and cause hot-potato routing issues.
4. Recommendation: Verify interface bandwidth settings on all links toward 10.113.52.0/24. Check 'auto-cost reference-bandwidth' consistency across all OSPF routers. If the path includes a low-speed link, consider upgrading or using a tunnel. Verify no manual 'ip ospf cost' override is applied incorrectly.
</reasoning>
<answer>
WARNING: Severe OSPF metric skew for 10.113.52.0/24. Metric 1895 is 94x–947x higher than area average (2–20). Check interface bandwidth, reference-bandwidth consistency, and manual cost overrides. Suboptimal routing likely.
</answer>


[System] You are a network routing expert. Analyze the routing table, detect issues, and provide step-by-step reasoning. Use the format: <reasoning>...step-by-step analysis...</reasoning><answer>...concise answer...</answer>

[User]
Routing table:
B    10.250.46.0/21 [20/4] via 192.168.14.229
B    10.32.18.0/28 [20/5] via 192.168.107.56
B    10.84.106.0/17 [20/7] via 192.168.221.179
L    192.168.1.1/32 is directly connected, GigabitEthernet0/0
B    10.6.190.0/24 [20/942] via 192.168.148.77
B    10.252.8.0/17 [20/9] via 192.168.217.246
B    10.213.80.0/30 [20/2] via 192.168.85.120
B    10.141.136.0/19 [20/7] via 192.168.32.217
B    10.73.26.0/27 [20/2] via 192.168.194.188
B    10.37.65.0/27 [20/12] via 192.168.221.181
B    10.112.96.0/28 [20/8] via 192.168.60.45
B    10.224.139.0/22 [20/3] via 192.168.197.70
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0
B    10.11.15.0/18 [20/0] via 192.168.65.43
B    10.225.229.0/25 [20/4] via 192.168.81.22
B    10.74.133.0/20 [20/7] via 192.168.95.254
B    10.201.224.0/18 [20/5] via 192.168.179.221

Question: Analyze this routing table for Administrative Distance conflicts.

[Assistant]
<reasoning>
1. Observation: BGP route to 10.6.190.0/24 has MED 942, while all other BGP routes have MED between 0 and 15. The MED deviation is 62x to 942x from the normal range.
2. Analysis: MED (Multi-Exit Discriminator) is used for inter-AS path selection when multiple paths exist from the same neighboring AS. A MED of 942 is atypical—normal MED values reflect IGP cost (usually <1000). This extreme value suggests: (a) IGP metric redistribution without scaling, (b) manual MED policy misconfiguration, (c) AS-path prepending combined with MED, or (d) a BGP community setting MED incorrectly.
3. Context: BGP best-path selection compares MED after weight, local-preference, and AS-path length. An extreme MED makes this path the least preferred among equal AS-path alternatives, effectively black-holing traffic if it's the only path. It also complicates traffic engineering.
4. Recommendation: Verify MED configuration on the advertising router. Check route-maps setting MED based on IGP metric—consider dividing by a factor (e.g., 'set metric igp-cost / 10'). Review BGP communities that manipulate MED. Ensure consistent MED policy across all BGP speakers in the AS.
</reasoning>
<answer>
WARNING: BGP MED skew for 10.6.190.0/24. MED 942 is 62x–942x higher than normal (0–15). Check IGP redistribution scaling, route-map MED policies, and community configurations. Path likely depreferred.
</answer>