Question on BGP and MPLS

jrhofman · ‎07-09-2003

We have a WAN network using AT&T MPLS service. Our local AS at our headend is 64000 and the MPLS AS is 13979. We propogate a default route out our headend to our remote MPLS sites via a network 0.0.0.0 statement in BGP.

We are going to be bringing on our European locations into the cloud next. They will be utilizing different AS numbers in the MPLS core (AS13980) as well as each location (AS 63000) . Their headend will be propogating out a default rout to the Europe remotes the same as we do domestically.

My Question:

I want to insure that all European remote locations utilize the default route generated by their headend and the US remotes utilize the default generated by our headend. Is this something that AT&T will need to provision in the MPLS cloud, will we need to do something in our edge routers? our is it just inherent in BGP because of the different AS numbers?

rwiesmann · ‎07-09-2003

Hi

Are the edge router under your control? If yes, do you have the control on the

Route Target, Route Reflector and the vrf's?

If so are you indending of creating different vpn's one for europe one for north america?

I think in europe usually the provider has the control on the edge routers. But if

you have the conrol there are different way's do do that.

Regards

Roger

jrhofman · ‎07-09-2003

I'm not sure how to answer primarily do to lack of BGP/MPLS knowledge. We have control of our edge routers (CE). We are doing EBGP to AT&Ts (PE) router. No MPLS between our routers and AT&Ts routers.

It's a pretty strait forward configuration. We peer with the AT&T PE router and then propogate routes into the MPLS cloud via BGP network statements. All our remote routers receive these routes with a destination next hop of their peered AT&T PE router.

The configuration between Europe and US will be a single VPN network providing any-to-any connectivity.

Not sure if this helps you or not

rwiesmann · ‎07-09-2003

Hi

I guess did not understand you correct. It's as the usual setup PE is owned by the provider. So you do not have the control on the RT, RR and vrf's.

My experience is that in the mpls vpn there is only one best route which goes into the routing table....so there is no multipath bgp support.

So that means if you have just one single vpn (same RT in Europe and US) only the better BGP Route will go into the routing Table und thus be distributed from your providers pe to your ce. So in your case only the better default route will be present in the providers vpn routing table and be propagated to your ce. The second will only kick in if the first one disappears.

Unlike the other fellow posted weight and local preference will not help you because this attribute will not be transported to the next AS.

There is a possibility that you can go with communities but this you have to

discuss with the provider.

I would first of all ask your provider if he supports multipath bgp?

Second i would check with the provider if you can influence the RT how they are used and implemented.

If you can not influence this two things i would think about implementing two different vpn's which are interconnected at some point.

Hope that gives you an idea.

Roger

hbaerten · ‎07-09-2003

Since the head office and the remote sites use the same AS, the MPLS provider will probably replace the source AS with its own, so the US remote sites will receive the US default route with an as-path 13979 13979 and the european default route with an as-path 13979 13980 13980.

Since the US route has a shorter AS path, it will be prefered by BGP, so to answer your question: yes it will be automatic. Of course the european route will be used if the US route is not available so if you don't want that you'll have to filter it out.

If for some reason the above should not be the case (e.g; if the MPLS provider does something weird with the AS path) you should still have enough control at the CE routers to prefer one route over another, e.g. by adding a community to the announcement at the head end (different community in US and europe) and at the remote sites put a different localpref or weight according to the community received.

hth

Herbert