cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
988
Views
16
Helpful
26
Replies

CE's on same subnet (Tunnel?)

johnelliot
Level 1
Level 1

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.

26 Replies 26

No probs, John.

Just another query: do these two sites need to communicate with any other sites apart from each other ?

Paresh

Not these two - but we may have that requirement down the track.

Hmm then you may have to move to VPLS soon enough ;-) or maybe you can do QinQ and transport it. The ideal thing to do for now would be to wait for those to come up.

mheusinger
Level 10
Level 10

Hello,

what you should look for is, whether there are any two hosts with exactly the same IP address in the 192.168.5.0/24 range. If so, then double NAT is the only solution at hand, i.e. you need to solve the problem at OSI Layer3, because within a single broadcast domain IP addresses need to be unique.

If you can make sure under any condition that there are no duplicate IP addresses assigned, then you can still use double NAT (source and destination) or create one OSI Layer2 broadcast domain. There are several possible approaches for this, like bridging, L2TPv3, EoMPLS or even VPLS.

The solution depends on your requirements, forseeable customer requests and hardware/software capabilities of involved equipment (and thus finally COST).

Hope this helps! Please rate all posts.

Regards, Martin

Hi Martin,

Definitely can gaurantee that there will not be two hosts with same IP in the 192.168.5.0/24 range.

We will have requiremtents (In the future) to be able to provide L2 VPNs for clients with varying tails (Eth, ATM + DSL), and leave all L3 configuration to them - VPLS certainly looks promising in this regard.

Thanks to all who replied.

Ok - Ran into a small problem attempting to use the "xconnect" method:

pseudowire-class ETHER-PW

encapsulation mpls

interface Port-channel1.590

encapsulation dot1Q 590

xconnect 10.10.10.102 590 pw-class ETHER-PW

MPLS encap is not supported on this circuit

Does mpls need to be enabled on the FE's ?

can you do a show mpls l2transport hw-capability on the interface and see if it supports egde functionality on Eth VLAN over MPLS. And iam doubtful about support on Port-channels as well.

Else you can try L2TPv3. Please note that EoMPLS is suported from min 7200

Ok - Got a working solution with L2TPv3:

PE1

pseudowire-class vlan-xconnect

encapsulation l2tpv3

ip local interface Loopback23

interface Port-channel1.590

encapsulation dot1Q 590

no snmp trap link-status

xconnect 10.10.10.102 590 pw-class vlan-xconnect

PE2

pseudowire-class vlan-xconnect

encapsulation l2tpv3

ip local interface Loopback23

!

interface FastEthernet0/0.590

encapsulation dot1Q 590

no snmp trap link-status

no cdp enable

xconnect 10.10.10.101 590 pw-class vlan-xconnect

!

And setup vlan 590 on switch ports - Initial testing appears good.

Thanks to all who provided help.

I am looking into using l2tpv3 to bridge multiple vlans between 2 data centers. would anything else be added to this configuration in order to extend the 802.1q trunk for more than one vlan across the tunnel?

I would have a 7206 with a gigabit interface acting as a trunk port, and i'd like to extend the vlans that connect on that trunk to the other site.

Hi Michael,

Just be wary on L2TPv3 - We see very high CPU utilisation whenever traffic passes over the tunnels(7204->7204 with NPE400's)....I've posted a question on this very topic, so hopefully it is a simple fix.

Hello,

I would assume you check with the feature navigator, whether EoMPLS for VLANs is supported in your IOS/hardware combination. Unfortunately there are still several limitations when it comes to EoMPLS.

You might need to use L2TPv3 in case EoMPLS is not yet supported on your platform.

Hope this helps! Please rate all posts.

Regards, Martin

Hello John,

Definately MPLS does NOT have to be enabled on a customer interface with EoMPLS or VLANoMPLS. This is not the reason for the message. If you could provide the hardware and IOS for more detailed help.

Could it be that VLANoMPLS is not supported on your hardware (Sup720?)?

Hope this helps!

Regards, Martin