cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
292
Views
0
Helpful
2
Replies

IGP decisions with MPLS Features...

lcruxon
Level 1
Level 1

Hi all,

I work for a small company with 8/9 POPs in various locations all connected via Ethernet back to our central locations.

We're at the stage of integrating 2 disparate networks at the moment (one running EIGRP, one OSPF, the greater number of devices on the OSPF network) and as I'm going to have to go through the pain of choosing what to do with the integration, just looking for some advice.

I've heard of people doing this in a number of ways, and am interested in what people are doing in the real world in the way are you running OSPF for connected routes and establishing BGP neighborships based on this? Just running OSPF/your IGP throughout?

We will also be looking to roll out some MPLS features such as TE, L2/L3 VPN's and look to your experiences of the best way to go about the overall network so I don't get 3 months down the line and find an absolute error that I have made which means I have to change everything to something else.

Trying to get a feel for what people are doing in practice.

Thanks for any help.

2 Replies 2

mheusinger
Level 10
Level 10

Hi,

If you are going to implement MPLS TE there is little choice, as it is only supported with link-state protocols. In your case this means: replace EIGRP with OSPF everywhere you like to have MPLS TE.

Throughout your entire AS try to use only one IGP mainly for your NMS and BGP next hops. Depending on the size you might look into setting up different areas. If possible use only one area, as this again will simplify MPLS TE implementation quite a bit.

All customer routes should be in BGP either for Internet or for MPLS L3VPNs. So the IGP should provide for fast convergence under failure conditions and provide BGP next-hop connectivity.

Hope this helps! Please rate all posts.

Regards, Martin

swaroop.potdar
Level 7
Level 7

Well, there isnt one way this could be done, everyone would have a

different perspective to to tackle this first hand.

What I would recommend is without considering the existing logical topology,

first jot down the future requirements,

i:e:

1) Requirements:

1) Core IGP (OSPF or ISIS)

2) Services (L2VPN,L2VPN,TE,Hosted Services)

3) Redundancy Requirements and QOS SLA's

etc.

2) Once the requirements are freezed upon you can have a High Level

Design for the requirements done.

3) At this point of time, you will have to look at your existing setup and topology,

then you can figure out, what more changes or additions or deletions need to be done

to your existing setup, and how.

SO when you start thinking and jotting down a plan to migrate the existing setup to the

desired setup it will create a migration plan/Low Level Design document for you.

In the overall process, do not compromize on the requirements because of the existing

setup or topology.

Essentially till you go through step 1 and 2 dont think about your existing setup.

Simply focus of what you want and the overall High Level design for the same.

Then from step 3 onwards you have to focus on the migration and implementation specifics.

Now how to migrate each and every component to what you need is a tedious process and trying to get that achieved in the most possible graceful way, for which you may have to have internal

design dicussions and brain stroming with other people in your team.

And I am sure if you go this path you wont come across a point some time down, where you may have to rethink the whole thing. :-)

HTH-Cheers,

Swaroop