And Re: HP 10500 Series with isolated vlans

[BMNetworks]

Hello,

i need a solution for a vlan scenario. We have 20 vlans on a HP 10500 with intra-vlan routing activated. Now there should be placed some customer vlans. Every customer should get five vlans. All customer vlans should be isolated to all other vlans but the vlans of every customer should be routet on the core.

So we have vlans 10-30 with intra vlan routing for lokal server and other things. Customer A has vlan id 1001 -1005, customer B has vlan id 1011-1015. VLAN 1001-1005 sould be routet on the core, but not with all other vlans. the same for customer B.

How can I solve this?

THANKS

[Fredrik Lönnman]

Look at vpn-instances, its essentially a virtual router instance separated from the main routing table and other vpn-instances.

[BMNetworks]

And what about isolate vlans with secondary vlans? Is it possible to create vlan interfaces on secondary vlans in one isolate-vlan so they can communicate?

[Peter_Debruyne]

Hi,

Isolated user vlans are a mechanism to filter inside the vlan, so you can have e.g. 3 groups of users inside the same vlan, each of the groups can reach a server or service, but they cannot reach each other.

In your case you want to restrict communication between the vlans of different customers, so as Fredrik said, you have to go with VRF (vpn-instances). Technically an ACL could help, but vpn-instances will be much cleaner to configure.

Essentially you will give each customer his own routing table, which is totally independent of the other customer routing tables.

To allow communication between the public and customer routing tables, you can use route leaking, so you can allow some routes to be passed between the 2 routing tables.

Let us know if you know enough or if you need a configuration example,

Best regards,Peter

[BMNetworks]

OK, I understand. But a config example would be very nice.

Thanks

[Peter_Debruyne]

Hi,

this would be a sample config

# configure your internal (also referred to as public or global) routing table
vlan 10 to 30
int vlan 10
 ip ad 10.0.10.1 24
int vlan 11
 ip ad 10.0.11.1 24
...

# verify
display ip routing-table

# define routing table for customer1 (name is case-sensitive !)
ip vpn-instance customer1
 route-distinguisher 65000:1

# define ip interfaces for customer1, link them to the customer1 routing table and set IP
vlan 1011 to 1015
int vlan 1011
 ip binding vpn-instance customer1
 ip address 10.1.1.1 24
int vlan 1012
 ip binding vpn-instance customer1
 ip address 10.1.2.1 24
...

 # verify
dis ip routing vpn customer1

# define routing table for customer2
ip vpn-instance customer2
 route-distinguisher 65000:2

# define ip interfaces for customer2, link them to the customer1 routing table and set IP
vlan 1021 to 1025
int vlan 1021
 ip binding vpn-instance customer2
  # ip addresses can overlap between vpn intances, but then not route-leaking will be supported (no NAT on 10500)
  # so safest is to keep addresses unique per customer, in case some customer to customer communication would
  # be required
 ip address 10.2.1.1 24
int vlan 1022
 ip binding vpn-instance customer2
 ip address 10.2.2.1 24
...

 # verify
dis ip routing vpn customer2

 # customer internet access
You have 2 options:
1/ configure a firewall per customer, connect it to one of the customer vlans and configure the default route in the vpn instance to the firewall:
ip route-static vpn-instance customer1 0.0.0.0 0 10.1.12.254
dis ip routing vpn customer1

2/ use a central firewall which knows all the subnets. Recommend to use a dedicated vpn instance for it.
 # define fw vpn
ip vpn-instance fw
 route-distinguisher 65000:100
 # define routed interface in vpn
vlan 100
int vlan 100
 ip bind vpn fw
 ip ad 10.100.1.1 24
 # define default route in vpn, pointing to next hop firewall, assuming fw is configured with IP 10.100.1.2
ip route-static vpn fw 0.0.0.0 0 10.100.1.2

 # verify
dis ip routing vpn fw

Next, distribute these central firewall route into each customer vpn: customer vpn knows how to reach firewall, not the ther customers. Firewall vpn does not know the customer at this point, so this would be 1 way traffic.

Next, distribute each customer routing table into the firewall vpn, so the firewall vpn knows how to get back to the customers (now we have 2way communication).

This is done through a local BGP process:

 # start local bgp process with private AS number
bgp 65001

 # bgp database(routing table) needs to be populated with routes learned from the "customers", which are the vpn-instances, as well as the fw vpn:

 ipv4-family vpn-instance c1
  import-route direct
 #
 ipv4-family vpn-instance c2
  import-route direct
#

# for the fw vpn, make sure to import the static routes as well (this is the default route to the internet)
 ipv4-family vpn-instance fw
  import-route direct
  import-route static
 quit
 quit

 # now all the routes are in the bgp database, but isolated from each other:
dis bgp vpnv4 all routing

 # nothing changed at this point for the actual routing tables:
dis ip routing vpn c1
dis ip routing vpn c2
dis ip routing vpn fw

 # let's give these routes a proper "marking" or label, so the correct routes get imported to the correct vpn instances. This is done via a vpn-target field. Whenever bgp imports a route from a vpn, this routes can get 1 or more vpn-target markings in the bgp database.

These markings can be used on another vpn to select which routes (with which marks) you want to import.

# In this case, it is simple (remember to think in 2 directions : customer to fw and fw to customer)

 # to populate the fw vpn, you can mark all customer routes with 1 mark, and configure the fw vpn to "import" routes with that mark:

ip vpn c1
 # vpn target typically consists of the bgp AS number, next some locally significant identifier (you can choose)

 # it has nothing to do with the route-distinguisher configure earlier, just a new number range.

 # this action will mark the routes in the bgp db with this label:
 vpn-target 65001:1001 export-community

ip vpn c2
 # vpn target typically consists of the bgp AS number, next some locally significant identifier (you can choose)
 vpn-target 65001:1001 export-community

ip vpn fw
 # now the fw vpn will search the bgp db for label 65001:1001 and import the matching (in this case customer) routes
 vpn-target 65001:1001 import-community

### same for the other direction
ip vpn fw
 vpn-target 65001:1000 export

ip vpn c1
 vpn-target 65001:1000 import

ip vpn c2
 vpn-target 65001:1000 import

# this will ensure the fw vpn routes are learned in each customer network.

That should be it. The first time you do this it may look complicated, but give it a try, it is not too complex and avoid heavy maintenance on ACLs between the customers.

Best regards,Peter

 

[obrunori]

Hi,

Thanks Peter for the config and comments which are clear.

I have one question concerning the bgp option.

If the instance fw imports routes from all customers instances, this will allow routing between customer instances without being filtered by the firewall. Only traffic to and form Internet is filtered.

Is that correct?

Best regards,

Olivier.

[adagre]

Hi Peter,

I have the same scenario. I am curious to know how do we provide the VPNs to edge switches? I have a mixed bag of edge switches. Do they need to be VRF capable as well. Our cores are HP A7500's and we are trying to utilize vpn-instance for vlan and customer isolation. We can get all the OSPF working and such but we can't seem to be able to provide it to the edge. Thanks