- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-17-2019 04:20 AM
I thought I'd best be able to illustrate my issue with a collection of ping commands:
MY_SWITCH#ping XX.YY0.41.131 source XX.YY0.48.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/8 ms
MY_SWITCH#ping XX.YY0.48.10 source XX.YY0.41.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms
MY_SWITCH#ping XX.YY3.255.6 source XX.YY0.41.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/9 ms
MY_SWITCH#ping XX.YY3.255.6 source XX.YY0.48.1
Success rate is 0 percent (0/5)
MY_SWITCH#ping XX.YY0.41.131 source XX.YY3.255.5
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms
MY_SWITCH#ping XX.YY0.48.10 source XX.YY3.255.5
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms
As you can see ONLY ONE ping command fails. This is my issue. Communication from a particular VLAN to one particular other one just doesn't work. This is an existing network I have started working and I have set up the new VLAN which fails to reach the particular VLAN. For reference here are some VLAN IDs to explain the IPs above:
- VLAN 10 - XX.YY3.255.4/30
- VLAN 20 - XX.YY0.41.0/24
- VLAN 30 - XX.YY0.48.0/24
The ping illustration shows that:
- reach VLAN20 hosts from VLAN30
- reach VLAN30 hosts from VLAN20
- reach VLAN10 hosts from VLAN20
- CANNOT reach VLAN10 hosts from VLAN30
- reach VLAN 30 hosts from VLAN10
- reach VLAN 20 hosts from VLAN10
I've looked at trunk ports, etherchannels and ACLs and cannot see anything that would suggest VLAN30 has no access to VLAN10.
Switches involved are C3750s and C2960 with VLAN via VTP.
Anyone have any suggestions as to where I should look. I'm more than happy to re-check anything I already have!
Many thanks in advance!
Solved! Go to Solution.
- Labels:
-
Catalyst 3000
-
LAN Switching
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-18-2019 09:47 AM - edited 09-18-2019 09:48 AM
Hi,
Wow have I learnt a lot in the last few days!!!
My problem is solved! There was nothing wrong with the switch or the configuration.
The ISP gateway (as I guessed) was the issue. It turns out the ISP enforce a local IP range because they provide the service as part of a larger intranet. Therefore the subnets available to me were limited and I had created a VLAN just outside of the allowed range. Therefore packets from my new VLAN subnet were being dropped!
I now have access to an extended range and internet connectivity is working fine!!
Thanks again for your help Mark.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-17-2019 04:32 AM
can the SVIs on the L3 device ping each other , the 2 vlan ins question , before trying to ping from hosts on access switches start at the dist or core where the SVIs are and test there , that will rule out intervlan as the issue and then it must be l2 issue somewhere
Check STP is not blocking the vlans too along path and that there all forwarding
No firewall in place here virtual of physical there passing through either
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-17-2019 05:26 AM
Hi Mark,
Thanks for the reply. I think it might be L2 from what you say. Here are pings from SVIs on L3 core switch:
MY_SWITCH#ping XX.YY3.255.5 source XX.YY0.41.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
MY_SWITCH#ping XX.YY3.255.5 source XX.YY0.48.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
MY_SWITCH#ping XX.YY0.41.1 source XX.YY3.255.5
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
MY_SWITCH#ping XX.YY0.41.1 source XX.YY0.48.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms
MY_SWITCH#ping XX.YY0.48.1 source XX.YY3.255.5
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
MY_SWITCH#ping XX.YY0.48.1 source XX.YY0.41.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
The original pings were all carried out on the core switch too.
Not entirely sure how to check whether there is any blocking via STP. Could you point me to command at all?
There are no firewalls present within network. The L2 switch is trunked directly into the L3 switch.
The only other thought I had was that the host I am trying to ping inside VLAN1 is the site's gateway router, so I wonder if it is configured to only accept traffic from certain IP subnets? I unfortunately cannot check this as it is controlled by the ISP.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-17-2019 06:04 AM
Maybe but you could rule it out by putting laptop on same vlan giving it IP on same range and test that way as they wont control that the ISP
If intervlan routing is working between SVIs then could be some layer 2 issue
Also make sure the devices you are trying to ping between are not running any type of software firewall they can drop ICMP by default and may have to be disabled for a test , bets thing is get 2 laptops yourself put one on each vlan turn off AV and FWs and repeat the test , if the issue is still there check below
Recheck all trunks and links through the path just to be sure
Then check show int trunk on each link up again make sure it shows the last step below thats its FWD in STP
sh int trunk
Port Mode Encapsulation Status Native vlan
Gi1/0/47 on 802.1q trunking 5
Po1 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/0/47 1,5-6
Po1 1,4-6,226,2225,2239
Port Vlans allowed and active in management domain
Gi1/0/47 1,5-6
Po1 1,4-6,226,2225,2239
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/47 1,5-6
Po1 1,4-6,226,2225,2239
Also check the STP for that vlan too as another step to match the above show int trunk , you can see when you check vlan 4 its allowed for PO1 its trunk in STP too
show spanning-tree vlan 4
VLAN0004
Spanning tree enabled protocol ieee
Root ID Priority 32772
Address
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32772 (priority 32768 sys-id-ext 4)
Address
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/3 Desg FWD 19 128.3 P2p Edge
Gi1/0/4 Desg FWD 19 128.4 P2p Edge
Gi1/0/5 Desg FWD 19 128.5 P2p Edge
Gi1/0/6 Desg FWD 19 128.6 P2p Edge
Gi1/0/7 Desg FWD 19 128.7 P2p Edge
Gi1/0/8 Desg FWD 19 128.8 P2p Edge
Gi1/0/9 Desg FWD 19 128.9 P2p Edge
Gi1/0/37 Desg FWD 19 128.37 P2p Edge
Gi1/0/38 Desg FWD 19 128.38 P2p Edge
Gi1/0/43 Desg FWD 19 128.43 P2p Edge
Po1 Desg FWD 3 128.2281 P2p
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-17-2019 09:22 AM
Hi Mark,
I've just read this (not tried it yet) but wanted to say a massive thanks for taking the time to reply in such detail!
I'll try it out tomorrow and feedback.
Cheers,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-18-2019 01:09 AM
Hi Mark,
I've not tried the laptop thing because I'm working remotely at present. But since I am running the ping commands on the L3 switch the firewall thing doesn't factor right?
In terms of the physical paths. Same as above. All my testing is taking place on the one L3 switch stack. There are no trunks involved at present.
I did check STP and it looks like you showed in example. Couldn't see any issues.
I did one other bit of testing. I created another new VLAN (say 50) and set it up with IP XX.YY0.49.1 255.255.255.240. I didn't configure any ports so there were no physical devices involved. I then again ran the ping test from this new VLAN to the interface (XX.YY3.255.5) on VLAN10 and it passed just like when VLAN30 is the source. So the interface for the VLAN is fine.
I then tried to ping the XX.YY3.255.6 with source XX.YY0.49.1 and it failed just like VLAN 30 does.
For good measure I pinged XX.YY3.255.6 with the source set as 4 other existing VLAN interfaces and they all passed!!
So all I can think is that somewhere there is some setting that permits traffic from those existing VLANs through to VLAN10 or some access list that prevents it. But all defaults show nothing of the sort. There are no specific default gateways and no access lists active on any ports that affect the IP ranges I am dealing with.
To give a bit more detail XX.YY.255.6 is set as a broad default gateway for all the IPs I am dealing with through this IP route command: XX.YY0.0.0/16 [1/0] via XX.YY3.255.6. And yet I cannot get on the internet from VLAN 30!
The one test that can prove whether my theory about IP ranges being blocked entirely by the router at address XX.YY3.255.6, is the laptop test that you proposed!!
I really do need to do this and I will as soon as I get down there again.
Still. Any other thoughts?
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-18-2019 01:31 AM
if this is all taking place on same stack , the routing does not matter in terms of statics etc , as intervlan routing takes place anyway on the switch , once ip routing command itself is enabled which it is as you can ping between vlans intervlan will ping
i think its something on the particular device blocking it if no acls and port acls in place its the only thing left ,as its all on same stack trunks stp shouldn't matter , these IPs your pinging they are complete for MACs in the show mac address table on the L3 stack yes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-18-2019 09:47 AM - edited 09-18-2019 09:48 AM
Hi,
Wow have I learnt a lot in the last few days!!!
My problem is solved! There was nothing wrong with the switch or the configuration.
The ISP gateway (as I guessed) was the issue. It turns out the ISP enforce a local IP range because they provide the service as part of a larger intranet. Therefore the subnets available to me were limited and I had created a VLAN just outside of the allowed range. Therefore packets from my new VLAN subnet were being dropped!
I now have access to an extended range and internet connectivity is working fine!!
Thanks again for your help Mark.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-18-2019 10:03 AM
