09-13-2016 04:28 AM - edited 03-08-2019 07:24 AM
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 ?
09-13-2016 01:06 PM
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
09-13-2016 10:08 PM
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 ?
09-13-2016 11:38 PM
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.
09-14-2016 04:43 AM
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.
09-14-2016 02:19 AM
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
09-14-2016 05:07 AM
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.
09-14-2016 06:27 AM
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
09-15-2016 10:11 PM
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).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide