[OSPF] how do I know the path used if both subnet have the same metric

[Gideon Goddard]

Hello,

I'm quite confused !

I don't the path used by a packet to reach a subnet 20.0.1.0/24 because this subnet can be reach by subnet 192.168.2.0/24 or subnet 192.168.1.0/24.

Subnet 192.168.1.0/24 and subnet 192.168.2.0/24 have the same metric....

Subnet 20.0.1.0/24 is behind subnet 192.168.1.0/24 and 192.168.2.0/24.

Here the routing table :

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback1
     20.0.0.0/24 is subnetted, 2 subnets
C       20.0.0.0 is directly connected, FastEthernet1/0
O       20.0.1.0 [110/21] via 192.168.2.254, 00:38:59, FastEthernet0/1
                 [110/21] via 192.168.1.254, 00:38:59, FastEthernet0/0
O    192.168.4.0/24 [110/20] via 192.168.2.254, 00:38:59, FastEthernet0/1
C    192.168.1.0/24 is directly connected, FastEthernet0/0
C    192.168.2.0/24 is directly connected, FastEthernet0/1
O    192.168.3.0/24 [110/20] via 192.168.1.254, 00:39:00, FastEthernet0/0

[acampbell]

Hi,

As both paths have equal cost then you will be load sharing.

See :-

http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/9237-9.html#q3a

Regards

Alex

[Gideon Goddard]

So here is what I see :

A. OSPF uses the metric aCost, which is related to the bandwidth. If there are equal cost paths (the same bandwidth on both multilinks), OSPF installs both routes in the routing table. The routing table tries to use both links equally, regardless of the interface utilization. If one of the links in the first multilink fails, OSPF does not send all the traffic down the second multilink. If the first multilink peaks 100%, OSPF does not send any traffic down the second multilink because OSPF tries to use both links equally, regardless of the interface utilization. The second is used fully only when the first multilink goes down.

But when I wireshark my routers R2 and R3, I see these flux :

How do you understand this ?

Because you were talking about load balancing ..

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Normally you don't.  OSPF supports ECMP, so either path might be used.

If you need all packets to just use one path over the other, you can adjust the OSPF cost to prefer one path.

By default, all packets for the same flow will use the same path.

[Gideon Goddard]

You , one subnet seems to forward the packet and the other "backward" them !

Logical ?

[Masoud Pourshabanian]

Hello,

It is possible. When there are two equall paths, OSPF uses hash of source and destination IP to choose the outgoing interface. Since this hash is calculated localy, the path for returning traffic might be different; however, always the same interface will be selected for a given source-destination. Try this command to check the exact outgoing interface for a specific traffic. If a outgoing interface is used for the specific traffic, that interface always will be used for that flow.

show ip cef exact-route [source] [destination] internal

On R1

show ip cef exact-route 20.0.0.1 2.0.1.1 internal

show ip cef exact-route 20.0.0.2 2.0.1.1 internal

on R4

show ip cef exact-route 20.0.1.1 2.0.0.1 internal

show ip cef exact-route 20.0.1.1 2.0.0.2 internal

Hope it helps,

Masoud

[Joseph W. Doherty]

It's good you mention that, although it presumes packets are being forwarded by CEF.

[Masoud Pourshabanian]

Hello Joseph

I think CEF is active on all cisco routers now. Is not it?

Respect,

Masoud

[Joseph W. Doherty]

It usually is, but it can (sometimes?) be disabled.  Also OP didn't denote device kind (although on a Cisco support site - one might presume we're discussing Cisco devices - laugh).

Also even when CEF is active, some packets might be process switched, and those, I believe, are round robined.  For example, on a CEF active router, if you ping from it, I believe the pings requests are round robined (on just the ping source device).

[Gideon Goddard]

R1#sh ip cef exact-route 20.0.0.1 20.0.1.1 internal
20.0.0.1        -> 20.0.1.1       : FastEthernet0/0 (next hop 192.168.1.254)
                                    Bucket 11 from 16, total 2 paths

Thanks you it seems to works !!

And how do I know the return path of the packet from the same router ?

I've tried the contrary don't seem to work :

R1#sh ip cef exact-route 20.0.1.1 20.0.0.1 internal
20.0.1.1        -> 20.0.0.1       : FastEthernet1/0 (next hop 20.0.0.1)

[Masoud Pourshabanian]

Please check my previous comment. You need to use the second command on R2.

Masoud

[Gideon Goddard]

I can't know it only with R1 ?

[Masoud Pourshabanian]

I am sorry on R4

I will edit my post.

[Masoud Pourshabanian]

You need to consider direction

show ip cef exact-route [source] [destination] internal

R1#sh ip cef exact-route 20.0.1.1 20.0.0.1 internal

If you check this command on R1, it means packets are coming from R4 and going to switch. it does not answer your question. you need to check packets coming from switch going to R4.

Please post the output of these commands

on R1

sh ip cef exact-route 20.0.0.1 20.0.1.1 internal

on R4

sh ip cef exact-route 20.0.1.1 20.0.0.1 internal

Masoud

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

BTW, that's perfectly normal with ECMP, and is known as asymetrical routing.

Occassional asymetical routing can cause issues, usually with devices tracking flow state, but when it does, you configure routing to stop using multiple paths "randomly".