Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Nexus 7010 and issues with EIGRP

We have, for nearly 4 years, used EIGRP on our 6513 to  make use of two unequal links to our branch offices.  This worked because we could use the variance command and cause EIGRP to insert two routes into the table, one from each carrier.  Thus it was we could balance the load to each one with a ratio similar to the ratio of the bandwidth of Link A to Link B.

We just purchased 2 Nexus 7010's to replace our single 6513 core.

After much consternation we have found from our Ciscio SE that the Nexus 6.0.2 software rendition of EIGRP does not support variance. 

Why would Cisco take their own propriatary protocol and then gut it by removing features?  I'm quite ready to send these Nexus boxes back in favor of a newer 6500 series.  MEC doesn't work like it is supposed to and the show-tech runs for over 24 hours without ever finishing (and this we can repeat on both boxes, multiple times).

We've opened a tac case but I just wondered if anyone knows a work around for the 'variance' command?

2 ACCEPTED SOLUTIONS

Accepted Solutions
Bronze

Re: Nexus 7010 and issues with EIGRP

What is your connection to each carrier? If MPLS, what are you doing for PE/CE routing?

Bronze

Re: Nexus 7010 and issues with EIGRP

Nevermind, BGP TE is not really going to help because of the Citrix deal...

So two parts to this if I understand correctly, 1- Load sharing, preferably proportionate to the available bandwidth. 2- How to route voice/video/citrix over carrier A the difficulty being the Citrix subnet is at the site where this traffic engineering has to occur (so we're forced to used a source-based logic)

#1

Even though we tweak EIGRP variace to be proportionally equal to the available bandwidth, we're working with sessions. Even though the session ratio may be roughly equal to the bandwidth ratio, the actual bandwidth used could be totally different. So we could argue that really any traffic engineering mechanism is just as good (functionally) as EIGRP variance. Meaning you could take some subset of your routing table (a third-ish) on carrier 1's WAN router and increase the metric to do manual load sharing. GLBP with weighting would do it, but then you'd have to do static routing to the gateway address (not fun).

Now, all that being said, OER (now PfR) would actually get you closer to load sharing at the prescribed bandwidth ratio. PFR monitors your external links and will dynamically shift loads to even out the bandwidth utilization. It does this one of two ways: PBR if the WAN routers are directly connected, or static routes if they are not. So with the latter, here's an example of how PFR operates: Say you have Host A talking to network B over Carrier 1. PFR decides it wants to move that traffic over to carrier 2 because the bandwidth is unbalanced. It injects a static route pointing to Carrier 2 for network B. Assuming you redistribute static into your IGP at the WAN router, it propagates down to the core.

But OER/PFR can be a beast. It's unfamiliar territory, not very intuitive, and not widely adopted yet. The good thing with it is you can run it in monitor mode for as long as you like till you get comfortable with it. That way you could see what it would do without it actually doing anything.

#2

Since Citrix is at the site where we're doing the traffic engineering, I'm afraid we're stuck with PBR. In the future we'll be able to do TOS routing (probably via PFR), but for now all I can think of is PBR.

5 REPLIES
Bronze

Re: Nexus 7010 and issues with EIGRP

A valid solution may depend on your topology, but I'll toss out a few ideas:

-Traffic engineering to present equal cost paths to the Nexus core

-GLBP on the WAN routers

-Policy-based routing (gross)

-EIGRP distribute list out from WAN routers to lower metrics for half the remote site prefixes (manual load sharing)

Sent from Cisco Technical Support iPad App

New Member

Re: Nexus 7010 and issues with EIGRP

interesting.

Given those options let me share a bit more info maybe you can help me narrow down?

I agree PBR is gross.  We are doing it now. I hate it. But it does exactly what we need to do, coupled with EIGRP/variance that lets my route table see two paths to the office on the other end.

Here are my contraints, imposed by management.  1) Carrier A MUST carrie all traffic for Voice, Video and Citrix sessions.  This is because management mistakenly believes that only carrier A provides QOS.  That is not true, but I can't convince them.  So there is that requirement.  2) All other traffic must be shared over Carrier A and B in an ammount proportionate to the available bandwidth.  3) if either circuit fails the other must pick up with NO delay.

Okay now, what I did to make their dream come true was, I used EIGRP from the two routers (one to each carrier) and used variance to ensure that a seriously unequal link (155MB vs 45MB) would still make it in the table.  Then I used PBR to force certain traffic to prefer the faster link.  Granted, I could have weighted the links differently for vairous network numbers to avoice PBR, at least for voice and video traffic. PBR was needed however because the only way I could identify outbound  Citrix traffic was by the source (citrix servers are on their own network, but workstations are all over the place).  

So now that you have the ugly picture of what I had to do to meet the requirements, I guess my question is, which of the above options will allow me to balance "unintersting" traffic proportionately across two unequal links, while also allowing me to prefer one link for 'interesting traffic', which may only be identified by it's source network, and still faill over if a link dies?  I will start reading on that option right away.  We have to deploy tomorrow night and I only found out about the variance problem yesterday... :-(

Thank you in advance.

Bronze

Re: Nexus 7010 and issues with EIGRP

What is your connection to each carrier? If MPLS, what are you doing for PE/CE routing?

Bronze

Re: Nexus 7010 and issues with EIGRP

Nevermind, BGP TE is not really going to help because of the Citrix deal...

So two parts to this if I understand correctly, 1- Load sharing, preferably proportionate to the available bandwidth. 2- How to route voice/video/citrix over carrier A the difficulty being the Citrix subnet is at the site where this traffic engineering has to occur (so we're forced to used a source-based logic)

#1

Even though we tweak EIGRP variace to be proportionally equal to the available bandwidth, we're working with sessions. Even though the session ratio may be roughly equal to the bandwidth ratio, the actual bandwidth used could be totally different. So we could argue that really any traffic engineering mechanism is just as good (functionally) as EIGRP variance. Meaning you could take some subset of your routing table (a third-ish) on carrier 1's WAN router and increase the metric to do manual load sharing. GLBP with weighting would do it, but then you'd have to do static routing to the gateway address (not fun).

Now, all that being said, OER (now PfR) would actually get you closer to load sharing at the prescribed bandwidth ratio. PFR monitors your external links and will dynamically shift loads to even out the bandwidth utilization. It does this one of two ways: PBR if the WAN routers are directly connected, or static routes if they are not. So with the latter, here's an example of how PFR operates: Say you have Host A talking to network B over Carrier 1. PFR decides it wants to move that traffic over to carrier 2 because the bandwidth is unbalanced. It injects a static route pointing to Carrier 2 for network B. Assuming you redistribute static into your IGP at the WAN router, it propagates down to the core.

But OER/PFR can be a beast. It's unfamiliar territory, not very intuitive, and not widely adopted yet. The good thing with it is you can run it in monitor mode for as long as you like till you get comfortable with it. That way you could see what it would do without it actually doing anything.

#2

Since Citrix is at the site where we're doing the traffic engineering, I'm afraid we're stuck with PBR. In the future we'll be able to do TOS routing (probably via PFR), but for now all I can think of is PBR.

New Member

Re: Nexus 7010 and issues with EIGRP

pFr...yes, that's what our SE said too however he indicated it was kind of 'bleeding edge' and we would not have time to implement it by tomorrow night.  So for now...PBR and some method of stuffing lesser prefered routes in the table.  I will work with that direction.  Thanks!

688
Views
0
Helpful
5
Replies
CreatePlease login to create content