BGP, Default Routes and AT&T's IPFR service

[jduban]

I'm in the process of implementing AT&T's IPFR service to replace our company's existing frame-relay network. As the network stands today, all of the branch offices connect to 1 of 3 hub sites. Each hub site has a connection to the Internet and injects a default route into OSPF. This provides us with a very clear manner in which the various branch sites access the Internet.

After the migration to the IPFR service, we would like to maintain the deterministic manner in which the branch offices access the Internet. ie. Branch offices in the eastern US which are currently connected via a PVC to the eastern hub, would still utilize the eastern US hub for Internet access after the migration to the IPFR service.

This would require AT&T to make the routing decision based on the destination of the packet and the ASN from which it originated. I don't believe this is possible utilizing only BGP and announcing a default route from each of the hub sites.

One idea would be to build GRE tunnels from each individual branch office to each hub location. The default route would be announced from the hub sites through these tunnels and the branch router would make the decision on which tunnel to use to access the internet. Is there a better approach?

[aretana]

John:

AT&T is replacing your (p2p) L2 connectivity with an (any-to-any) L3 pipe... The advantage is that now you have an instant backup (vs being connected to only one hub). OTOH -- You're right, to get a behavior similar to what you had before, you either have to get them involved in routing your traffic (based on the source) OR you route it yourself (using a tunnel).

I can't offer a lot of wisdom, except for a couple of variations on what you're proposing.

If AT&T is offers you an MPLS service (not clear from their web-site), then they should be able to emulate the exact scenario you had before: set up a VPN connection between each branch and 1 of 3 hubs. By the 'magic' of BGP MPLS/VPN, each branch would then receive only the routes from the corresponding hub. Even better, AT&T may even be willing to run OSPF with you. =:-) In any case, the downside is that he dynamic back up is lost.

The other alternative would be to convince AT&T to use 'set metric-type internal' when advertising routes to you. Theoretically, the paths from the hubs would look the same to them (same AS_PATH length , etc.) and would chose the closest exit -- which should translate into the branch offices in the eastern US using the eastern hub... For this to work, you depend on AT&T's backbone being able to distinguish (IGP metric-wise) between multiple exits.

Note that these two ideas work only if your provider is involved...

Good luck!

Alvaro.

[jsayer]

I've been working on a similar problem with a customer that has implemented an MPLS WAN with a different provider. I've also implemented AT&T's IPFR and E-VPN services. At least with the IPFR, you get control of the customer-edge routers.

With this situation, we've tried to convince our customer to split the network into multiple MPLS VPN within the provider's network. Then each of the hub sites would interconnect the three VPN's and each VPN could have its own default route injected without overlapping with the others. You lose some of the direct any-to-any by doing this, as sites on VPN-A will have to cross a hub site to get to sites on VPN-B or VPN-C. Default routes from other VPN's should look like their one AS further away than the local VPN's default route.

So far, our customer has chosen to go with one big MPLS WAN requiring the MPLS provider to modify their internal routing for the multiple default routes - not sure they will be willing to do this. And I suspect AT&T will be even less willing than others.

Hope this helps,

John