SRW2024 Vlan with PVE fonction

Unanswered Question
Jan 15th, 2010

Hi,

I have an installation with 6 swr224 switches connected to a srw2024 switch. Each srw224 is for one different company. We built trunk connexions with a different VLAN number for each company between the 6 srw224 and the srw2024. Further more each company is on a particular IPv4 subnet. There is a RV042 (internet gateway, one internet connection for the 6 companies), which accept multiple subnets connected on the srw2024 .

Is anyone know if it's possible to use the PVE fonction or another one on the srw2024 and how to parameter this fonction in order to permit access to the RV042 internet gateway to all companies but the companies must be totaly isolated one from the other

Thank you for your help.

Schéma Réseau LEAP.jpg

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joachim Kern Fri, 01/15/2010 - 06:44

connect the customer switches directly to the rv042 (if you have more than 4 customers you can use a rv082) and configure each lan port on the rv042 in a different 'vlan' on the rv042 port configuration page.

this vlan feature acts like PVE on the rv042 itself. LAn to WAN routing works. lan port to lan port is blocked if in different rv042 vlans.

otherwise you can setup the firewall on the rv042 to block routing between subnets - but i guess some testing would be required to set up the rules (and if a customer fakes other customers ip address it could circumvent the firewall.

coroneljy Tue, 01/19/2010 - 08:17

Thank You Jokern for your answer but we don't want to connect all the clients switches to the RV042 because we think the switching capacity and the bandwith of the RV042 won't be sufficient. Further more, as far as we know, the RV042 is able to work with multiple IP subnets but it's not possible to program VLANs on the port management web interface.

Blocking the subnets routing is not satisfying because it could be easy for someone to change his IP adress and fake to belong to another client.

The question is still unanswered ? Any other solution ?

alissitz Tue, 01/19/2010 - 11:10

Hello,

A couple of thoughts.

If you do not want any of the customers to share resources / talk to each other then PVE might work.  PVE would restrict the port from talking to any other port except the uplink which is connected to the RV042.

I have not lab tested this, but it should be easy enough to do.  Go into each port that connects the switches and enable PVE and indicate which port is the uplink.

Normally PVE is not suggested for switch to switch communications when these ports are in trunking more.  PVE is an edge port feature.  In your case, you can configure each port as an access port and configure it for the different VLANs.  This would restrict each port from talking to each other.

I would assume that each customer has their own DHCP server?  If a single DHCP server is configured with a DHCP scope for each VLAN then this would be a shared resource ... meaning that all companies would need to have communications.  This poses a couple of problems.

1) PVE could not work since all the different companies would to communicate with a single port that is not the RV042.  The RV042 is not VLAN aware and is not the best solution in this design.

Another option for keeping the VLANs separate, is to exclude different VLANs from each inter-switch trunk links; this is vlan filtering.  This assumes that you have trunk links between the switches and you can limit which VLANs can communicate over each trunk link.  This would solve your problem as well since you would not allow other customer VLANs on the trunk links to other customers.

If you are sharing resources, filtering vlans will still pose a problem for shared resources.  By using the RV042 and SRW switches, you have limited the options and features, as well as the expansion abilities of your design.

I might suggest for you to reconsider your design a little.  A few suggestions (many ways solve this ...)

1) Use a 3560 series switch as the aggregation layer.  This opens a lot of flexibility and allow you to add features, security, services, shared services, etc ...

2) W/ a 3560 switch you can use full private vlans.  This would allow you to segment your network as well as allow shared resources like email and DHCP servers.  These shared resources would be placed within a community vlan.  You can keep a single IP subnet across all private vlans.  Not sure how large your network is ...

Private vlans are local to that switch, and so the RV042 would not know anything about these private vlans ... which would be fine.

By putting in a 3560 you can also configure security, DHCP services, filtering, etc ... to all of the customers.  This would be a very nice solution.  If in L3 mode, the 3560 can point to the RV042 as the uplink (default route).

As you know the 3560 also has L3 features and so this can provide a lot of solutions for multi customer / multi-tenants enviroments.  I would at the very least look to installing a 3560 in the aggregation.

3) You can use a Cisco 1800 series ISR as your router.  This router is vlan aware, has FW abilities, and can segment / route / provide DHCP / etc ... between all the 6 customers.

Using either an 1800 series ISR or a 3560 allows you a lot more flexibility, redundancy, ability to add additional services etc ... Can you or should you use both?  I would suggest evaluating this option.

I hope this was not confusing, however I would suggest to take a new look at the design and equipment being used.

Do please respond with any questions and or comments,

Andrew Lee Lissitz

coroneljy Tue, 01/19/2010 - 12:14

First, thank you Andrew for the time you spent to answer my questions.

2/ each company has his own DHCP so we don't have to manage the problems that could be generated by a common DHCP server.

3/ the reason why we chose the SRW serie is the cost. The client has a small budget so we used small business switches. We know that the RV042 doesn't manage Vlan but it manages multiple subnets which is OK for our design.

4/ we thought about a level3 switch which would have been easier to parameter than a level 2. But we saw that the PVE fonction that is not present on the SRW224 could be the solution.

5/ The problem is that we have to begin the installation of the whole system in two weeks. And before doing it we need to be certain it will work. We can't try before because the switches are directly delivered to the final client. We try to simulate a similar configuration with a SWR224 as aggregation layer instead of a SRW2024 (that we don't have any) but it doesn't work because there is no PVE fonction on the SRW224. Either nobody can't "see" nobody, either everybody sees everybody. We didn't manage that  everybody can't see everybody except the RV042 that must be seen by everybody. I hope my explainations are clear.

So to conclude, I wan't to be sure that the PVE fonction will permit to do it because the Administration Guide of the SWR2024 we found on the cisco.com site doesn't talk about the PVE fonction ( http://dl.cisco-france.com/dl.php?75c0a8c5e57cae8e ).

I really need a confirmation from someone who ever experienced this PVE fonction.

Thank you to anyone that could confirm this.

alissitz Tue, 01/19/2010 - 12:26

I better understand now.

For PVE configuration look to the SGE sereies switching as the SRW series will not perform this. 

Here is the datasheet:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9967/ps9982/data_sheet_c78-502447.html

I have done PVE on the SGE series and it works.    Would be best for you to work this in a lab ... no way for you to do this?  Can you install this new network in parallel for testing?  

HTH,

Andrew

coroneljy Tue, 01/19/2010 - 12:55

Andrew,

Why do you say that SRW will not perform PVE fonction ? I agree with you that SWR224 doesn't perform PVE but SRW2024 does and thats the reason why we choosed this switch to play the agregation layer role.

It's clearly indicated on cisco web site that SWR2024 performs PVE. I invite you to go to this page:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9967/ps9989/data_sheet_c78-502265.html

Can you tell me if the PVE of the SGE serie is the same as on the SRW2024 ?

As I tell you we can't test in lab and I don't want to buy a SWR2024 even with NFR rabate juste for testing. Further more financially speaking we don't want to spend to time doing configuration on the client site.

Sincerely

Jean-Yves CORONEL

alissitz Tue, 01/19/2010 - 13:01

Yes, my mistake ... the 2024 is different than the 224.  I was looking at the 224 and am sorry for the confusion.

There is no difference in the PVE on SGE versus the SRW2024.

HTH,

Andrew Lissitz

coroneljy Tue, 01/19/2010 - 13:16

Andrew,

Thank you for these precisions.

Can you confirm that with the PVE on the SGE you experienced can permit to achieve our goal : everyone can't see each other even if they are on the same subnet (fake ip adress) but every one can see the RV042 and the RV042 can see everybody ?

Sincerely

Jean-Yves CORONEL

alissitz Tue, 01/19/2010 - 14:00

PVE should be the same on both products. Normally PVE would be configured on edge ports and not between switches, however I do not see why there should be any issues with running the ports between switches if these ports are setup as access mode.

There is a note on page 25 or page 32 ... depending on how your browser loads that mentions"

NOTE: All ports in the same PVE group should join the same VLAN group.

Config Guide:

http://www.cisco.com/en/US/docs/switches/lan/csbms/srw2048/administration/guide/SRW-US_v10_UG_A-Web.pdf

I am not sure how to interpret this statement with respects to your suggested design.  W/ PVE you would not have separate vlans ...but only one vlan and each port could only talk to the uplink port.

This is one of the advantages to PVE is that you can have a single vlan that offers segmentation ...  so normally this makes sense, because PVE was designed to operate with a single VLAN.  For your install I am not sure of it, if you change the vlan numbers to different vlans.

If you need to have separate vlans then this should be tested first.  If you cannot test it first, then perhaps a quick call to our support team might assist further.

Here is the link and you can find the correct phone number from this link:

http://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

Kindest regards and HTH,

Andrew