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.
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
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 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.
description -CUST-A Braches-
encapsulation dot1Q 723
ip vrf forwarding VPN-CUSTOMERBRANCH
ip address 22.214.171.124 255.255.255.248 secondary
ip address 126.96.36.199 255.255.255.248 secondary
ip address 188.8.131.52 255.255.255.248 secondary
ip address 184.108.40.206 255.255.255.248 secondary
ip address 220.127.116.11 255.255.255.248 secondary
ip address 18.104.22.168 255.255.255.248
no cdp enable
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.
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?
1. Introduction Internet security is important with the increasing
attacks that are happening every day. Many internet and browsing
security solutions exist, but some are not very easy to use or maybe the
question is how can I enable them? In this referen...
Cisco Software Manager Server API Guide This document describes the
programmatic interfaces, RESTful APIs, which are supported by Cisco
Software Manager Server (CSM Server). Overview CSM Server supports a set
of finite RESTful APIs. The first step to use ...
If you are using Cisco's new linux-based Cisco Software Manager server,
then you probably want to make sure there is a startup service for
it.I'll assume that you've already installed the CSM server on a
systemd-based linux system. The commands given belo...