Netpath not showing redundant LAN links

Between the probe and the destination is about 4 or 5 hops. Some hops, with redundant links, aren't showing redundant paths - netpath is showing a straight hop to hop topology, like a straight line.

Specifically, the flow is crossing a router, that has four uplinks - 2 each to 2 parallel L3 switches, which also have 2 links each to the destination.

So, it should look like line to a baseball diamond. I'm using Cisco EIGRP, with ECMP routing. All the hops are monitored solarwinds nodes.

here's the routing table I'm worried about - as you can tell, the routing table has four hops, with equal metrics:

RMER1#sh ip route 10.24.2.5

Routing entry for 10.24.2.5/32

Known via "eigrp 250", distance 170, metric 51210880, type external

Redistributing via eigrp 250

Last update from 10.24.90.13 on GigabitEthernet0/0/4, 1w0d ago

Routing Descriptor Blocks:

10.24.90.13, from 10.24.90.13, 1w0d ago, via GigabitEthernet0/0/4

Route metric is 51210880, traffic share count is 1

Total delay is 100011 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

10.24.90.9, from 10.24.90.9, 1w0d ago, via GigabitEthernet0/0/2

Route metric is 51210880, traffic share count is 1

Total delay is 100011 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

* 10.24.90.5, from 10.24.90.5, 1w0d ago, via GigabitEthernet0/0/3

Route metric is 51210880, traffic share count is 1

Total delay is 100011 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

10.24.90.1, from 10.24.90.1, 1w0d ago, via GigabitEthernet0/0/1

Route metric is 51210880, traffic share count is 1

Total delay is 100011 microseconds, minimum bandwidth is 1000000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 2

Find more posts tagged with

NetPath

cisco

eigrp

Accepted answers

All comments

john.ta

I have not used Netpath, but from a networking perspective you can only have one good path. You see that * next to 10.24.90.5? This means all traffic is going over 10.24.90.5 - which is why this would be the next hop in Netpath. Only when the metric is modified will traffic take a different path, which would then be reflected in Netpath.

ankthar_lemarre

I believe this is essentially correct. To put it another way, NetPath doesn't care what the paths COULD be, it cares what the paths HAVE been. It sends traffic and monitors the path that traffic took. If you have 100 potential paths and the NetPath traffic has always only gone down one path, only one of the 100 paths will show. If traffic has gone down 20 of those paths during the time NetPath has been monitoring the route, then it'll show 20 paths.

Possibly in the future it'll use the actual routing tables to build out all the potential paths and then show which ones have actually been used.

I don't know 100% for sure, but it seems like this also means it's not useful for QoS, or any kind of traffic shaping. If you're sending HTTP down one path and HTTPS down another path, Netpath will only know about one of them.

lanli.fsm

How do you setup your EMCP? Through Cisco load sharing? If the load sharing ONLY takes into account destination/source IP, service destination port (basically some hash algorithm based on those fields), your netpath probe may ONLY see single path to the given service because all load sharing fields are fixed and result in the same hash value. And that single path is typically your application traffic (for the monitored service) experiences too.

pseudocyber

In my original question, I showed you the output of "show ip route w.x.y.z". Here's a snippet of my same routing table, with just "show ip route". Notice, I have four equal cost routes:

D EX 10.24.2.5/32

[170/51210880] via 10.24.90.13, 1w5d, GigabitEthernet0/0/4

[170/51210880] via 10.24.90.9, 1w5d, GigabitEthernet0/0/2

[170/51210880] via 10.24.90.5, 1w5d, GigabitEthernet0/0/3

[170/51210880] via 10.24.90.1, 1w5d, GigabitEthernet0/0/1

I realize, the * indicates the preferred route at the moment. But the flows will be balanced, across the four equal cost routes.

I don't know much about netpath, but it seems to me, just looking at it, externally, it shows multiple paths, not just the best path. Hovering over the different links, even shows the liklihood of traffic flowing down a given link.

Here's a pic of netpath to google - external routers, show multiple links. Internal routers don't.

sgtp

I know this was a while ago, but did the path ever change, or was it always the same?

pseudocyber

I have a new monitor, at a remote site, and it changes.

sgtp

Hmmm... I have multiple paths that don't show up, but I don't have ECLB.

I have noticed that during a hiccup in the net, I get multiple paths being displayed, which makes sense because over a convergence, traffic could go across more than the primary link.

My assumption, after looking at the scenarios I have and other's I have read about on thwack, is that you will only see multiple paths, if the probe traffic takes multiple paths. If the agent sends out a probe to a remote device and all of the traffic traverses a single link (even though you are ECLB), the agent will only be able to report on those hops. I'm also fairly confident that route-caching is on by default and will send packets down a single link per destination. If you remove go to the interfaces and do a "no ip route-cache" it will change the scheme to per packet and both links might show up.

A word of caution though, when remove the route-cache, the router's CPU might skyrocket depending on your PPS rate because it has to determine where to send each packet rather than caching the destinations.

I can't conceptualize how they could "steer" the probe data to report on other links, that aren't in use at the time of the probe, with programing logic.

pseudocyber

I suppose they're the same path - based on Cisco CEF or port-channel load balancing algorithm.

21122012

I have the same issue, between the source and the target there are devices (switches) that seems to be invisible in NetPath. Is there any workaround?