Search this Blog

Wednesday, March 23, 2011

How to prove no inter-vlan Routing

Qsolved Question: We have been tasked to prove that clients in separate access Vlans cannot get to each other whatsoever. We 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? We 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 we can take a look, and removing this option from the Registry is proving to be time consuming. Any thoughts?

Here is some relevant 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?

Qsolved Answer:

  • 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

  • We need 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 ?

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.

Citation - This blog post does not reflect original content from the author. Rather it summarizes content that are relevant to the topic from different sources in the web. The sources might include any online discussion boards, forums, websites and others.

No comments :

Post a Comment

 
/* Google Analytics begin ----------------------------------------------- */ /* Google Analytics end ----------------------------------------------- */