01-02-2020 06:16 AM
How do I do Routing between selective VLANs?
Say if there are 3 VLANs 10,20 and 30, and if I want to enable Routing between 10 and 30 and not between others, then how do I do it?
Consider that the VLANs are configured on the L3 Core switch and VLAN information synchronized to the Access Switches. Is there a specific command that I could configure on the L3 Switch to achieve this ?
Solved! Go to Solution.
01-02-2020 07:47 AM
Have you considered using an access list that suites your specific needs?
The example below blocks all traffic destined to vlan 20.
Switch#show running-config ! no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname Switch ! ! ip routing ! ! no ip domain-lookup ! ! spanning-tree mode pvst ! ! interface FastEthernet0/1 switchport access vlan 10 switchport mode access switchport nonegotiate ! interface FastEthernet0/2 switchport access vlan 20 switchport mode access switchport nonegotiate ! interface FastEthernet0/3 switchport access vlan 30 switchport mode access switchport nonegotiate ! . <output omitted> . ! interface Vlan1 no ip address shutdown ! interface Vlan10 mac-address 0060.5c24.1901 ip address 10.0.0.1 255.255.255.0 ! interface Vlan20 mac-address 0060.5c24.1902 ip address 20.0.0.1 255.255.255.0 ip access-group NO_20 out ! interface Vlan30 mac-address 0060.5c24.1903 ip address 30.0.0.1 255.255.255.0 ! ip classless ! ip flow-export version 9 ! ! ip access-list extended NO_20 deny ip any 20.0.0.0 0.0.0.255 permit ip any any ! ! ! line con 0 ! line aux 0 ! line vty 0 4 login ! ! ! end
01-02-2020 07:47 AM
Have you considered using an access list that suites your specific needs?
The example below blocks all traffic destined to vlan 20.
Switch#show running-config ! no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname Switch ! ! ip routing ! ! no ip domain-lookup ! ! spanning-tree mode pvst ! ! interface FastEthernet0/1 switchport access vlan 10 switchport mode access switchport nonegotiate ! interface FastEthernet0/2 switchport access vlan 20 switchport mode access switchport nonegotiate ! interface FastEthernet0/3 switchport access vlan 30 switchport mode access switchport nonegotiate ! . <output omitted> . ! interface Vlan1 no ip address shutdown ! interface Vlan10 mac-address 0060.5c24.1901 ip address 10.0.0.1 255.255.255.0 ! interface Vlan20 mac-address 0060.5c24.1902 ip address 20.0.0.1 255.255.255.0 ip access-group NO_20 out ! interface Vlan30 mac-address 0060.5c24.1903 ip address 30.0.0.1 255.255.255.0 ! ip classless ! ip flow-export version 9 ! ! ip access-list extended NO_20 deny ip any 20.0.0.0 0.0.0.255 permit ip any any ! ! ! line con 0 ! line aux 0 ! line vty 0 4 login ! ! ! end
01-02-2020 10:32 PM
Thanks for the Solution. It's working! Thus, basically to enable Routing betwwen certain VLANs, I need to enable IP Routing and then use ACL to block selective VLANs.
Just need one clarification on the ACL part, you had created an Extended ACL to block traffic from any source trying to access 20.0.0.0 Network and applied it on the SVI of VLAN20 in outward direction. What is the difference between these commands in terms of direction in/out?
01-03-2020 02:50 AM
Hi, glad you found it useful!
Each interface can only have a single ACL applied to it in any direction, one inbound and/or one outbound.
The direction you will choose to apply the access list is in large dependent on the topology itself and way traffic flows through it,
as well as the how and what traffic you, the admin, decide which traffic to block or permit and where in said topology.
A few rules of thumb:
Standard ACL's are best applied as close to the destination as possible. The reason being they only match on the source IP address thus blocking any traffic that matches a certain entry in the ACL and that may result in blocking of entire networks.
Extended ACL's are able to match on a plethora of properties (i.e. source / destination IP addresses, source / dest. port & L3 Protocols). Because of that level of granularity available to us we can afford (and best practice suggests that we do) to place the ACL as close to the source as possible. Imagine being routed throughout a large network only to arrive at the destination and eventually be blocked, a waste of resources.
As for the direction application of the ACL, this again ties back to the way the topology is but largely this is how this works;
Inbound ACLs are check when traffic tries to enter an interface (whether a virtual or physical one) and before the packet has been processed by the forwarding plane. Traffic that matches a permit statement and manages to get through an inbound ACL (assuming there is one) gets processed and routed to the appropriate egress interface it is at this point (post routing) that the traffic is checked against an outbound ACL, right before it exists the interface (again assuming one is applied).
You can see how this can take up unnecessary resources (processing and routing of the packet only to have it eventually dropped), which is why it is sometimes preferable to match (and drop) on an inbound ACL, but there are situations and constraints that will prevent you from doing so (remember one ACL per-direction per-interface).
I hope this answered your question.
Cheers;
01-02-2020 10:05 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide