David, thank you, yes it's helpful. I wasn't specific enough, I do know I need their help but they haven't been able to come up with a way for us to do this!

Yes, we're still EIGRP PE-CE. I guess I was hoping for something we can set in EIGRP that will get used in their BGP (I am trying to provide them with "use this, fellas" since they haven't been able to say "we'll use this, Paul." ;^)

We have (and are still) considered switching to BGP but it likely means switching all sites to BGP, we don't think we can do it with just the Data Center 7606's. My current knowledge of BGP wouldn't fit on the head of a pin but a 4d nail would have room. And although I'd love to learn, the conversion itself would be a PITA.

Any other ideas? TIA.

Hi,

If having Sprint cooperate is not an option, the only other thing that comes to my mind is that you can use EIGRP's option of modifying the metric in the inbound direction.

This can be done in both your 7609s and on remote sites.

Use offset-list under your EIGRP process to change the metric of inbound advertisements you get from the PE. By doing so, you could manipulate which of the PE-CE circuits you're using for this particular prefix.

David

I haven't looked at this yet, since I just got the 2nd line operating Monday, but it occurs to me that each remote has only one PE and so only one next-hop. I could certainly use one OC3 or the other at the HQ end by adjusting the remote net's metrics, but I don't see how I could send the remote site traffic BACK via a specific OC3 PE.

FYI Sprint isn't uncooperative they just haven't suggested a method.

Thanks for your input.

Paul

hello , i have an important question which will create a scenario in my mind based on your answer.

Do you want to separate the remote sites traffic based on site criteria no matter what type of traffic it is ? i.e for example you have 10 sites , you will separate 5 sites with all their traffic to one of the hq 7606 and the other 5 to the other.

Or you want to direct certain type of traffic for example voice to one of the 7606 and other types for example data to the other i.e the 10 sites will have access to both 7600's based on the type of traffic.

Another question : is redundancy to both 7600's links an important design issue for you i.e if for example five sites or certain traffic is accessing one of the oc3 links in the hq and this link fails , do you want all the traffic to be directed to the other oc3? is that what you agreed with sprint upon ? or you will have some loss of connectivity for some sites or traffic until link is recovered ?

Thank you ...

Absolutely yes to both questions.

It won't be a division by number of sites, we'll use traffic load to assign a remote to one OC-3 or the other, but yes all traffic from any particular site will use a single OC-3.

And yes, we absolutely must have the redundancy, with one possible change being this: we will have a large (OC-12) link from HQ to the DR site, in 1Q07. We might be willing to have both "sets" of sites use the DR site as their "backup" link, such that the failure of either HQ OC-3 sends their traffic to the DR and then back to HQ via the OC-12. The DR site will have its own OC-3 link to the MPLS cloud as well as the backhaul link to HQ.

Thanx for your interest, looking forward to hearing from you.

Paul

OK this is perfect ...

what i'm suggesting you do is to tell sprint to assign a bunch of sites (decided by you) an RT extcommunity and the other bunch a different RT.After that they will import in each one of the HQ PE'a a different RT than the other which will cause separate sites routing information to be redistributed into EIGRP process of the PE and by then to your devices.

If we keep the solution up to this only we won't have any redundancy so what you should do next is to let sprint import both RT's for all the set of sites into the DR PE (or they could assign a third common RT for all the remote sites to be imported in the DR PE ONLY).

please tell me if the oc-12 link is a dedicated leased line (dark fiber for example) or a layer3 mpls shared link.

In the first case sprint will only have to increase the metric (make them less desirable) of redistributed routes from the MPBGP process to the EIGRP inorder to choose those routing information as the last option when one of the oc-3's fail and not to choose it whenever both HQ links are active.You will not have any problems with external vs internal eigrp learned routes because all those routes already reached the DR PE as external and this is the way they will reach the HQ through the oc-12.

Waiting for your response ...

This sounds pretty good so far. The HQ-DR OC-12 is a completely separate link, dedicated leased line.

As an aside, I had found the route-map "set extcommunity rt" facility and asked Sprint if that would work (not knowing how it works) - I haven't had a (sensible) answer yet. They suggested SOO - which I *will* need to reduced problems from the backhaul OC-12 - but SOO will not solve THIS OC-3 assignment problem, I'm sure.

So, if Sprint will set up the rt targets (right?) in the MPLS cloud, can we use "set extcommunity rt..." in the remote CE routers, to control what goes where ourselves? I say this because Sprint is fairly responsive to up/down/error issues but the more complex things take a lot longer to address. If we can have them set up the system once and we do the ongoing maintenance, we can monitor the load and adjust it ourselves.

HTH, thanx.

Paul

OK "set extcommunity rt" might work if you are already exchanging extended communities with sprint which i think is not happening because extended communities are only exchanged via BGP updates (as long as i know) so the only routing protocol that might be used in that case is BGP.

In your case and since your PE-CE routing protocol is EIGRP , setting the RT's could only be done inside sprint cloud.That's why i suggested my last post solutions.

I prefer if you suggest it to them and see what they might say.

I'm totally supportive with you when you say you want to remove as much administrative burden as possible upon them inorder to have a quick suitable setup but in all cases since you are using layer 3 mpls links , you will always need their help especially in routing decisions with redundant links.

One more idea i have which will make things much easier for them (but will never negate their important role) is to use ordinary route tagging with route maps on your CE's (done by you).You could simply tag all the routes coming out of a group of sites with a certain tag lets say 19 and the other routes from the other set of sites with 29 and let sprint match with another route map on their HQ-PE (done by them) those routes and change their metric on the HQ PE's while redistributing them into EIGRP.So that tags 19 take a less metric (preferred) on HQ-PE-1 which is connected to HQ-CE-1 and other routes with other tags take default metric (less preferred) and vice versa on the other HQ-PE.By this you will have redundancy and separated sites on each HQ-PE.

Please inform me if that's ok with you and THEM :-)