Re: Any host with any IP can connect my switch port

MUSTAFA3 · ‎01-24-2020

Hi all,

I would like to ask a question about network design.

Topology is as follows: My devices connect to 3650 which works as edge switch and it is connected to BB 3850.

I only defined two VLANs in 3650 (vlan20 and vlan10) and gave that VLANs to specific ports. On the 3850 switch, I defined vlan10 with a 192.170.10.1 255.255.0.0 IP address, and vlan20 with a 192.170.20.1 255.255.0.0 IP address.

But I can connect any devices with an IP 192.168.x.x to any ports on 3650 and the devices with IP 192.168.x.x can access each other over 3650. How can I block that, how can I ensure that only the devices that have IP according to vlan10 and vlan20 can connect to edge switch?

Georg Pauwen · ‎01-25-2020

Hello,

in theory, putting a port in a different Vlan should isolate that port...

Can you post the full running configs of both switches ?

MUSTAFA3 · ‎01-25-2020

I also put the topology in packet tracer. In this topology, 10.1.10.2 can ping to 10.1.10.3, vice versa.

You can find the configs below.

Thanks.

EdgeSwitch

------------

version 16.3.2

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname EDGE_SW

!

no ip cef

no ipv6 cef

!

spanning-tree mode pvst

!

interface GigabitEthernet1/0/1

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface GigabitEthernet1/0/2

switchport access vlan 10

switchport mode access

switchport nonegotiate

!

interface GigabitEthernet1/0/3

switchport access vlan 5

switchport mode access

switchport nonegotiate

!

interface GigabitEthernet1/0/4

switchport access vlan 20

switchport mode access

switchport nonegotiate

!

interface GigabitEthernet1/0/5

switchport access vlan 10

switchport mode access

switchport nonegotiate

!

interface GigabitEthernet1/0/6

switchport access vlan 20

switchport mode access

switchport nonegotiate

!

interface GigabitEthernet1/0/7

switchport access vlan 20

switchport mode access

switchport nonegotiate

!

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

!

interface GigabitEthernet1/1/1

!

interface GigabitEthernet1/1/2

!

interface GigabitEthernet1/1/3

!

interface GigabitEthernet1/1/4

!

interface Vlan1

no ip address

shutdown

!

ip classless

!

ip flow-export version 9

!

line con 0

!

line aux 0

!

line vty 0 4

login

!

end

BB Switch

-------------

!

version 16.3.2

no service timestamps log datetime msec

no service timestamps debug datetime msec

no service password-encryption

!

hostname BB

!

no ip cef

ip routing

!

no ipv6 cef

!

spanning-tree mode pvst

!

interface GigabitEthernet1/0/1

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface GigabitEthernet1/0/2

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface GigabitEthernet1/0/3

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface GigabitEthernet1/0/4

!

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

!

interface GigabitEthernet1/1/1

!

interface GigabitEthernet1/1/2

!

interface GigabitEthernet1/1/3

!

interface GigabitEthernet1/1/4

!

interface Vlan1

no ip address

shutdown

!

interface Vlan10

mac-address 0060.4768.e702

ip address 192.170.10.1 255.255.255.0

!

interface Vlan20

mac-address 0060.4768.e703

ip address 192.170.20.1 255.255.255.0

!

ip classless

!

ip flow-export version 9

!

ip access-list standard test1

!

line con 0

!

line aux 0

!

line vty 0 4

login

!

end

Georg Pauwen · ‎01-25-2020

Hello,

can you post the project(.pkt) file ? ZIP it first otherwise the system won't let you upload it...

Configs look ok as far as I can tell. Packet Tracer has a few flaws, this might be one of them...

MUSTAFA3 · ‎01-25-2020

I attached the project.

I think that it does not look like that reason is a packet tracer.

Thank you for your effort.

Georg Pauwen · ‎01-25-2020

Hello,

I just connected two PCs, in two different Vlans, with both access ports being in another Vlan. No communication at all...

That is why I think it is either a flaw with the 3560 in Packet Tracer, or in Packet Tracer globally. Instead of the 3560, try a 2960 and check if the results are the same...

Senbonzakura · ‎01-26-2020

Yes, I agree with Georg.

Logically speaking, those the two hosts shouldn't be able to ping each other do to being in two separate broadcast domains.

The only other ways those two VLANs could talk to each other would be if you had a routing table configured or if they were the same VLAN because configuring a VLAN on an interface is segmenting it.

Based on your configuration of the interfaces you showed us, they shouldn't be able to communicate.

Richard Burts · ‎01-25-2020

I found the description in the original post to be somewhat confusing about what is the issue. But the diagram and the configs that were posted are very clear. The original poster assumes that this network has only 2 vlans (10 and 20) but this network also has a third vlan, which is vlan 1. Any port not assigned to a specific vlan belongs in vlan 1.

If I understand the explanation correctly devices connected in vlans 10 and 20 are working as expected. But the original poster is concerned that devices connected to ports that are not in those vlans, and given IP addresses 10.1.10.2 and 10.1.10.2 are able to ping each other. The explanation for this is simple. Both of those PCs are connected to ports in vlan 1. Interface vlan 1 does not have an IP address and is shut down. So devices in vlan 1 would not be able to communicate with devices in other vlans. But any device in vlan 1 can communicate with any other device in vlan 1 by simply sending an arp request for the other device. This is why 10.1.10.2 can communicate with 10.1.10.3, they are both in vlan 1 and are using local communication. The original poster seems to want to prevent this communication but I do not know of any way to prevent devices who are in the same vlan to communicate with each other.

HTH

Rick

HTH

Rick

Georg Pauwen · ‎01-25-2020

Hello Richard,

the problem is that a PC with an access port in Vlan 20 with IP address 192.170.20.200/24 can ping a PC with an access port in Vlan 10 and IP address 192.170.10.101/24. I tried this on a real switch but could not get both machines to reach each other. I don't see how they could, so I think it must be Packet Tracer.

Maybe you have seen something like that before ?

MUSTAFA3 · ‎01-26-2020

Maybe I could not state the problem correctly. But the real problem is "how can I ensure that only the devices that have IP according to vlan10 and vlan20 can connect to edge switch?" as @Richard Burts wrote

Richard Burts · ‎01-26-2020

@Senbonzakura misses the point made in the original post that the access switch is connected to a backbone switch and the backbone switch does have ip routing enabled. So correct hosts in vlan 10 should communicate successfully with correct hosts in vlan 20. This is not the issue raised in the original post.

I made an assumption that the hosts using 10.1.10.2 and 10.1.10.3 were connected to switch ports in vlan 1. If that were the case the hosts would be able to communicate with each other. But they would not be able to communicate with anything outside of vlan 1. @MUSTAFA3 has provided clarification and tells us that those hosts were connected to ports in vlan 20. This does complicate the situation a bit. So now vlan 20 has some hosts (correctly) in subnet 192.170.20.0 and some hosts in subnet 10.1.10.0. What does this mean?

If the question were whether it is possible for a host in 10.1.10.0 to communicate with a host in 192.170.20.0 I would say that in certain specific (and limited) circumstances it is possible for 10.1.10.0 host to communicate with 192.170.20.0 host. But in most circumstances 10.1.10.0 will not communicate with 192.170.20.0. So the situation is much like what I said in my earlier response. 10.1.10.2 will communicate with 10.1.10.3 but not with anything else.

But that is not really what @MUSTAFA3 was asking. He is asking how to prevent hosts in vlan 20 from using addresses in a different subnet. If all hosts were using DHCP this would be easy to achieve. But if vlan 20 is using DHCP (as the posted config shows that it is) and someone connects a host with a manually configured static IP how can we address this? I believe that Dynamic ARP Inspection is the best tool to solve this.

HTH

Rick

HTH

Rick

Richard Burts · ‎01-25-2020

It seems that @Georg Pauwen and I have different understanding of the problem described in this post. Georg believes that hosts in 192.170.10.0 should not be able to communicate with hosts in 192.170.20.0. And he set up a switch to test it and in his test the hosts could not communicate. I am guessing that his test was done on a edge switch that did not have a trunk connecting to the backbone switch.

As I look at the posted configs here is what I see:

- edge switch with some ports assigned to vlan 10 and some ports assigned to vlan 20 (and some ports still in vlan 1).

- edge switch connects to backbone switch with a trunk that carries all the vlans.

- backbone switch connects with a trunk port that carries the vlans.

- backbone switch has vlan interfaces for vlan 10 and vlan 20 with appropriate IP addresses and masks (and interface vlan 1 has no address and is shut down).

- backbone switch has ip routing enabled.

Given that configuration the expected behavior is that hosts in vlan 10 and vlan 20 should communicate successfully. (another expected behavior is that hosts in vlan 10 and 20 should not be able to communicate with hosts in vlan 1)

As I read the post that has the diagram and the configs I believe that the problem being described is that host 10.1.10.2 and host 10.1.10.3 can successfully ping each other. As I explained in my previous response this is expected behavior. Hosts in the same vlan should be able to communicate, and that is true no matter whether ip routing is enabled or not (and no matter whether switches involved are layer 2 only or are layer2/layer 3).

As I re-read the original post I believe that there is a significant question being asked: "how can I ensure that only the devices that have IP according to vlan10 and vlan20 can connect to edge switch?". I believe that the only way to ensure that only devices in vlan 10 and vlan 20 can connect is to ensure that every switch port that is not in vlan 10 or in vlan 20 is shut down. If 2 devices are allowed to connect in vlan 1 then they will be able to communicate.

HTH

Rick

HTH

Rick

MUSTAFA3 · ‎01-26-2020

Thanks for the detailed response. And you're right, my question is actually "how can I ensure that only the devices that have IP according to vlan10 and vlan20 can connect to edge switch?".

The devices that have IP 10.1.10.2 and 10.1.10.3 is attached to the access ports with vlan20, in addition, VLAN1 is shut down. According to the definition of VLAN20, given IPs are not acceptable and they must not able to communicate, also your comment verifies that. Do I miss anything?