Setting advertisement / split horizon direction in EIGRP routing

[Paul Morgan]

Hello all,

I am trying to work out if I am being a bit rubbish or if split horizon is my new worst enemy.

Below is a diagram of my (simplified) problem scenario using EIGRP.

The solution I am looking for is that Router R3 learns of the 10.0.0.0/8 network from both R1 and R2, then does not advertise it to either. Simple with split horizon enabled.

But when either R1 or R2 are rebooted, a decision somehow takes place, and may well determine that R3 should advertise 10/8 to the new (rebooted) neighbour, at which point split horizon prevents it from being advertised back again. This means the topology table on R3 doesn't contain this route for this neighbour and is slow to converge if the other neighbour is lost.

Is there a way to control in which direction routes are advertised first on a neighbour link? and then I can let split horizon do its thing

Or is there something I am not thinking of...

many thanks,

Paul

[Paul Morgan]

Hi Jon,

I cannot reply to your latest post. The page kicks up an error. (Ajax HTTP 504)

Regarding your idea, whilst the solution you propose would simplify the routing at the core, the branches would still have two equal cost routes would they not? Hence potential for loops in the traffic flow.

It would have been a very neat way of doing things

[Jon Marshall]

Paul

Yes, the site is being a real pain at the moment.

I'm not sure I follow.  You said in a previous post -

On R1 and R2, each Interface Tunnel statement includes ip summary-address eigrp 1 192.168.0.0 255.255.192.0 and 192.168.64.0 255.255.224.0

so how do you do 50/50 from each branch ie. are you applying a delay per tunnel somehow.

When you talk about metrics and delay I have been assuming you meant between R1/R2 and R3 whereas now I'm wondering whether it might be for the remote sites ?

How are you ensuring that if traffic comes in from a branch office via R1 or R2 to the core that it gets sent back out of the same router it came in on.

As far as I can see R3 has no idea which router the traffic came in on.

Jon

[Paul Morgan]

Yes the summaries are on the tunnel interfaces to the branches. I was intending to add a delay on the tunnel interfaces, as previously mentioned. So a delay on 50% of tunnels on R1 and then a corresponding delay on the remote ends of those tunnels. This seemed the most logical way of achieving the objective. Both ends then become least candidates. And the increased metric accommodates routing from R3. Or so I thought, until I hit this split horizon issue (which it now seems is my lack of understanding EIGRP features really). So my fallback options are to mess about with AD or to use offset lists. The offset list option is simple and efficient but uses a lot of code. An offset list command for each of half the tunnels on each router. Then one summary ACL and an accompanying offset list command for the connection to R3. I have this working in my lab. Its fine. I just wanted to avoid it with a growing organisation and so many lines of code to error check. 

[Jon Marshall]

Paul

I think that was where I was getting confused.

Why not simply add a delay at the remote end ie. the branch end. That's all you need if you use the solution I proposed.

You don't need the delay on R1 or R2 because they only pass the more specific subnets they are responsible for back to R3 so R3 will automatically route back the same way.

So you just need to make sure that a branch that uses R1 as primary adds the delay to the interface connecting to R2 and the same in reverse for branches connecting to R2 as primary.

No need for any offset lists.

And you still don't have EIGRP queries to make if you lose a branch link.

Jon

[Paul Morgan]

Ah ok, that sounds like it could be a winner. And it answers my original question of why I wasn't able to use delay as a deciding factor in my routing. It was because I always tried it at both ends.

So Ive just tried it and it works fine in production as far as I can see. The only question/issue I have now is how to test one at a time. Since I cant summarise single links, I will have to use at least two active sites I think...

but I like it. It is simple once implemented. Many thanks indeed for all your assistance

[Jon Marshall]

Paul

No problem, glad to help.

If you mean test the whole thing I suggested using summary routes etc. I would recommend testing in a lab first.

I'm not even sure how you tested it in production unless you just mean adding the delay at the other end ?

But yes if you implement the whole thing then deploying a new branch would mean simply adding the summary on the routes on R1 and R2 on the tunnel interface and then adding a delay at the branch end.

As long as the new branch fell within the existing summary ranges then everything else is taken care of.

Jon

[Paul Morgan]

well actually, my earlier post shows a summary of 192.168.32.0/18. This wasn't a mistake. It accommodates the new branches as we work down the subnet range from 32. So I think we have everything covered.

[Jon Marshall]

Okay, well good luck with the implementation, hope it goes well.

Would be interested to know how it worked out.

Jon

[Paul Morgan]

I will update you when we have completed the whole project. Unless there is a catastrophe and I am back here sooner

[Jon Marshall]

Paul

Sorry, been a bit busy.

So each branch sends a summary to both R1 and R2. If traffic from a branch to another branch comes into R2 then R2 should just route it back out of R2.

If however the link on R2 to the destination branch is down then you want to go via R3.

The summary routes are configured on the branch routers not R1 and R2.

Is that correct ?

The only other bit I'm unclear on is when you say -

Traffic was to be load balanced simply (50/50) split using a small additional delay on the tunnels to give preference.

Presumably you are talking about traffic from the core switch ie. not the traffic flow I have described above ?

If so can you clarify when you say traffic is to be load balanced but then you want to give tunnels preference.

If you do want to give some tunnels preference are all these tunnels terminating on one of the routers R1 or R2 or are they mixed between the routers.

Jon

[Jon Marshall]

Paul

I took that definition of split horizon from a post i was involved in a while back with Peter Paluch who knows EIGRP as well as anyone i know.

It may differ slightly from what you know the rule to be.

You may want to have a read of that post as well -

https://supportforums.cisco.com/discussion/12127441/quick-eigrp-problem

Jon