CE's on same subnet (Tunnel?)

[johnelliot]

I have a requirement to setup a VRF over 2 PE's where there is a CE hanging of each PE running the same subnet (192.168.5.n/24) - The CE's addressing cannot be modified.

I'm assuming I will need to setup a tunnel?

Any suggestions greatly appreciated.

[pkhatri]

John,

I'm not sure a tunnel would help. In the context of layer 3 routing, if each CE advertises that 192.168.5.n/24 subnet to its PE, other PEs in the network will have the option to select between one of the two routes and will select one or the other. You will end up with traffic destined for that network being directed to one CE or the other and things would not work too well.

One option you have is to NAT all the traffic from both of the CEs and advertise the NATed address blocks into the MPLS cloud. That way, you won't have

duplicate networks in the MPLS cloud and the two CEs will be able to communicate with each other.

Hope that helps - pls rate the post if it does.

Paresh

[johnelliot]

Thanks for the quick response Paresh - So there's no way to establish a layer 2 tunnel between the two CE's?

[pkhatri]

You could possibly configure a GRE tunnel between the sites and then bridge over it but you will not solve the underlying problem of the duplicate networks...

Paresh

[nrmdcs]

John,

What exactly is the topology here? Do you want both CE routers to be in the same VPN? If you have two CE devices that you want to belong to the same VPN (VRF) instance, you'll need to NAT. If the CE routers are to belong to different VPNs, you don't have a problem - the VRF functionality will keep the routes separate.

Jon

[johnelliot]

I would prefer not to do NAT - So if two seperate VPNs will solve my problem, I'm happy to go that way.

We basically have a backup network in one location that operates on the 192.168.5.n/24 network - We are moving one of the backup devices to a remote location, to give ourselves some goegraphic redundancy(For backups) - All backup clients backup to primary backup device, then to secondary (Hence the reason, we cannot change the IP of the secondary backup device). I was hoping there was a way to create a "layer 2" VRF so the 192.168.5.n/24 network could co-exist at both locations.

[pkhatri]

John,

The two-VRF solution allows you to use over-lapping space but you still will not be able to cummonicate between the 2 VLANs without doing NAT. So if that's what you want, your problem is still not solved...

Paresh

[attrgautam]

If you are using Ethernet, then probably you can extend the VLAN over the MPLS cloud(ATOM) and use the same IP Segments at either space. This will make ur n//w transparent to the SP core.

Or on a layer 3 solution you can do anycast and if the primary site fails the route is removed from the routing table and flaps to the 2nd site. Let me know if i came close to understanding your requirement.

[johnelliot]

Thanks for the response.

Yes we are using ethernet with dot1q - Do you have any links/examples on how to implement extending the vlan over the MPLS cloud?

[attrgautam]

http://www.cisco.com/en/US/products/sw/iosswrel/ps1612/products_feature_guide09186a00800e9571.html

Here you go this should help you.

[johnelliot]

Thanks for the url - I also did some searching last night and came across this : http://book.itzero.com/read/cisco/0510/Cisco.Press.MPLS.Configuration.on.Cisco.IOS.Software.Oct.2005.eBook-DDU_html/1587051990/ch11lev1sec2.html

Which uses xconnect - Is this also a viable option?

[pkhatri]

John,

I'm not sure if ATOM will work for you. Firstly, EoMPLS uses point-to-point links and that does not quite fit your requirements. Secondly, if you are going to be doing so, your PEs need to be running MPLS out to your CEs (a Carrier of Carriers setup)...

Paresh

[johnelliot]

Paresh,

In the example URL I provided( http://book.itzero.com/read/cisco/0510/Cisco.Press.MPLS.Configuration.on.Cisco.IOS.Software.Oct.2005.eBook-DDU_html/1587051990/ch11lev1sec2.html ), it states there is no awareness of the MPLS backbone to the end-user routers:

"There is no requirement that the VLAN identifier should be the same at both the ends. The most important detail is the VC identifier. The value 100 is used on both PE1 and PE2. From the end-user perspective, the EoMPLS service appears as an extension of their Ethernet segment (or in this case, a VLAN). There is no awareness of the MPLS backbone to the end-user routers"

The sample vlan config also doesn't mention any requirement to have MPLS out to CE's:

PE1(config)#interface FastEthernet5/0.100

PE1(config-subif)# encapsulation dot1Q 100

PE1(config-subif)# no cdp enable

PE1(config-subif)# xconnect 10.10.10.102 100 encapsulation mpls

__________________________________________________________________________

PE2(config)#interface FastEthernet5/0.100

PE2(config-subif)# encapsulation dot1Q 100

PE2(config-subif)# no cdp enable

PE2(config-subif)# xconnect 10.10.10.101 100 encapsulation mpls

Unless Im missing something?

[pkhatri]

Hi John,

Maybe you need to clarify your requirements to me... do you control the PEs ? I was under the impression that you had purchased a VPN solution for which you needed some mechanism on the CEs to merge two LANs....

If you do control the PEs, then AToM is certainly an option. But in such a case, you will need to configure your CE devices up as bridges so that the LAN can be truly extended between the two CEs. Then, you can use a xconnect to create the EoMPLS link between the two CEs.

Pls do remember to rate posts.

Paresh

[johnelliot]

Hi Paresh,

We do indeed control the PE's - Apologies if this wasn't made clear in my initial post.

Thanks for your assistance.