Solved: MPLS, GRE (with no IPSEC) & Dynamic Routing

sterdnotshaken · ‎04-17-2010

Good day my friends!

Just wondering if any of you could help shed some light on how I would do something. We are switching over from a Point to Point connection between sites to an MPLS one. I have read that Multicast is not permitted across MPLS, so after terminating the MPLS circuits into our network, I created some GRE Tunnels to allow for Multicast (for Dynamic routing as well as Music on Hold)... Everything went well, other then all traffic between the sites is going over the Tunnel interfaces. I would prefer that only multicast traffic go over the GRE tunnel and all other traffic traverse the MPLS without GRE Encapsulation.

I attempted to do this by doing the following... I wrote an access list indicating Multicast source addresses, then created a route map and did a match ip address acl and set interface to tunnel. then I applied that route map to the vlan (although it doesn't give me the option for direction on the 6509 switch) that the single interface is a member of. That interface goes to the router provided by the service provider. I did the same in the other site as well (2811 router, appied to the interface). What have I done wrong so far?

We run EIGRP and I did inject the tunnel ip addresses into eigrp, after which traffic started going across it (the tunnel). I need to make sure that routing can find a path via MPLS in EIGRP outside of GRE, and for that all I have done so far is create static routes (on our 6509 and 2811 devices that the MPLS terminates to) with the destination subnet being in the other site between the qwest router and our router (Did that at both sites). I havent created any static routes for remote sites internal subnets because I would like EIGRP to do that, I don't want to rely on Static routes for routing between sites as far as our internal routing.

So I guess, my question is 2 fold:

What else do I need to do to get EIGRP to know about the path between sites over MPLS besides through the GRE tunnel?

&

How would you control traffic so only Multicast traversed the GRE tunnel where all other traffic would go over MPLS natively?

Any help you could lend would be very much appriciated!

Laurent Aubert · ‎06-04-2010

Hi,

SP usually limits the routing protocol shared with the customer to BGP as it's the most flexible one to implement and it avoids them testing all of them to support them..

You don't need mroute on the 6500 as they are only receiving PIM Join from the tunnel. You would need them if you have sources on the remote site and in this case your assumption is correct (mroute point to the remote site subnet only)

If you have a single upstream router (Adtran router) to the source, you don't need the DR tuning.

HTH

Laurent.

View solution in original post

Laurent Aubert · ‎04-17-2010

Hi,

If you activated PIM under the tunnel interface, you don't need the PBR config and as soon you have an active receiver on the remote site, the remote router will send a PIM join over the tunnel (assuming you are using SSM or the RP is located a the central site where the source is). To avoid loops there is a mechanism called RPF (Reverse Path Check) so a router will accept multicast traffic on its interface only if it will use the same interface to join the source or the RP if we are on the shared tree.

As a result your multicast tree will follow your IGP shortest path even if it's build on the reverse direction.

To achieve what you want i.e. multicast over the tunnel and unicast traffic over the physical interface, you need to tune RPF by telling the router it needs to use its tunnel interface as its RPF interface toward the source. This way we bypass the IGP route (assuming EIGRP is not running anymore inside the tunnel) and the PIM join will be sent over the tunnel even if your unicast route point to the physical WAN interface. Here is the command to apply on each remote site:

ip mroute 0.0.0.0 0.0.0.0 tunnel x

Any sources will be RPF check against the tunnel interface.

Regarding your unicast routing policy, you need to check with your SP which dynamic routing protocols you can share with him.

HTH

Laurent.

sterdnotshaken · ‎05-21-2010

First off, please accept my apologies for not responding to your reply Laurent... I really appreciate your gracious help as I try to figure out solutions for this and other issues...

So, regarding your response, it sounds like I don't need the PBR then, so that is good to know. A couple additional questions come to mind...

If it were you (anyone reading this), and you had 2 sites connected via MPLS and you had a need for Multicast to traverse between the sites, how would you do it? I chose the GRE route due to that fact that it support's multicast, yet it may not be the best method. So, any other ideas would be appreciated!

My original plan was, for only Multicast traffic (EIGRP and PIM-SM) to use the GRE Tunnels, and for everything else to use the MPLS without GRE encapsulation... and Laurent has given me some ideas on how to accomplish this, yet, I am still not quite sure what to do... Could you Laurent, or others elaborate on how I can configure my edge devices (2811 on one end, and 2 6509 switches on the other end with 2 GRE Tunnels (2811-6509A & 2811-6509B))? The SP from which we are getting MPLS runs BGP to the CPE devices... So could I try and implement IBGP on the routers in front of the CPE routers (my routers, behind the CPE routers) that has EBGP running (using the private AS # that the CPE routers are using) and then route between sites using BGP and then use the mroute command to send all multicast over the tunnel and everything else would use BGP for dynamic routing purposes? (That may be a dumb idea, I don't know)

Also, is there any downside to letting all traffic use the GRE Tunnels for communication (other then the extra overhead)? if not, maybe I shouldn't worry about separating Multicast from Unicast traffic and dictating what should use which. What do you think? If you would recommend this, how do I control fragmentation on 6509 switches? @ the one site, the MPLS is terminated at a 2811 router and I can use the ip tcp adjust-mss command, but the 6509 switches don't have that feature, so how do I ensure traffic going over the GRE isn't being fragmented? With the ip mtu xxxx command?

I promise to respond promptly to whoever can help me out with this, and really appreciate any help you can offer.

Thanks!

Laurent Aubert · ‎05-25-2010

No worries !!

GRE is your best choice except if your SP confirms that it can transport your multicast traffic.

Let's assume the answer is no. In this case you should dedicate the GRE tunnel for multicast only and send natively your unicast traffic to your MPLS link. The main advantage is it scale better if you add more sites because if everything is GRE based, you will have to deal with a complex meshing which will become a nightmare to manage, troubleshoot,..

The way you learn the remote prefixes from the CPE really depends on what your SP supports. Some support any routing protocol and other support only few of them. You have to discuss with them and BGP can be the solution.

Here is an example for the tunnel config:

int tunnel 0

descri to 6509A

ip add x.x.x.x/30

tunnel source

tunnel destination <6509A WAN interface>

ip pim sparse-mode

keepalive

!

int tunnel 1

descri to 6509B

ip add y.y.y.y/30

tunnel source

tunnel destination <6509B WAN interface>

ip pim sparse-mode

keepalive

!

ip mroute 0.0.0.0 0.0.0.0 tunnel 0 1

ip mroute 0.0.0.0 0.0.0.0 tunnel 1 10 <-- higher AD

So in this case tunnel 0 is the primary one and tunnel 1 the backup one.

You need to make sure that at the hub site if both 6500 are on the same subnet facing the source, 6509A is the PIM DR (higher priority) for that subnet.

If you are not familiar with multicast, I suggest you to start with one tunnel only and see the impact of adding a another one in a 2nd phase once you feel comfortable with multicast.

HTH

Laurent.

sterdnotshaken · ‎05-26-2010

Thanks for the reply Laurent!

Ok, so I just got off the phone our SP and they said they do not support Multicast transport over MPLS... so your assumption is correct...

I see, so it sounds like I want to stay away from allowing all traffic to traverse between sites over MPLS via GRE... I never considered the issue with scaling when using GRE for all traffic. Good to know!

While I was on the phone with our SP, I talked with them about routing protocol's they support via MPLS, to which they responded with BGP as really the only option.

FYI, this is our current WAN arrangement between 2 of the sites:

Site A>Cisco 2811>Adtran Router (SP provided)>PE-PESite B

Site A>Cisco 2811 (same as above)>Adtran Router (SP provided)>PE-PESite B

The SP suggested we run OSPF between our hardware and the Adtran routers and then 2-way redistribute subnets between EIGRP to OSPF and then from OSPF to BGP as follows:

EIGRP ran inside Site A and B

OSPF running on outside facing interface on 2811 and 6509

OSPF running on inside interfaces on Adtran routers

Private AS BGP running on Adtran with Public AS neighbor to PE device

This should work, but wouldn't it work for me to just configure BGP on our 2811 and have a IBGP adjacency between it and the Adtran Router and then filter what routes are redistributed from and to IBGP on our 2811 into EIGRP? If this would work, does one design have any advantages over the other? It seems like the EIGRP to OSPF to BGP idea has to many moving parts...

My objective is to allow all devices in all locations (4 MPLS sites) to route dynamically, verses relying on static routes.

Regarding the Tunnel config's... I see... Excellent example. OK, so it sounds and looks like I would first configure each site with the routing protocol solution, then, implement GRE with per the example provided, and that would accomplish Multicast over GRE and everything else over MPLS! Thanks alot Laurent!

So what would you recommend regarding the routing protocol structure?

Laurent Aubert · ‎05-27-2010

Hi,

OSPF or BGP can do the job but if it's BGP I think the SP will accept only eBGP session and not iBGP. Between the two, you should choose the one you are the most comfortable with.

HTH

Laurent.

sterdnotshaken · ‎06-02-2010

Ok, so I checked with the SP and your correct, they will only accept EBGP sessions with customers... why is that?

I am just about ready to go live with this config, but wanted to run a few final questions by you all...

With regard to the ip mroute 0.0.0.0 0.0.0.0 Tunnel 1 command, what is the effect of that command on the 6509 switches that have multicast traffic pass through them from the RP to some host that is @ that same site... having never used the mroute command, will that command tell switch that - 0.0.0.0 0.0.0.0 - any source address is reachable through the tunnel interface? that isn't the command I would want @ the main site, right? I would use that command @ all (3 remotes sites all connected via MPLS) remote sites? and @ the main site, I would be more specific with something like ip mroute 10.155.0.0 255.255.0.0 tunnel 1 (where 10.155.0.0 is a subnet at a remote site)?

Also, Laurent, you had mentioned this: "You need to make sure that at the hub site if both 6500 are on the same subnet facing the source, 6509A is the PIM DR (higher priority) for that subnet."

How is that accomplished? Both 6509 switches are indeed connected to the adtran MPLS router (which is a layer 3 switch, although both 6509 switches are connected via the same vlan on that adtran) via the same subnet...

Any help would be appreciated!

Laurent Aubert · ‎06-04-2010

Hi,

SP usually limits the routing protocol shared with the customer to BGP as it's the most flexible one to implement and it avoids them testing all of them to support them..

You don't need mroute on the 6500 as they are only receiving PIM Join from the tunnel. You would need them if you have sources on the remote site and in this case your assumption is correct (mroute point to the remote site subnet only)

If you have a single upstream router (Adtran router) to the source, you don't need the DR tuning.

HTH

Laurent.

sterdnotshaken · ‎06-22-2010

Hey Laurent,

I just wanted to thank you for the excellent help you gave me on this MPLS\GRE implementation. Everything went smoothly and all (including Multicast) is working perfectly. I really apprecated you taking time out of your life to help me out!

Steve

Laurent Aubert · ‎06-22-2010

Hi Steve,

I'm glad to read that :-). You are now able to help other guys with multicast issue in MPLS environment ;-)

Good work

Laurent.