HSRP: Controlling path of returned traffic

matthew.norman · ‎10-19-2016

Hello all,

I am using the following basic topology to assist with the question:

If I initiate a ping from the PC to 10.0.0.2 only two of the packets get returned. It looks like two are going via R1 and the other to go via R2 and get discarded.

I assume that this is due to main router having equal cost routes to the 10.10.30.0/24 network. I understand that I can influence the cost of the routes to force the traffic to return to R1. Would this be standard practice or is there a better way.

Ideally any traffic going out from R1 should return to R1 and the same for R2.

Appreciate any advice.

Matt

Mark Malone · ‎10-19-2016

Hi Matt

that does not sound right traffic should be going by the active only , it should not be going to the standby at all , could you provide the HSRP configuration off both r1 and r2 please

when you trace to 10.0.0.2 does it go by the active ?

sh run int x/x

show standby brief

Rick Morris · ‎10-19-2016

Routes should go to the VIP, and that should be tied to the active router, no traffic should go to the second, that is the purpose of HSRP.

I would look at the hsrp config and validate what is there, also make sure that you only see one active router and one standby, it is possible that you have not established your HSRP active/standby and sending traffic both ways, as indicated in your posting.

Joseph W. Doherty · ‎10-19-2016

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

As the other posters have noted, for "original" HSRP with no redirect added to the interface, all host outbound traffic should go to the active HSRP gateway. mHSRP or HSRPv2, support multiple virtual gateways and might redirect a host to use another gateway if it believes the other gateway offers a better path. (I think I recall original HSRP, if no redirect is removed, could redirect traffic to another router's physical gateway - not a recommended configuration.)

Ideally any traffic going out from R1 should return to R1 and the same for R2.

Why's that ideal?

Splitting a flow's packets across multiple paths can often cause issues, but outbound and return paths being different generally don't cause any issues unless there's sometime in the path (e.g. FW or NAT), that's stateful, that needs to see all the outbound and return packets. For such cases, you generally configure routing metrics so there's a primary path and a backup path, the latter only used if the former is "broken".

BTW, asymmetrical outbound and return path can cause issues with L3 switches when their L2 and L3 timeout timers differ. For these you can also adjust routing metrics are insure the L2 and L3 timeouts match.

matthew.norman · ‎10-20-2016

Hello,

Thank you everyone for all of the responses.

I have set this up in packet tracer to simulate.

If I ping from PC1 to R3 at the top of the diagram, it follows this sequence:

Packet 1: PC1 > R1 > R3 > R2, R2 drops the packet as the destination MAC does not match any of it's interfaces

Packet 2: PC1 > R1 > R3 > R1 > PC1, Packet returns as expected

Packet 3: Same as pakcet 1

Packet 4: Same as packet 2

So the return traffic from R3 is being load balanced as it has two equal cost paths to the 10.10.30.0 network but R2 drops the packets.

Mark Malone · ‎10-20-2016

can you post the hsrp configuration from both routers and the show standby brief or detail

Joseph W. Doherty · ‎10-20-2016

In my experience, Packet Tracer, at least older versions, often worked incorrectly.

Have you tried this on real equipment or a better emulator (e.g. GNS3)?

BTW, when you ping from "PC1 to R3", what R3 IP are you pinging?

If might also help if you would provide the network masks and "how" you're routing between routers.

So the return traffic from R3 is being load balanced as it has two equal cost paths to the 10.10.30.0 network but R2 drops the packets.

I don't see why it should be doing that (see above comment about Packet Tracer).

matthew.norman · ‎10-20-2016

Hi Joseph,

It could just be packet tracer as you say. I have had many issues with it that wouldn't happen in the real world.

I haven't got a real lab to test with but am in the process of setting up GNS3 so may be able to test on there.

For the test I am pinging 10.0.0.2.

The addressing being used is:

PC Subnet: 10.10.30.0/24, Virtual Gateway: 10.10.30.1 (Active 10.10.30.2, Standby 10.10.30.3)

R1-R3 Subnet: 10.0.0.0/30

R2-R3 Subnet: 10.0.0.4/30

R3 currently just has static routes to the 10.10.30.0 network:

S 10.10.30.0/24 is directly connected, FastEthernet0/0

is directly connected, FastEthernet1/0

Joseph W. Doherty · ‎10-20-2016

From what you described R3 should be able to send packet to your host via R1 or R2. However, if your host tried to reply to R3 packets sourced from 10.0.0.6, that would be an unknown destination for R1. In other words, pinging the host from R3, half the pings would fail.

On the other side, pinging R3's 10.0.0.2 from the host should always, I believe, come back from 10.0.0.2 however it might be using both paths. About a month ago, i ran into a somewhat similar issue and found a Cisco router using another equal cost path, not just the path from the interface I was sourcing pings from.

A couple things you can try:

On R3, if supported by Packet Tracer, ping the host using a source IP of 10.0.0.2.

On R1 add a static route for 10.0.0.4/30 pointing to 10.0.0.2 (or run an IGP between your routers).