Hi Jon and Vivek,
Personally, I agree with most of Vivek's recommendations.
Vivek, the one thing I do not entirely agree with is your focused intention of introducing VPNs into Jon's network. I don't see a use case for that in Jon's network. You don't configure VPNs just for the sake of having VPNs, rather, you configure them to provide a specific service you know you need. At the present knowledge of Jon's network, I do not see how the introduction of MPLS L3 VPNs is going to simplify or streamline the configuration and operation, or solve a requirement that could not be met by other means.
Regarding the order of steps of introducing the changes into network, my preferred order would be:
- OSPF (neither BGP nor MPLS will operate without internal routing in place)
- MPLS (to have it running before BGP kick into action so that whatever routes BGP advertises, the path to the other PE's loopback is already labeled)
- BGP + RRs
- Route injection into BGP
One concern I have is the convergence time for new hosts appearing in the BGP table - for example if a new DSL service comes online and their IP appears on a PE, the convergence time will be fairly slow when propagating the route to other PE's when compared to OSPF.
I suppose you are talking about a DSL subscriber connecting and its /32 address being added to the routing table pointing to the appropriate Virtual-Access interface, right? Performing the redistribute connected in BGP could indeed take up to 60 seconds until the customer router is injected into BGP and advertised to its peers. A better approach is this:
- Have your DSL customers get their IP addresses from a particular IP subnet, for example, 192.0.2.0/24
- On the PE that serves these clients, configure the static route for this network, pointing to Null0:
ip route 192.0.2.0 255.255.255.0 Null0
- Now inject this route into the BGP using any appropriate method - a redistribute static can be used, or - in this case, as this is just a single network - the network 192.0.2.0 command would also be appropriate.
This approach has several advantages. First, you prevent BGP from experiencing route churn as DSL clients come and go, because instead of their individual IP addresses, you only advertise the entire subnet these clients can be covered with, and this subnet is stable. Second, this approach effectively summarizes the clients' addresses - instead of advertising hundreds of client IP addresses, you advertise just a single subnet. Third, this Null0 route makes sure that if any packets for non-existent clients arrive to your PE (for example, the DSL client has abruptly disconnected while packets are still pouring in for this client), they will be discarded right away instead of forwarding them through some different route, perhaps a default route, and causing a transient routing loop.
If you have multiple PEs serving DSL clients then each PE should use a unique subnet from which the clients get their IP addresses. This will allow you to extend the suggested approach to an arbitrary number of PEs, each of them advertising its own subnet from which client IPs are allocated.
Best regards,
Peter
