In this article, I will work with a (I think common) topology where we have switches in two layers (and not the recommended three). There is a core, which is an L3 switch (or two for redundancy) that performs actual inter-VLAN routing. The second layer is access, to which all devices are connected (stations, in this case also servers, printers, etc.). All switches in the access layer are connected to the core, these connections are configured as trunks and we use VLAN Trunking Protocol (VTP), so we have the same VLANs on all switches.
Note: Similarly, you can also use a setup where we don't use an L3 switch, but a router. Basic information is in the article VLAN - Virtual Local Area Network.
Enabling routing between VLANs
By default, the switch is in L2 switching mode. If we want to use the L3 feature IP routing, we need to enable it.
SWITCH(config)#ip routing
We don't need to use any routing protocol because all routing takes place on one device. Cisco IOS automatically inserts directly connected interfaces into the routing table. If routing is enabled, IOS routes according to entries in the routing table, which are static routes and directly connected interfaces.
This is the advantage of inter-VLAN routing, that almost no configuration is needed for basic functionality. VLAN interfaces on the core switch are directly connected interfaces, between which routing is performed automatically. We only need to create a VLAN interface for VLANs that we want to route, and set its IP address. The IP address is necessary anyway because it serves as the gateway for the given subnet.
The following example creates a VLAN interface for VLAN 100, which has subnet 10.0.1.0/24 and we want the gateway address to be 10.0.1.1. VLAN 100 is already created.
SWITCH(config)#interface vlan 100 SWITCH(config-if)#ip address 10.0.1.1 255.255.255.0 // entering IP address along with the mask that determines the subnet SWITCH(config-if)#no shutdown // default state of the interface is off
It's also advisable to set the default gateway if we want to communicate, for example, to the internet, so the router knows where to send traffic that doesn't belong to any of its VLANs. There are several configuration options, but the first option is only for completeness, we can't use it!
SWITCH(config)#ip default-gateway 10.0.1.250 // can be used only if routing is not enabled SWITCH(config)#ip default-network 10.0.1.0 // sets the default network when using routing SWITCH(config)#ip route 0.0.0.0 0.0.0.0 10.0.1.250 // most common method, I create an entry directly in the routing table
Just as a note, I'll mention a useful thing here. If we've divided the original single network into VLANs and were using one DHCP server, we can still continue using one server. On the server, we create several pools (one for each subnet). And on the switch, we configure DHCP Relay Agent for the given VLANs, which forwards broadcast requests for IP address assignment using unicast to the specified server.
SWITCH(config-if)#ip helper-address 10.0.1.10
Limiting routing and non-routed VLANs
I think there can be two situations if we don't want to route everything:
- non-routed VLAN - we want to have an isolated VLAN, completely non-routed with other VLANs, either functioning as a closed network or further connecting it using a firewall or other GW
- limitedly routed VLAN - we want one VLAN to be able to communicate only with some others, or to allow only certain communication
Non-routed VLAN
From the previous chapter, it's clear how easily we can create an isolated VLAN. It's enough if its VLAN interface doesn't have an IP address assigned (it doesn't have to exist at all or can be shutdown). Such a VLAN doesn't participate in the routing process. We need to have an IP address on the VLAN for several reasons, for example when we want to access the switch in this VLAN (its CLI or web interface) or when we want to use IP address assignment from a DHCP server on the switch (to this VLAN). But after thinking about it, we can probably always do without the VLAN we don't want to route having an address.
The second option is a bit more complicated and involves creating an ACL. This is discussed in the next chapter.
Limitedly routed VLAN using ACL
If we want some VLAN to be routed (able to communicate) only with some others (and not with all). Or we want to specify communication between VLANs even more (or completely prohibit it). Then we can use Access Control List (ACL). And we apply these ACLs to VLAN interfaces on the router (in our case, the core switch), these ACLs are called Router ACLs.
Note: Another option is to use VLAN ACLs (VACLs), also known as VLAN maps (vlan access-map), which apply not only to routed traffic (like Router ACLs) but also to bridged (switched) traffic within the VLAN, i.e., to all packets. They have certain advantages, but also disadvantages. I don't cover them in this article.
A detailed (I hope) description of ACLs is in the article Cisco IOS 8 - Access Control List, so I won't discuss creating ACLs here. But I'll try to explain in detail applying ACLs to interfaces, because I didn't understand it for a long time. If we consider port ACLs, which are applied to some port, the situation is relatively simple. In the article about ACLs, there's a schematic diagram that hopefully clearly shows that we look at communication from the router's perspective, and if we want to deal with incoming communication to the port (to the router), we apply in and if outgoing, then out.
Applying ACL to a port
The following image similarly illustrates the situation. Computer X is connected to port 1. Server Y is connected to port 47 of the switch. If we apply an ACL to port 1 as incoming, we're dealing with communication that leaves station X and is directed (not necessarily only to it) to server Y. In that case, the source addresses are from station X (S=X) and the destination addresses are from server Y (D=Y). Other variants are shown in the image.
Applying ACL to a VLAN
If we transfer the situation to our L3 core switch, the situation is the same, but I think it requires more serious consideration. We do apply the ACL to the VLAN interface, but we don't look at directions from the VLAN's perspective, but from the switch's perspective (or its routing process - VLAN interface). As if the VLAN was outside the switch and everything from it entered the router through the VLAN interface to which we apply the ACL. When we apply an ACL as incoming to a VLAN, it deals with communication that leaves this VLAN and enters the routing process (into the interface). I've tried to schematically depict the situation in the following image.
Choosing ACL and direction
Cisco provides only one general recommendation:
- Apply standard ACL close to the destination as out (rules contain only source addresses, so we limit what enters the destination)
- Apply extended ACL close to the source as in (rules contain both source and destination addresses, we limit traffic leaving the source, i.e., before it's processed by the routing process)
In practice, we have the option to apply ACL at the source or at the destination and apply either the in direction, the out direction, or both in and out. In case we're controlling traffic at the port level, we also need to be aware of which side of the communication (source, destination) we're setting the port to.
For interVLAN routing, sometimes a standard ACL may be sufficient, but we'll probably more often use an extended ACL. Whether we set it in, out or both together needs to be carefully considered. Most communication (TCP protocol) needs to establish a connection, so when we limit only one direction, the connection doesn't establish, and communication doesn't occur. But certain communication is one-way (typically UDP protocol).
If we apply an ACL as incoming at the source VLAN, it's enough to set it only on one VLAN (the source one and we limit who it can communicate with). If we wanted to set it at the destination, we'd have to set it at all destinations to which the source VLAN must not communicate.
A small summary of how we can apply ACLs:
- on in at the restricted VLAN - source is the restricted VLAN, destination we either allow or deny, we control what can leave the VLAN
- on out at the restricted VLAN - destination is the restricted VLAN, we control what can enter it
- on both in and out at the restricted VLAN - destination and source in both variants, we prevent data entry and exit to the given VLAN
- on out at the destination VLAN - in some cases we may need to apply ACL also at destination VLANs, for example we want all VLANs to be able to communicate only with one (e.g., with servers) and not among themselves
Usage example
I'll try a more complex example. Let's take the situation from the previous image, where we have VLAN 100, VLAN 200, and we'll add VLAN 300. We want VLAN 100 to communicate with VLAN 200 and VLAN 300, but VLAN 300 to communicate only with VLAN 100, same as VLAN 200. In other words, full routing where VLAN 300 is restricted to communication with VLAN 100 only.
SWITCH(config)#ip routing SWITCH(config)#interface vlan 100 SWITCH(config-if)#ip address 10.0.1.1 255.255.255.0 SWITCH(config-if)#no shutdown SWITCH(config)#interface vlan 200 SWITCH(config-if)#ip address 10.0.2.1 255.255.255.0 SWITCH(config-if)#no shutdown SWITCH(config)#interface vlan 300 SWITCH(config-if)#ip address 10.0.3.1 255.255.255.0 SWITCH(config-if)#no shutdown SWITCH(config)#ip access-list extended vlan300in SWITCH(config-ext-nacl)#permit ip 10.0.3.0 0.0.0.255 10.0.1.0 0.0.0.255 SWITCH(config)#interface vlan 300 SWITCH(config-if)#ip access-group vlan300in in
The second example shows the possibility of isolating one VLAN.
SWITCH(config)#ip access-list extended vlan300 SWITCH(config-ext-nacl)#deny ip any any SWITCH(config)#interface vlan 300 SWITCH(config-if)#ip access-group vlan300 in SWITCH(config-if)#ip access-group vlan300 out
Ten popis v malém shrnutí je IMHO poněkud zmatený. Access-list in by měl řídit, co do VLAN může vstoupit. Ať už z fyzických portů ve VLAN nebo z jiného L3 rozhraní (třeba i jiné VLAN).
Takže komunikace mezi VLAN 100 a 200 by vypadala patrně následovně:
paket z portu ve VLAN100 -> Vlan100 access-list in -> routování -> Vlan100 access-list out -> Vlan200 access-list in ->Vlan200 access-list out -> odchozí port ve VLAN200.
Ale nezkoušel jsem to, takže můžu kecat, ale takové použití se mi zdá nejlogičtější.
respond to [1]davro: Moc se ve vašem popisu nevyznám, ale jsem si jist, že je to tak, jak popisuji v článku, a ne jak píšete vy. Snad každý to musí pochopit z obrázku a ještě jsem se to snažil podrobně popsat.
Hlavní věc je, že Router ACL, je něco jiného než Port ACL, a uplatňuje se pouze na routovaný provoz. Směr in je to co odchází z VLANy, vstupuje do VLAN interfacu (na který se ACL aplikovalo) a tedy vstupuje do routovacího procesu.
Jo a v rámci jedné VLAN se neprovádí routování, ale switchování.
Zkousel sem priklad pouziti nastavit v packet traceru , a nefungovalo me to , (pouzival sem tam L3 switch 3560-24PS) , slo by ten postup napsat kompletni , vcetne toho co ma byt nastaveno na PC ktere se maji pripojit do jednotlivych vlan .
SWITCH(config)#ip routing
SWITCH(config)#interface vlan 100
SWITCH(config-if)#ip address 10.0.1.1 255.255.255.0
SWITCH(config-if)#no shutdown
SWITCH(config)#interface vlan 200
SWITCH(config-if)#ip address 10.0.2.1 255.255.255.0
SWITCH(config-if)#no shutdown
SWITCH(config)#interface vlan 300
SWITCH(config-if)#ip address 10.0.3.1 255.255.255.0
SWITCH(config-if)#no shutdown
SWITCH(config)#ip access-list extended vlan300in
SWITCH(config-ext-nacl)#permit ip 10.0.3.0 0.0.0.255 10.0.1.0 0.0.0.255
SWITCH(config)#interface vlan 300
SWITCH(config-if)#ip access-group vlan300in in
tak tohle me nefunguje
respond to [4]mirek: Zajímavé. Já když jsem to psal, tak jsem to vyzkoušel a chodilo to správně.
Me spolu ty vlany nekomunikuji vubec , paket dojde tak akorat na switch a dal uz nikam neprojde ....... a zkousel sem komunikaci mezi vsemi vlan .
Problem odstranen ....... clovek nesmi verit vsemu co mu cisco simulatory nakecaj;-) ........... smazal bych svuj predchozi prispevek , ale bohuzel to nejde .
respond to [4]mirek: Myslim, ze je v tom access listu prohozena zdrojova a cilova adresa, spravne to je takhle:
permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255
:-)
respond to [8]Jenda: To ne! Aplikuje se to na VLAN300 na odchozí provoz, první adresa v ACL je zdrojová, takže to musí být 10.0.3.0 0.0.0.255.
respond to [9]Samuraj: V tom pripade musi byt IP ACCESS-GROUP VLAN300 OUT.
Je to odchozi provoz, ne prichozi.
respond to [10]Jenda: Odchozí provoz to je, ale bere se to z pohledu routeru a ne VLANy. Přečtěte si můj článek nebo jakýkoliv jiný o dané problematice.
Ahoj,
potreboval bych poradit. Mam switch c3560, nastavil jsem ho do modu router a vytvoril prislusne vlany. Tento router chci používat jako centralni router v me siti. Oddelene vlany pro servery, PC a wifi sit. Problém je v tom, ze uvnitř site je vse ok, ale potrebuji odroutovat provoz ven. Od poskytovatele mam veřejnou IP. Jako AP mam router Ubiquiti nanostation M2 loco. Na venkovni strane je verejna IP, uvnitř site je IP z mého rozsahu ale v nastaveni Nanostationy (vnitrni sit) nemohu nastavit gateway, která by ukazovala smerem k c3560. V nastaveni lze zadat pouze IP a masku. Poradite mi někdo, co s tim?
Predem diky za odpověď.
Kaya
[script]snad tohle nefunguje[/script]