VLANs and Layer 2

Infuscomus · ‎09-13-2016

Device: Catalyst 3750E

IOS: 12.2(53)SE2

Situation: multiple VLANs configured, DHCP enabled, inter-VLAN routing is working correctly. ICMP partially working between devices in different VLANs. At an ICMP sweep I can detect about 1/3 of the IP addresses in the other than current VLANs.

Problem: can no longer detect MAC addresses of computers in other-than-current VLAN with any network scanning tools.

This situation occurred after a firewall was implemented in the network (between SW and Router), but it does not appear to be related to this. During the FW implementation, there were some test changes made on the SW, but now the configuration is nearly identical to the initial one except some reallocated ports and the To-FW-Interface IP chage. I can find absolutely nothing that could cause this anomaly. SW reboot did not solve the problem.

Practically, before, I could quickly do a complete network sweep and in a few seconds I had correct information about all devices in all VLANs of the network, no matter where the sweep was done from. Now, I can only detect part of the devices (which makes no sense). What can cause this ?

I can see the necessary information from the SW CLI, but the low level techs can no longer see all the devices in the network.

Is there a fix for this ?

Could I try to use IP-helper address to somehow forward/broadcast again the relevant L2 information ?

I know L2 info suppose not to be transmitted across VLANs, but then how come it worked before ?

salemmahara · ‎09-13-2016

you should find your answer in the character of your scanner . I mean if it's using Broadcast , it's not going to work anymore when VLANs come up. When a switch receives frames from Trunk port, it only throw it out of ports which are same as sender VLAN. Can you involve your router in your scan procedure ? encapsulation and decapsulation can help you

Infuscomus · ‎09-13-2016

I know it's using Broadcast and it suppose not to work in VLANs, but how did it work before ?

Initially, the SW was connected to the Router. Now the firewall is between them. Perhaps the Router was doing something but what ?

salemmahara · ‎09-13-2016

1. MAC address will be changed during routing process.

2. If you want to lookup a device using its MAC, you must be in the same broadcast domain otherwise you can't find it using physical address ( MAC ) .

3. Again, you should consider to type of generated packet.

-multicast ? Of course NO because it's used in some applications and protocols .

- Unicast :

->same network : destination will be find using Broadcast

-> Another network: using your gateway

- Broadcast: This kind of packets will be sent to specific address ( Ex: 192.168.255.255 is broadcast for 192.168.0.0/16) . So all computers in this range receive the request .

Note: Router never pass Broadcast .

So if you could find clients before, you should check your design again. I personally can't talk about it without information.

Infuscomus · ‎09-14-2016

Please tell me what information you would need and I can provide it. I used to use AngryIPScanner for the very quick scan. Now this now finds only a few hosts alive hostnames do not actually match (like it would get them from a cache). AdvancedIPScanner (this one takes way too much time to scan vs. the only few seconds for correctly configured AIPS) correctly detects what's alive, but again hostnames are not updated.

paul driver · ‎09-14-2016

Hello

If this was working prior to some change then I would suggest that change made some impact.

During the FW implementation, there were some test changes made on the SW

Was this on the L3 switch?

Check to see if all the L3 interfaces (SW and FW) have the correct subnet ranges, I have seen in the past misconfiguration on subnetwork addressing and it caused partial loss of reachability to devices it the same subnet

res
Paul

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Infuscomus · ‎09-14-2016

A VLAN was moved to the FW as a test, but then it was put back on the SW. I suspect this is part of what caused the problem. subnet ranges were never changed, port assignments are the same.

paul driver · ‎09-14-2016

Hello
So there is no misconfiguration pertaining to this affected subnet?

inter-VLAN routing is working correctly. ICMP partially working between devices in different VLANs

Contradicting statement - You must have some inter-vlan routing issue -
As the L3 for now resides back on the L3 switch and not on the fw, has the routing for this subnet been taken off the FW. plus any static routes, acls etc...

Have you tried clearing arp cache(s)
What type of switch is perform the inter-vlan routing?
Do you have Dhcp snooping, DAI or IPSG enabled or any first hop routing protocols?.

Can you ping other vlans from the core switch sourced from different L3 interfaces?
From a affected host what does a trace show, does it hit its related default-gateway

res
Paul

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Infuscomus · ‎09-15-2016

I was going to answer yesterday, but the forums went down.

No other so-far reported issues except ICMP, everything else and of higher layers is working, including RDP.

Yes, there are no static routes in the FW, the subnet was there just for testing.

I did not clear arp/cache, but I did reload the SW.

The switch performing the IVR is a catalyst 3750-E

Switch DHCP snooping is disabled. ARP inspection/DAI is disabled. No IPSG, No FHRP.

Yes, I can ping any of the target IP addresses no matter their VLAN directly from the SW CLI.

Traceroute towards an internet address goes normally: 1.SW-VLAN-GW --> 2.Router --> 3. ISP-IP
Traceroute towards a detectable LAN IP in another VLAN or any IP from the same VLAN resolves after hop 1 (SW).
Traceroute towards an undetectable LAN IP that is alive in another VLAN times out after hop 1 (SW).