Combining PE-CE eBGP VPNv4 prefix exchange with mVPN?

[ERIK LAWAETZ]

Background:

Present MPLS backbone based on 3750ME and 6504/Sup32 to all main locations.

Rigid (and stable) structure at each site with C - CE - PE, eBGP pr. VRF between CE and PE, static/HSRP between C and CE.

C typically 6500/Sup720, CE either 3560(G) or 3750(G).

Only backside to present design is that connectivity between to CEs at a site is via L2 in Cs, that is CE - C - C - CE.

That has provided some interesting failure scenarios :(.

Static configuration with many configuration steps for new networks also provides possible errors.

We're looking at removing the CE and combine the C/CE functionality into the 6500/Sup720 on each campus.

Then we can either run traditional eBGP pr. VRF between C/CE and PE or we could move to a solution with PE-CE eBGP VPNv4 prefix exchange, such as would be used when service providers exchange label info across AS boundaries.

The latter solution means all PEs will accept all VPNv4 routes rather than just the ones for which they have locally defined VRFs.

But it also provides flexibility combined with ease of the configuration, as the PEs are basically reduced to P functionality, and at the same time the usage of eBGP between C/CE and PE means we don't have to include the C/CEs in the IGP (IS-IS) of the backbone and convert them to full PEs, compromising the stability of the MPLS core, while maintaining all the control handles of BGP.

The C/CEs would need to BGP peer with the PEs in the global routing table for exchange of VPNv4 routes and next hop information.

Does this sound like a feasible solution? Caveats?

Next issue at hand is mVPN.

We'd like to support pr. VRF multicast across the MPLS backbone, and mVPN seems like the answer to that. Unfortunately it's not supported now nor will it apparently be so on the 3750ME.

The obvious answer is to move to e.g. 7604 as PE platform, which is a long term strategic option, but it's not gonna happen overnight.

Assuming we implement the PE-CE eBGP VPNv4 route exchange, would we be able to switch the mVPN functionality into the C/CE routers, this taking away the restraints of the 3750MEs?

We would run pr. VRF PIM on the C/CE and define default- and data-MDTs for each VRF on the C/CE.

Obviously we would need multicast routing in the global routing table, both on the PEs (based on PIM-SM, Bidir or SSM), and between the C/CEs and the PEs (based on PIM or perhaps MP-BGP?).

Would this work? Caveats?

[shivlu jain]

Hi elawaetz

From the above I come to know that for the first solution actually you should go with the vrf lite, if you want to club your customers on 6500. For PE-CE a bgp instance is required and it will work only for vpnv4 not in global and its a feasible solution you can go with this.

Solution For MVPN:-

For MVPN you need not worry about the clinet end. You have to take care for the folowing points for mvpn:-

a) Use ip pim-spare-mode for your backhaul, so hat in case of rp failures your clients will not be affected.

b)Choose a suitable multicast protocol like autorp if you are having full cisco domain or BSR for mix breed.

c)If you r using auto-rp advertise your rp information with the help of acl which includes the 239 group becasue by default it takes 224 group.

d)For your cloud default mdt is required (unique for per vrf)and it is only in the global multicast routing table.

e)Data mdt can be used but its an optioal component.

f)Per vrf rp should be required.

g)MP-BGP update should be with one loopback only, if u r having multiple loopbacks for bgp peering then rpf failures problems will arise and you wonot be able to send or receive the streams.

h)3750is specially deisgned for ME; By defaut cisco switches forward the multicast traffic but if u want ot create the vrf then u need a router and 7600 is gud one becasue with this you can go with extranet also.

You last point i already cleared, in global multicast routing table only default mdt groups will be enterted.

regards

shivlu