Metro Ethernet VPN via MPLS VRF's

[sherwinang]

Hello All,

We have deployed VPN's via ethernet and we integrate that via dot1q VLAN's on a subinterface on a GigEthernet. We then make those a member of a specific vrf forwarding VPN for example.

interface GigabitEthernet0/1.101

description VPN-CUST1

encapsulation dot1Q 101

ip vrf forwarding VPN-CUST1

ip address 192.168.125.1 255.255.255.252

ip address 192.168.126.1 255.255.255.252 secondary

no cdp enable

end

The client only wants the Head Office to see the branches, but not branch to branch for commercial and technical reasons eg. viruses/snooping etc. In our ATM subinterfaces, each branch has one subif so each has a different VRF and RD, we then just import the RD to the head office. But with VLAN based branches, we can't do it like this. I hope I had made it clear somehow. The question is, is there any other option to achieve this on a VLAN based subif VPN's? We are thinking of creating a subif VLAN for each branch but what if there are thousand branches, our VLANs will be exhausted easily. Hoping for your insights regarding this.

Thanks!

[mheusinger]

Hello,

a Central Service VPN seems to be, what you need, as far as I understand.

The config could look like this:

ip vrf HQ

rd 65000:1

route-target import 65000:101

route-target export 65000:102

interface GigabitEthernet0/1.101

description HQ link

encapsulation dot1Q 101

ip vrf forwarding HQ

ip address 192.168.125.1 255.255.255.252

ip address 192.168.126.1 255.255.255.252 secondary

no cdp enable

and on the PE, where the remote office is connected:

ip vrf RO1

rd 65000:1001

route-target export 65000:101

route-target import 65000:102

ip vrf RO2

rd 65000:1002

route-target export 65000:101

route-target import 65000:102

interface ATM0/0.1001

description remote office 1

ip vrf forwarding RO1

ip address 10.1.1.1 255.255.255.252

pvc 10/1001

encapsulation aal5snap

...

interface ATM0/0.1002

description remote office 2

ip vrf forwarding RO2

ip address 10.1.2.1 255.255.255.252

pvc 10/1002

encapsulation aal5snap

...

Thus all the remote offices will only get the HQ routes and cannot connect to each other. The HQ will get all RO routes and only one link is needed to connect the HQ, not one link per RO.

Hope this helps! Please rate all posts.

Regards, Martin

[cisand2002]

Hello,

can you clarify/detail this point "But with VLAN based branches, we can't do it like this." ?

regards,

cisand

[sherwinang]

Thanks Martin for the reply. Actually that's how we are doing it right now for ATM based branches. The problem arises when the remote branches are terminated virtually on a VLAN subinterface. Since they're a part of the same VLAN interface, they still could see each other regardless of the RD's since they're part of the same VRF.

For example:

interface FastEthernet0/1.723

description -CUST-A Braches-

encapsulation dot1Q 723

ip vrf forwarding VPN-CUSTOMERBRANCH

ip address 20.10.0.65 255.255.255.248 secondary

ip address 20.10.0.73 255.255.255.248 secondary

ip address 20.10.0.81 255.255.255.248 secondary

ip address 20.10.0.89 255.255.255.248 secondary

ip address 20.10.0.113 255.255.255.248 secondary

ip address 20.10.0.57 255.255.255.248

no cdp enable

end

With ATM there's no problem since we can create separate VRF's for each like what Martin has showed us. With Ethernet VLAN implementations on circuits terminated via MetroEthernet they will see each other.

I hope that somewhat clarified and thanks again for answering, I hope you can recommend a solution.

[mheusinger]

Hello,

So you place all branches in a LAN. Per definition they should see each other!

MPLS VRFs are somewhat like virtual routers operating at network layer. Once you have given connectivity on OSI layer 2 there is little chance to avoid this.

So the best thing would be to have each branch in it´s own VLAN and place the VLAN interfaces in a separate VRF. If this is not supported by the MetroEthernet provider then there might be no chance at all to break connectivity other than installing firewalls at the branch offices.

In brief: in case you have several clients connected to a VLAN in a switch and connect them to one interface on a PE, this PE can not prevent their connectivity.

So: does the MetroEthernet provider offer you branch separation or not?

Hope this helps! Please rate all posts.

Regards, Martin