Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

VLAN based Hub and Spoke

Hi Friends,

I have 3 sites A (hub), B (spoke) and C (spoke).

Each site has one switche - Cisco 3560

Site A is connected to B and C separately, (site B and C are not connected to each other)

Site A is also connected to a server that needs to be accessed from all three sites.

There will be different VLANs on each site and all of them need to access the server connected to site A.

VLANs need not talk with each other - only with server VLAN.

My plan:

Create Trunks  between sites.

Assign different VLANs to each client subnet connecting at different sites A, B and C.

Create ACLs to stop unneccessary VLAN communication

However, this method does not look scalable - I was thinking of using 'q in q' somehow... please give me some suggestions on what will be the most feasible options.

thank you very much

regards

NK

6 REPLIES
Hall of Fame Super Blue

Re: VLAN based Hub and Spoke

NK

If you can have separate vlans at each site then i would make the connections between the 3560 switches routed connections rather than trunks ie.

Site A

=====

int gi0/1 <-- to Site B

no switchport

ip address 192.168.5.1 255.255.255.252

int gi0/2 <-- to Site C

no switchport

ip address 192.168.5.5 255.255.255.252

Site B

=====

int gi0/1

no switchport

ip address 192.168.5.2 255.255.255.252

Site C

=====

int gi0/1

no switchport

ip address 192.168.5.6 255.255.255.252

this way you do not need to run STP across the links between sites and you can simply route from each site to the servers.

Jon

New Member

Re: VLAN based Hub and Spoke

Jon,

i wanted to have a plain layer 2 network without any routing and that is why decided to use trunks.

In your example case what would be the configuration on spokes B/C for clients?

I am not working on cisco full time so my questions might be very basic - sorry for that..

thank you

NK

Hall of Fame Super Blue

Re: VLAN based Hub and Spoke

NK

If you want L2 then do what you were proposing. I'm not entirely sure why you think it's not scalable and certainly Q-in-Q wouldn't help between 3 sites.

You asked for feasible solutions and that's why I suggested routing because it is better, in my opinion, to route rather than switch. If you don't need the same vlan at all sites routing is the best way to go but like i say if you don't want to then don't.

If you have the advanced IP services images on your 3560 switches then you can run a routing protocol between the 3 switches, otherwise you could run RIP or use static routing. Each 3560 would do the inter-vlan routing for it's own vlans and then you would route between sites.

However as i say, if what you really want is to use  L2 which i get the impression you do then just stick with trunk links.

Jon

Hall of Fame Super Blue

Re: VLAN based Hub and Spoke

NK

Apologies for the rather terse last response, i was in a bit of a hurry.

If each site has it's own vlans then there is no benefit to running trunks because you do not need to send traffic from the same vlans across sites. The server vlan needs to be accessible from all sites but you can route to this, you don't need to have the server vlan in all sites.

If you summarise your addressing in each sites a single static route could be used per site eg.

Site A = 172.16.0.0/24 -> 172.16.7.0/24  -> summary 172.16.0.0 255.255.248.0 or 172.16.0.0/21

Site B = 172.16.8.0/24 -> 172.16.15.0/24 -> 172.16.4.0 255.255.255.248 172.16.8.0/21

Site B = 172.16.16.0/24 -> 172.16.23.0/24 -> 172.16.16.0 255.255.255.248  172.16.16.0/21

note you want to leave spare subnets in each site summarised range for future growth so you can allocate more /24's to each site and use a larger summary address if you want.

Then each 3560 on each site would be responsible for routing that sites vlans. So on each 3560 you would have the relevant vlans in the vlan database and the relevant L3 vlan interfaces.

Finally you need to add a static route to the switches eg.

Site A switch

==========

ip route 172.16.8.0 255.255.248.0  192.168.5.2  <-- note 192.168.5.2 is used from my previous thread as are the rest of the next-hops

ip route 172.16.16.0 255.255.248.0 192.168.5.6

Site B switch

==========

ip route 172.16.0.0 255.255.248.0 192.168.5.1

Site C switch

==========

ip route 172.16.0.0 255.255.248.0 192.168.5.1

Jon

New Member

Re: VLAN based Hub and Spoke

Jon,

No worries, I didn't notice it - until you pointed it out

Actually the reason I want L2 is because there will be multicast traffic (delay sensitive) in this network. I presume with the network configured to route - I will have to learn multicast routes - which may add to overall delay.

Thank you for your valuable suggestions though.

Cheers

NK

Cisco Employee

Re: VLAN based Hub and Spoke

Hello NK,

Based on your description of the network and your requirements, if you need to communicate between the users on different VLANs and the server VLAN, you do need to have routing enabled somewhere. The big question will be where you want to do the routing. One option would be to do it at individual sites which makes your design simple and scalable. You can configure dynamic routing protocols between the sites and all routes will be synchronized. If you decide that all routing should be done in site A (hub), then you need to trunk all the VLANs to the Site A and then have a router/switch that has enough juce to route/handle traffic from multiple sites. But in either case, you do need routing somewhere.

As far as your requirement of multicast traffic is concerned, you can configure multicast routing at each site. Using multicast routing will help you control traffic over the inter-site links as the routing protocol will build the tree and forward traffic only if there is a client across the link. On the other hand, some switches treat multicast traffic as broadcast and send it across all the ports creating traffic floods.

Hope this helps you choose the right design.

Regards,

NT

1340
Views
17
Helpful
6
Replies
CreatePlease to create content