When first bringing the routers online, both routes show in the BGP table. The route that’s first in the BGP table (based on how long it takes the devices to come online) will be inserted into RIB. After about 5 to 8 minutes, only one route shows in the BGP table and in RIB, and it’s the proper one based on the BGP selection process.

During failover, the GRE route takes over in about 4 seconds. After failover, once BGP has re-established, both routes show in the BGP table and the GRE route remains as best route for 5 to 8 minutes before the BGP process switches to the MPLS route, which is the inserted into RIB.

Sorry for the confusion but it’s been a while since I played in the lab and my impatience got the best of me. Once again, thanks for the great lab.

In the normal state, both routes show in the BGP table with only the MPLS route in the RIB. During failover and after failover, only the GRE route shows in the BGP table and the RIB. After I clear the iBGP peer, it returns to normal state.

Well, I’ll play with it more tomorrow to see if I can figure out the issue and then post the results. Thanks for the prompt reply.

The only thing of concern is when I reconnect the Paris-M router and after the BGP is re-established, the route to London-M from Paris-M remains through the GRE tunnel. The only way I can get it corrected is to reset the iBGP connection to Paris-I. Have you experienced this before and were you able to find a solution?

Thanks for the great lab,

Jerry

Here’s a good one for you: last week I had to add a new allowed SNMP IP to around 50 ASAs. A bunch of them weren’t showing up in Orion, it took me awhile to realize that I specified the wrong interface (outside instead of inside) on a bunch of them. Doh.

Just to amuse you, it took me about an hour to find where I had gone wrong with the initial MPLS config, earlier in the Lab…couldn’t get the right response to “sh mpls ldp neigh” for MPLS-PE2…you would think I could tell the difference between 255 and 225, wouldn’t you???

Many Thanks

Jim Blake

Thanks for the post and kind words!

I’ll admit, I did jump around quite a bit when doing these guides. I probably could have made them flow better. In this one using Chicago-M as the ping source was probably a bad choice as, like you said, we hadn’t touched that router yet nor had we configured the MPLS VPNs. I probably should have used NY-I as the source, sorry about that.

I do believe we covered the MPLS VPNs and Chicago-M in the later posts. Here is a summary of the guides:

Part 1 – Configured Internet1 and Internet2
Part 2 – Configured WAN MPLS cloud
Part 3 – Configured London and Paris Internet routers
Part 4 – Configured New York-I
Part 5 – Configured MPLS VPNs in the WAN
Part 6 – Configured M routers

Again, sorry for the confusion in this one, choosing Chicago to run the ping from wasn’t the best idea on my part.

There is just one thing I don’t get…You are usually very complete with your descriptions, or you say when you omit stuff….but I just worked through the configs on this part (4) of the Lab, and you go from configuring New-York_I to testing using Chicago_M as a ping source. At this point you haven’t configured (or even mentioned) Chigago_M, and if it’s going to communicate with 10.128.0.1, the Internet_1 Lo0 range, from its own loopback range 192.168.5.1, then it has to go through the (MPLS) network in AS65535…But so far we have not configured the VPNs in that AS, nor even got BGP running in AS 65535, so getting the VPNs running is still some way away. We have OSPF running, but trying to ping from Chcago assumes we have already done some (at least basic) configuration on Chicago_M.

I will be creating my own configuration where I need to, to complete the LAB, and I have to say that its only because of your work that I could even think of putting such a complex config together, but can you clarify for me: did I miss a bit of your write-up, did you miss a bit of your writeup, or did I completely miss the point? I don’t want to criticise your work, but I’m puzzled….

Regardless of all that, this is one fine Lab, and has been a great learnng tool! Thanks!

Jim