cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4456
Views
60
Helpful
13
Replies

VLANs in a routed environment

kellcom
Level 1
Level 1

So this may seem like an ignorant question but I'm a bit confused...it seems to me that when you have a VLAN in a purely switched environment you can control what Endstations on those vlans can communicate with other endstations simply by using the allowed statement on the trunk port.  But when you add in a router or turn router functionality on in a switch those conventions go out the window and you have to resort to router/L3 controls e.g. access lists (based on L3/IP) to be able to enforce communications between endstations.  Am I crazy?  Why wouldn't the allowed statement be enough? Example...the core is two routers connected over a WAN.  Attached to the router is a distribution switch connected to access switches with multiple vlans behind them.  Distribution is routing and is the default gateway for the VLANs.  As long as I have VLAN 1 allowed on the trunk port which connects to the distribution switch and router (the same  config on the switch behind the other router on the other side of the WAN) I can ping any device I want.  I get that ping is based on IP/layer 3 but shouldn't the fact that none of the other VLANs are allowed across the trunk make it so the pings don't get through? What am I missing?  Routers are running BGP and so are the distribution switches.  Access switches don't have routing enabled.  Thoughts are welcome...

2 Accepted Solutions

Accepted Solutions

Not sure you still understand VLAN isolation and trunks.

Case 1

SW1 (VLANs 1, 2, 3) SW2 (VLANs 2, 3, 4)

No connections, although both switches have VLANs 2 and 3 in common, they are, other than using same VLAN IDs, different VLANs.

Case 2

SW1 (VLANs 1, 2, 3) <VLAN3:VLAN3> SW2 (VLANs 2, 3, 4)

Now the two switches are physically connected, via both using access ports in VLAN 3.  VLAN 3 is the same VLAN on both switches.  All the other VLANs, even VLAN 2, are different VLANs.

Case 3

SW1 (VLANs 1, 2, 3) <Trunk:Trunk> SW2 (VLANs 2, 3, 4)

Again the two switches are physically connected, but now using Trunk ports on both switches, using the default of allowing all VLANs.  VLANs 2 and 3 are the same VLAN on both switches.  VLANs 1 and 4 are only on SW1 and SW2, respectively.  However, if you define VLAN 1 on SW2 or VLAN 4 on SW1, they will be the same VLAN on both switches.

Case 4

SW1 (VLANs 1, 2, 3) <Trunk:don't allow VLAN 2:Trunk> SW2 (VLANs 2, 3, 4)

VLAN 2 is treated like Case 2, while all the other VLANs are like Case 3.

With switches you can, optionally, extend the same VLAN across multiple switches.  At L2, with VLANs, hosts cannot intercommunicate unless they are in the same actual VLAN.  The same VLAN number, on different switches, doesn't, alone, insure it's the same VLAN.  Also, as mentioned in my prior posting, it's possible the same VLAN, that can allow hosts to intercommunicate, might have different VLAN numbers on different switches (but a very bad, and unusual, practice).

When you add a L3 (routing device), VLANs are always different, although you might have trunks (call subinterfaces on Cisco routers)

Case 5

SW1 (VLANs 1, 2, 3) <Trunk:allow VLANs 1 and 2:Trunk> RTR <Trunk:allow VLANs 3 and 4:Trunk> SW2 (VLANs 2, 3, 4)

VLAN 3 on SW1 and VLAN 2 on SW2 are not able to communicate with anything else, but all the other VLANs can intercommunicate, and, again, VLAN 3 on the two switches are two different VLANs.

BTW, whether at L2 or L3, generally you only use the same VLAN number, on different switches, if it's truly the same L2 VLAN.  If it's not, again generally, a different VLAN ID is used, although if the purpose of a VLAN is the same, a device ID might be added.

E.g.

SW1 (VLANs 10 and 20) <trunk> SW2 (VLANs 10 and 20) <trunk> SW3 (VLANs 10 and 20)

Where VLAN 10 might be user data and VLAN 20 user VoIP

RTR1 <trunk> SW1 (VLANs 10 and 20)
RTR1 <trunk> SW2 (VLANs 10 and 20)
RTR1 <trunk> SW3 (VLANs 10 and 20)

As above can be confusing, if we assume there's just one VLAN for the same #, often better is:

RTR1 <trunk> SW1 (VLANs 110 and 120)
RTR1 <trunk> SW2 (VLANs 210 and 220)
RTR1 <trunk> SW3 (VLANs 310 and 320)

where #10 is still user data and #20 is user VoIP.

L3 switches can do all the above, and, at first, can be confusing, because they do both L2 and L3. In above, a L3 switch can replace either a L2 SW# or a L3 RTR#, or do both functions concurrently. I.e. you might have just one L3 switch that takes the place of a router and switch.

When using L3 switches, also at first, think of how you would do "whatever" using router and switch.  Keep in mind how L2 works vs. L3, especially for intercommunication.

View solution in original post

The original poster says "I was expecting to be able to (granularly) control VLAN access via the trunk allow statement". The problem is that vlans and trunks are layer 2 entities and can not provide the granular control that you want. It really helps if we think of this in terms of the hierarchical network layer model. Each layer provides a service to the layer above it and operates independently of the layers below it.

Layer 1 is the physical layer. It deals with wires and electrons on the wires and the physical connection of devices.

Layer 2 is the Data Link layer. It uses the services of layer 1 but is not at all concerned with physical attributes. Layer 2 provides connectivity between devices that are directly connected (in the same broadcast domain = in the same vlan). Vlans and Trunks are part of how the Data Link layer achieves it's functions. If there are 2 devices are in the same vlan then they can communicate directly. If there are 2 devices and each is in a different vlan then they can not communicate. If there are several switches and several vlans are present on each switch the a trunk is an efficient way of carrying traffic for the several vlans and keeping that traffic separated. But a trunk does not allow devices in one vlan to communicate with devices in a different vlan.

Layer 3 is the Network layer. It uses the services of the data link layer (vlans, trunks, etc) but is independent of those entities. The network layer allows devices in one network to communicate with devices in a different network (devices in one vlan to communicate with devices in another vlan). And if you want to control what networks can communicate with other networks then that control must take place at layer 3 - Network layer - using access lists and similar things.

 

HTH

Rick

View solution in original post

13 Replies 13

Hello,

 

not really sure I understand what you are asking, but if you turn on "ip routing" on the switch, trunking and Vlans become irrelevant on the link between the router and the distribution switch. Post the running configurations of your devices, and indicate what behavior you expect with these configurations.

Appreciate everyone's responses...configs are attached as well...

 

There are servers on VLAN 1 ip 10.1.10.50, VLAN 100 ip 192.168.100.13, VLAN 101 ip 192.168.101.13, & VLAN 102 ip 192.168.102.13

On VLAN 110,120,130 there are clients pulling ips from DHCP on Distribution switch.  Based on the VLANs allowed on their respective trunks, I would expect VLAN 1 wouldn't be able to talk to any of the servers or clients, VLAN 100 server should be able to talk to all servers and clients, VLAN 101 server should be able to talk to all clients and only server on VLAN 100, and VLAN 102 server should be able to talk to all clients and only server on VLAN 100.  BUT...everyone can talk to everyone...SO my question is, are the VLANs basically moot at this point because there is routing on distribution switch and core which is what I believe you are alluding to when you say that trunking & vlans become irrelevant which implies the only way to get the granular control is through ip access lists.  

 

 

HO-CORE-1#sho run
Building configuration...

Current configuration : 1439 bytes
!
version 12.2
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname HO-CORE-1
!
!
ip cef
no ipv6 cef
!
!
interface FastEthernet0/0
ip address 10.1.5.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.15.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
ip address 10.1.1.2 255.255.255.0
encapsulation frame-relay
frame-relay interface-dlci 301
!
interface Serial0/1
no ip address
clock rate 2000000
!
interface Ethernet1/0
ip address 192.168.13.2 255.255.255.0
duplex auto
speed auto
!
interface Ethernet1/1
ip address 10.1.10.1 255.255.255.0
duplex auto
speed auto
!
interface Ethernet1/2
no ip address
duplex auto
speed auto
!
interface Ethernet1/3
no ip address
duplex auto
speed auto
!
router bgp 5
bgp log-neighbor-changes
no synchronization
timers bgp 30 180
neighbor 10.1.1.1 remote-as 10
neighbor 10.1.5.2 remote-as 7
neighbor 10.1.10.2 remote-as 9
network 10.0.0.0
network 192.168.15.0
network 192.168.25.0
network 10.1.5.0 mask 255.255.255.0
network 192.168.30.0
network 10.1.10.0 mask 255.255.255.0
network 192.168.13.0
!
ip classless
ip route 192.168.25.0 255.255.255.0 192.168.15.2
ip route 192.168.30.0 255.255.255.0 10.1.5.2
!
ip flow-export version 9
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
!
end

***********************

Distribution#sho run
Building configuration...

Current configuration : 3033 bytes
!
version 16.3.2
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname Distribution
!
!
!
ip dhcp excluded-address 192.168.110.1 192.168.110.99
ip dhcp excluded-address 192.168.120.1 192.168.120.99
ip dhcp excluded-address 192.168.130.1 192.168.130.99
!
ip dhcp pool vPool110
network 192.168.110.0 255.255.255.0
default-router 192.168.110.1
dns-server 4.4.4.4
ip dhcp pool vPool120
network 192.168.120.0 255.255.255.0
default-router 192.168.120.1
dns-server 8.8.8.8
ip dhcp pool vPool130
network 192.168.130.0 255.255.255.0
default-router 192.168.130.1
dns-server 12.12.12.12
!
!
no ip cef
ip routing
!
no ipv6 cef
!
!
spanning-tree mode pvst
!
!
interface GigabitEthernet1/0/1
switchport trunk allowed vlan 1,10,15,20,30,100-102
switchport mode trunk
!
interface GigabitEthernet1/0/2
switchport trunk allowed vlan 10,20,30,100-101
switchport mode trunk
!
interface GigabitEthernet1/0/3
switchport trunk allowed vlan 10,20,30,100-102
switchport mode trunk
!
interface GigabitEthernet1/0/4
switchport trunk allowed vlan 10,20,30,100,102
switchport mode trunk
!
interface GigabitEthernet1/0/5
!
interface GigabitEthernet1/0/6
!
interface GigabitEthernet1/0/7
!
interface GigabitEthernet1/0/8
!
interface GigabitEthernet1/0/9
!
interface GigabitEthernet1/0/10
!
interface GigabitEthernet1/0/11
!
interface GigabitEthernet1/0/12
!
interface GigabitEthernet1/0/13
!
interface GigabitEthernet1/0/14
!
interface GigabitEthernet1/0/15
!
interface GigabitEthernet1/0/16
!
interface GigabitEthernet1/0/17
!
interface GigabitEthernet1/0/18
!
interface GigabitEthernet1/0/19
!
interface GigabitEthernet1/0/20
!
interface GigabitEthernet1/0/21
!
interface GigabitEthernet1/0/22
!
interface GigabitEthernet1/0/23
!
interface GigabitEthernet1/0/24
switchport trunk allowed vlan 1
switchport mode trunk
!
interface GigabitEthernet1/1/1
!
interface GigabitEthernet1/1/2
!
interface GigabitEthernet1/1/3
!
interface GigabitEthernet1/1/4
!
interface Vlan1
ip address 10.1.10.2 255.255.255.0
!
interface Vlan10
mac-address 00e0.8fac.9301
ip address 192.168.110.1 255.255.255.0
!
interface Vlan20
mac-address 00e0.8fac.9302
ip address 192.168.120.1 255.255.255.0
!
interface Vlan30
mac-address 00e0.8fac.9303
ip address 192.168.130.1 255.255.255.0
!
interface Vlan100
mac-address 00e0.8fac.9304
ip address 192.168.100.1 255.255.255.0
!
interface Vlan101
mac-address 00e0.8fac.9305
ip address 192.168.101.1 255.255.255.0
!
interface Vlan102
mac-address 00e0.8fac.9306
ip address 192.168.102.1 255.255.255.0
!
router bgp 9
bgp log-neighbor-changes
no synchronization
neighbor 10.1.10.1 remote-as 5
network 192.168.110.0
network 192.168.99.0
network 192.168.120.0
network 192.168.130.0
network 192.168.100.0
network 192.168.101.0
network 192.168.102.0
!
router rip
!
ip default-gateway 10.1.10.1
ip classless
!
ip flow-export version 9
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
end

Distribution#

*****************************

Floor1#sho run
Building configuration...

Current configuration : 2076 bytes
!
version 12.2(37)SE1
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
no service dhcp
!
hostname Floor1
!
!
spanning-tree mode pvst
!
!
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/2
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/3
switchport access vlan 20
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/4
switchport access vlan 20
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/5
switchport access vlan 30
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/6
switchport access vlan 30
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/7
!
interface FastEthernet0/8
!
interface FastEthernet0/9
!
interface FastEthernet0/10
!
interface FastEthernet0/11
!
interface FastEthernet0/12
!
interface FastEthernet0/13
switchport access vlan 101
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/14
!
interface FastEthernet0/15
!
interface FastEthernet0/16
!
interface FastEthernet0/17
!
interface FastEthernet0/18
!
interface FastEthernet0/19
!
interface FastEthernet0/20
!
interface FastEthernet0/21
!
interface FastEthernet0/22
!
interface FastEthernet0/23
!
interface FastEthernet0/24
!
interface GigabitEthernet0/1
switchport trunk allowed vlan 10,20,30,100-101
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/2
!
interface Vlan1
ip address 10.1.10.5 255.255.255.0
!
interface Vlan10
mac-address 00e0.8f03.4c01
no ip address
!
interface Vlan20
mac-address 00e0.8f03.4c02
no ip address
!
interface Vlan30
mac-address 00e0.8f03.4c03
no ip address
!
interface Vlan101
mac-address 00e0.8f03.4c04
no ip address
!
ip default-gateway 10.1.10.2
ip classless
!
ip flow-export version 9
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
end

Floor1#

**************************************

Floor2#sho run
Building configuration...

Current configuration : 2060 bytes
!
version 12.2(37)SE1
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname Floor2
!
!
spanning-tree mode pvst
!
!
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/2
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/3
switchport access vlan 20
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/4
switchport access vlan 20
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/5
switchport access vlan 30
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/6
switchport access vlan 30
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/7
!
interface FastEthernet0/8
!
interface FastEthernet0/9
!
interface FastEthernet0/10
!
interface FastEthernet0/11
!
interface FastEthernet0/12
!
interface FastEthernet0/13
switchport access vlan 100
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/14
!
interface FastEthernet0/15
!
interface FastEthernet0/16
!
interface FastEthernet0/17
!
interface FastEthernet0/18
!
interface FastEthernet0/19
!
interface FastEthernet0/20
!
interface FastEthernet0/21
!
interface FastEthernet0/22
!
interface FastEthernet0/23
!
interface FastEthernet0/24
!
interface GigabitEthernet0/1
switchport trunk allowed vlan 10,20,30,100-103
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/2
!
interface Vlan1
ip address 10.1.10.6 255.255.255.0
!
interface Vlan10
mac-address 00e0.f9ed.a101
no ip address
!
interface Vlan20
mac-address 00e0.f9ed.a102
no ip address
!
interface Vlan30
mac-address 00e0.f9ed.a103
no ip address
!
interface Vlan100
mac-address 00e0.f9ed.a104
no ip address
!
ip default-gateway 10.1.10.2
ip classless
!
ip flow-export version 9
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
end

Floor2#

**********************************

Floor3#sho run
Building configuration...

Current configuration : 2084 bytes
!
version 12.2(37)SE1
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname Floor3
!
!
spanning-tree mode pvst
!
!
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/2
switchport access vlan 10
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/3
switchport access vlan 20
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/4
switchport access vlan 20
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/5
switchport access vlan 30
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/6
switchport access vlan 30
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/7
!
interface FastEthernet0/8
!
interface FastEthernet0/9
!
interface FastEthernet0/10
!
interface FastEthernet0/11
!
interface FastEthernet0/12
!
interface FastEthernet0/13
switchport access vlan 102
switchport mode access
switchport nonegotiate
!
interface FastEthernet0/14
!
interface FastEthernet0/15
!
interface FastEthernet0/16
!
interface FastEthernet0/17
!
interface FastEthernet0/18
!
interface FastEthernet0/19
!
interface FastEthernet0/20
!
interface FastEthernet0/21
!
interface FastEthernet0/22
!
interface FastEthernet0/23
!
interface FastEthernet0/24
!
interface GigabitEthernet0/1
switchport trunk allowed vlan 10,20,30,100,102
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet0/2
!
interface Vlan1
ip address 10.1.10.7 255.255.255.0
!
interface Vlan10
mac-address 00d0.58c1.2101
no ip address
!
interface Vlan20
mac-address 00d0.58c1.2102
no ip address
!
interface Vlan30
mac-address 00d0.58c1.2103
no ip address
!
interface Vlan102
mac-address 00d0.58c1.2104
ip address 192.168.99.7 255.255.255.0
!
ip default-gateway 10.1.10.2
ip classless
!
ip flow-export version 9
!
!
line con 0
!
line aux 0
!
line vty 0 4
login
!
!
end

Floor3#

Hello,

 

I still don't understand what you are asking. Your distribution switches have 'ip routing' enabled, but no routing (static or dynamic) configured ? What are you after ? Maybe it helps if you post a topology of your network, and then indicate what behavior you are seeing, and what you are expecting to see. Any "inter-Vlan" access can only be controlled by later 3 access lists. If there is no layer 3 device, only devices connected to the same Vlan can communicate.

The original poster asks 2 related questions: 

"are the VLANs basically moot at this point because there is routing on distribution switch and core" 

"the only way to get the granular control is through ip access lists. " 

vlans and trunks are important and controlling when we are dealing with layer 2. They form the foundation for processing at layer 3 but are no longer the main control on forwarding traffic. As long as a vlan (and its associated subnet) are locally connected on a layer 3 routing device (router or switch) then the hosts in that vlan can communicate with hosts in other locally connected vlans/subnets (and with hosts in other subnets for which the routing device has routing information - static routes or dynamically learned routes).  In the layer 3 environment the control over who can communicate with who is based on ip access lists.

HTH

Rick

Topo attached.  Distribution Switch is running BGP.  I think I have this figured out thanks to everyone's comments and some testing...I was expecting to be able to (granularly) control VLAN access via the trunk allow statement but it appears this statement is such that it only allows or disallows all traffic from that particular VLAN to traverse it's own trunk.  There is no mechanism or technique that gives you the granularity to say only let VLAN x to talk to VLAN y (which lives outside of x's switch) unless you use an access list.  I was thinking you could do this by only allowing x & y on their respective trunks but it doesn't seem to work that way.  Once you allow x on the trunk, then VLAN y,z,a,b,c regardless of where they live can all talk to x unless you allow/disallow them on their own trunks-interim/transit trunks don't seem to matter.  In diagram Access Switch Floor 1 (left bottom)... I can't stop VLAN 100 from talking to VLAN 10 unless I don't allow VLAN 10 on the trunk (or not allow 100 on it's own trunk) which effectively shuts VLAN 10 off from the rest of the world-except whoever is on VLAN 10 on the same switch.  It makes me think that once a packet passes through the route plane the VLAN tag is not used/recognized so VLAN 15 which is on the other side of the network can talk to VLAN 10 without any problem regardless of whether VLAN 15 is in the allowed list on VLAN 10's trunk port or not.  I assumed that the tag would matter such that if VLAN 15 was not explicitly allowed on VLAN 10's trunkport they wouldn't be able to communicate but that appears to not be the case.  VLAN any can talk to VLAN 10 as long as VLAN 10 is allowed on it's own connected trunk port-unless access lists are applied.

Topo cutoff bottom...VLAN 10,20, 30 with networks 192.168.110.0, 192.168.120.0, 192.168.130.0 respectively all live on all 3 access switches at the bottom.  

Not sure you still understand VLAN isolation and trunks.

Case 1

SW1 (VLANs 1, 2, 3) SW2 (VLANs 2, 3, 4)

No connections, although both switches have VLANs 2 and 3 in common, they are, other than using same VLAN IDs, different VLANs.

Case 2

SW1 (VLANs 1, 2, 3) <VLAN3:VLAN3> SW2 (VLANs 2, 3, 4)

Now the two switches are physically connected, via both using access ports in VLAN 3.  VLAN 3 is the same VLAN on both switches.  All the other VLANs, even VLAN 2, are different VLANs.

Case 3

SW1 (VLANs 1, 2, 3) <Trunk:Trunk> SW2 (VLANs 2, 3, 4)

Again the two switches are physically connected, but now using Trunk ports on both switches, using the default of allowing all VLANs.  VLANs 2 and 3 are the same VLAN on both switches.  VLANs 1 and 4 are only on SW1 and SW2, respectively.  However, if you define VLAN 1 on SW2 or VLAN 4 on SW1, they will be the same VLAN on both switches.

Case 4

SW1 (VLANs 1, 2, 3) <Trunk:don't allow VLAN 2:Trunk> SW2 (VLANs 2, 3, 4)

VLAN 2 is treated like Case 2, while all the other VLANs are like Case 3.

With switches you can, optionally, extend the same VLAN across multiple switches.  At L2, with VLANs, hosts cannot intercommunicate unless they are in the same actual VLAN.  The same VLAN number, on different switches, doesn't, alone, insure it's the same VLAN.  Also, as mentioned in my prior posting, it's possible the same VLAN, that can allow hosts to intercommunicate, might have different VLAN numbers on different switches (but a very bad, and unusual, practice).

When you add a L3 (routing device), VLANs are always different, although you might have trunks (call subinterfaces on Cisco routers)

Case 5

SW1 (VLANs 1, 2, 3) <Trunk:allow VLANs 1 and 2:Trunk> RTR <Trunk:allow VLANs 3 and 4:Trunk> SW2 (VLANs 2, 3, 4)

VLAN 3 on SW1 and VLAN 2 on SW2 are not able to communicate with anything else, but all the other VLANs can intercommunicate, and, again, VLAN 3 on the two switches are two different VLANs.

BTW, whether at L2 or L3, generally you only use the same VLAN number, on different switches, if it's truly the same L2 VLAN.  If it's not, again generally, a different VLAN ID is used, although if the purpose of a VLAN is the same, a device ID might be added.

E.g.

SW1 (VLANs 10 and 20) <trunk> SW2 (VLANs 10 and 20) <trunk> SW3 (VLANs 10 and 20)

Where VLAN 10 might be user data and VLAN 20 user VoIP

RTR1 <trunk> SW1 (VLANs 10 and 20)
RTR1 <trunk> SW2 (VLANs 10 and 20)
RTR1 <trunk> SW3 (VLANs 10 and 20)

As above can be confusing, if we assume there's just one VLAN for the same #, often better is:

RTR1 <trunk> SW1 (VLANs 110 and 120)
RTR1 <trunk> SW2 (VLANs 210 and 220)
RTR1 <trunk> SW3 (VLANs 310 and 320)

where #10 is still user data and #20 is user VoIP.

L3 switches can do all the above, and, at first, can be confusing, because they do both L2 and L3. In above, a L3 switch can replace either a L2 SW# or a L3 RTR#, or do both functions concurrently. I.e. you might have just one L3 switch that takes the place of a router and switch.

When using L3 switches, also at first, think of how you would do "whatever" using router and switch.  Keep in mind how L2 works vs. L3, especially for intercommunication.

The original poster says "I was expecting to be able to (granularly) control VLAN access via the trunk allow statement". The problem is that vlans and trunks are layer 2 entities and can not provide the granular control that you want. It really helps if we think of this in terms of the hierarchical network layer model. Each layer provides a service to the layer above it and operates independently of the layers below it.

Layer 1 is the physical layer. It deals with wires and electrons on the wires and the physical connection of devices.

Layer 2 is the Data Link layer. It uses the services of layer 1 but is not at all concerned with physical attributes. Layer 2 provides connectivity between devices that are directly connected (in the same broadcast domain = in the same vlan). Vlans and Trunks are part of how the Data Link layer achieves it's functions. If there are 2 devices are in the same vlan then they can communicate directly. If there are 2 devices and each is in a different vlan then they can not communicate. If there are several switches and several vlans are present on each switch the a trunk is an efficient way of carrying traffic for the several vlans and keeping that traffic separated. But a trunk does not allow devices in one vlan to communicate with devices in a different vlan.

Layer 3 is the Network layer. It uses the services of the data link layer (vlans, trunks, etc) but is independent of those entities. The network layer allows devices in one network to communicate with devices in a different network (devices in one vlan to communicate with devices in another vlan). And if you want to control what networks can communicate with other networks then that control must take place at layer 3 - Network layer - using access lists and similar things.

 

HTH

Rick

Super helpful. Definitely understand much better now.  Really appreciate everyone's comments and help.  Thanks!

I am glad that our explanations have helped you understand better.  Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick

Hello

Its all to do with the addressing, if hosts reside within the same network range then no routing is required as all traffic is switched at Layer 2, The trunks are part of the layer 2 switched network so if you have hosts in the same vlan but on two different switch's then without the vlan being allowed on the trunk hosts in the same network wont be able to reach each other between switches, host in the same vlan on the same switch dont need these trunks so they will still be able to communicate.

 

When hosts are NOT in the name network range then a router is required to be able to lookup the destination address and forward that traffic between the different networks (vlans) and this is applicable if hosts in these vlans reside on the same switch or not.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

The original poster has a basic misunderstanding. He says "you can control what Endstations on those vlans can communicate with other endstations simply by using the allowed statement on the trunk port." That is not true. In a "purely switched environment" a device can communicate only with devices in its own vlan. To communicate with a device in a different vlan you need a layer 3 device (a router or a switch with ip routing enabled) doing forwarding between vlans.

It is true that whether a vlan is on the allowed statement for a trunk does control whether a device can communicate with a device in the same vlan on a different switch. But to communicate between vlans does require some device doing layer 3 forwarding (other wise known as routing).

HTH

Rick

Joseph W. Doherty
Hall of Fame
Hall of Fame

Indeed, your confusion appears to stem from a misunderstanding of VLANs and L3 routing.

Generally a LAN is a "shared wire".  Devices connected to the same shared wire can, physically, directly communicate with each other.  If you want to add extra devices, either they need to tap into the existing wire, or they need to connect to a wire that is in turn connected to another existing wire.

VLANs allow us to have logical shared wires on the same device (often a switch) or across a wired connection between devices (on Cisco switches, configured as a trunk).

As long as you don't physically interconnect LANs or VLANs, devices on those, because they are separated cannot communicate with each other.

Once you physically interconnect LANs or VLANs, devices can physically communicate.  BTW, it's possible to interconnect Cisco switch with VLAN X access port to a Cisco switch VLAN Y port.  Effectively you've joined the two VLANs into one VLAN (also something you normally should very much avoid).

Another way to interconnect LANs, or VLANs, is use a L3 routing device.  This will automatically block some traffic between LANs/VLANs, e.g. multicast and broadcasts, and require certain requirements for even unicast to transit between the LANs/VLANs.  For the latter, a the L3 device doing routing either needs to be known as a gateway to other hosts within the LAN/VLAN or act as a proxy for off local LAN/VLAN network traffic.  Further, for networks not directly connected to a L3 routing device, that device needs to also know how to get to them (such information is provided by static route statements and/or a dynamic routing protocol).

I haven't reviewed your later posted physical device configs, but you really should first understand the above, to understand why, or why not, something is working.