How to prove no inter-vlan Routing

[ianwardGD]

Greetings,

I have been tasked to prove that clients in separate access Vlans cannot get to each other whatsoever. I have three switches connected in a tree, with the core having different EIGRP AS numbers for each VLAN. The core connects the two other switches together, each switch has an individual client connected to it in a separate VLAN. Besides constant pings from one to the other that fail can anyone else think of a good way to procedurally and quantitatively prove this? I have also considered inspecting the ICMP packets that go across the trunk with Wireshark, but my Intel NIC card strips the VLAN tag from the packet before I can take a look, and removing this option from the Registry is proving to be time consuming. Any thoughts?

[Jon Marshall]

Ian

It's unclear how the core is setup. If the L3 SVIs for the vlans are on the core then having different EIGRP AS's will make no difference because the core switch will see these 3 vlans as directly connected. However you say pings are not working so perhaps i am misunderstanding where your L3 SVIs are setup.

If they are on the core then the pings may be failing not because of your EIGRP setup but because of firewalls on the PC ? Not saying this is the case but worth checking.

However, more specifically for your issue if the only reason your are using separate AS's is to stop inter-vlan communication then this is the wrong tool. You should be looking at -

1) access-lists on the L3 SVIs to restrict traffic

or

2) the use of vrfs on the switch

Jon

[ianwardGD]

Here is some relevent configs for the 3 switches:

CORE:

interface TenGigabitEthernet1/1
switchport trunk allowed vlan 10,15
switchport mode trunk
!
interface TenGigabitEthernet1/2
switchport trunk allowed vlan 10,15
switchport mode trunk
!

!
interface Vlan10
ip address 172.10.254.254 255.255.0.0
!
interface Vlan15
ip address 172.15.254.254 255.255.0.0
!
!
router eigrp 10
network 172.10.0.0
!
!
router eigrp 15
network 172.15.0.0
!

EDGE1:

!
interface GigabitEthernet0/1
switchport access vlan 10
switchport mode access
!

!
interface TenGigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,15
switchport mode trunk
!
interface TenGigabitEthernet0/2
!
interface Vlan1
no ip address
!
interface Vlan10
ip address 172.10.1.254 255.255.0.0
!
interface Vlan15
ip address 172.15.1.254 255.255.0.0
!

EDGE2:

!
interface GigabitEthernet0/1
switchport access vlan 15
switchport mode access
!

!
interface TenGigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,15
switchport mode trunk
!
interface TenGigabitEthernet0/2
!
interface Vlan1
no ip address
shutdown
!
interface Vlan10
ip address 172.10.2.254 255.255.0.0
!
interface Vlan15
ip address 172.15.2.254 255.255.0.0
!

Client1 is connected to EDGE1 gi0/1 with a vlan10 address and Client2 is connected to EDGE2 with a VLAN 15 address. For VLANs to communicate there needs to be a layer3 route between them but I thought I covered this by putting the networks in different AS, hence the failed pings. All the switches can ping each other because of the direct connection. Wouldn't adding ACLs just prove the effectiveness of an access list?

[Jon Marshall]

Ian

1) what is the default-gateway for client in vlan 10 and client in vlan 15 ?

2) can you post "sh ip route" from all switches  ?

Jon

[ianwardGD]

I did not specify the default gateway on the two clients and once I did the pings went through successfully. I'm a little confused as to why the pings were successful as I thought there needed to be on a common routing protocol(AS). Am I correct in thinking that the only way to make sure that two VLANS cannot talk to each other is through a VACL?

how does something like this look installed on the core:

ip access-list extended virtual-10

permit ip host 172.10.0.0. 0.0.255.255 172.10.0.0 0.0.255.255

exit

vlan access-map check-10 10

match ip address virtual-10

action forward

vlan access-map check-10 20

action drop

exit

vlan filter check-10 vlan-list 10

ip access-list extended virtual-15

permit ip host 172.15.0.0. 0.0.255.255 172.15.0.0 0.0.255.255

exit

vlan access-map check-15 10

match ip address virtual-15

action forward

vlan access-map check-15 20

action drop

exit

vlan filter check-15 vlan-list 15

[Jon Marshall · Accepted solution]

Ian

That was why i wanted to know where your inter-vlan routing was and it sounds like the core switch ie. did you set the default-gateway of the clients to be the respective IP address(s) of int vlan 10 and 15 on the core switch ?

It is as i said in my first post. The core switch will see vlan 10 and vlan 15 subnets as directly connected routes because the actual L3 interfaces for those vlans are actually on the core switch. So they will not be learned through EIGRP. Do a "sh ip route" on the core switch and you will see that the routes for those 2 subnets are learnt because they are directly connected and not through EIGRP.

If you had 2 routers (R1 & R2)  connected to your core switch and you ran EIGRP AS 10 on R1 and EIGRP 15 AS on R2 then R1 would only know about the 172.10.0.0 network and R2 would only know about the 172.15.0.0 network.

As for restricting access on the core switch (assuming the default-gateways for the clients are the core switch vlan IPs) you can use a VACL but a simpler and more standard approach would be to use an extended acl eg. on your core switch -

access-list 101 deny ip 172.10.0.0 0.0.255.255 172.15.0.0 0.0.255.255

access-list 101 permit ip 172.10.0.0 0.0.255.255 any   <-- this is for any traffic from vlan 10 to anywhere else other than vlan 15

int vlan 10

ip access-group 101 in

access-list 102 deny ip 172.15.0.0 0.0.255.255 172.10.0.0 0.0.255.255

access-list 102 permit ip 172.15.0.0 0.0.255.255 any

int vlan 15

ip access-group 102 in

Edit - for info, if you just wanted these 2 vlans be isolated ie. they cannot talk to each other but also they cannot talk to any other subnet outside of their own then simply remove the L3 SVIs for these vlans off the core switch.

Jon

[Jigar Dave]

Hello Ian,

while reading the thread, I am not able to understand one thing, you have created vlan 10 and vlan 15 on your core switch

interface Vlan10
ip address 172.10.254.254 255.255.0.0
!
interface Vlan15
ip address 172.15.254.254 255.255.0.0

and also again on your EDGE1 you have created another vlan with same no. but with different IP address/subnet

interface Vlan10
ip address 172.10.1.254 255.255.0.0
!
interface Vlan15
ip address 172.15.1.254 255.255.0.0

on EDGE2 as well,

interface Vlan10
ip address 172.10.2.254 255.255.0.0
!
interface Vlan15
ip address 172.15.2.254 255.255.0.0

I am interested to learn what is the reason behind this? it is not good idea if vlan created on core switches shoudl span across all switches by making core switch as VTP server mode and other 2 EDGE switches as VTP client or transparent mode?

its just a thought.

Best regards,

Jigar

[ianwardGD]

there is no VTP enabled here, since this was a test set up, adding management IPs for each VLAN on the edge switch was an easy way to make sure there was connectivity between the switches and the correct VLANs were being trunked to where they were suppose to go.