VLAN advice / pointers

[cheesypete]

I'm at the point where I've got VLAN blindness and cant see the reason for this issue - its probably something really obvious..

 

Currently moving away from a flat network to one with VLANS - all switches are HP, with the core switch being an HP A5800 and edge switches mainly HP 1910s

 

Have implemented some "test" VLANS across the core and edge switches, and as far as i can tell the intervlan routing is working fine; i can ping devices across vlans, as well as access shared folders.

However what i cant seem able to do, is ping devices (in this case servers) that are currently wired into the default VLAN (1) on the core

 

I can ping the core (ie ping the default VLAN) from any device on the VLANs i have created, but i cant ping the devices sat on VLAN 1. However devices that aren't part of a VLAN still can do so (and obviously this is paramount as i don want to collapse the whole network!!)

 

First question is - should i be able to ping the devices on VLAN 1? I feel that i should, but might be missing some basic VLAN 101 knowledge here

Secondly - what am i missing in my "wood for the trees" state!! It feels like its a routing issue but cant see why.

[Michael]

Tagged ports are a combination of VLANs or sometimes referred to as trunks. Untagged are any other ports associated with that VLAN.

 

Presumably if you're connected to an untagged port as part of the default VLAN, then you can ping servers? I'm speculating the port you're connected to isn't tagged with the default VLAN - that's how I see it, first look. VLANs can get complicated if you have too many.

[cheesypete]

Hi Michael - thanks for the reply, and apologies for delay in replying

 

Your comment was potentially a eureka moment, as that was one thing i had overlooked - sadly, popping the tag onto the port didn't make any difference - grr!

Keep getting pulled back to the route table, but apart from the static route to the gateway (10.4.192.150) the rest of it has been autopopulated with the vlan interfaces (10.11.x.x) - the core switch being 10.4.192.252

 

[Willott]

Do your devices on VLAN1 have 10.4.192.150 as their default gateway, or the switch?

[cheesypete]

Currently using 10.4.192.150...

[Willott]

Probably your cause (guessing you don't have routes in your router for the various vlans)? Packets will be routed from the vlans, to the servers, which will then reply sending packets to 10.4.192.150 which will most likely drop packets (or may route out to next hop dependent on router setup). Grab a test device, stick it's default gw to 10.4.192.252 and see if you can ping off vlans and from device to vlans

 

Edit: other way to confirm this would be to traceroute from both sides

Edited January 24, 2017 by Willott

[cheesypete]

No i dont have access to the router, so core switch was to be used for routing (being L3)

I'll go and have a play now..

[cheesypete]

So, flicking the default gateway to 10.4.192.252 allows pinging from both sides - result...

 

...however, the endpoints lose connection to internet

 

So somewhere there must be a need to edit the route table?

[Willott]

Endpoints on which netrange? Can you traceroute to google.com to see at which hop you loose?

[Katy]

Your core switch will need 10.4.192.150 set as the default gateway, any devices in VLAN1 will need 10.4.192.252 as their default gateway (set on the device e.g. by static or DHCP, not set on the switch), and any devices on the other VLANs will need the core switch interface IP on that specific vlan as their default gateway... that way all traffic goes to the core switch, then it handles anything across the VLANs itself and anything for the Internet goes out on 10.4.192.150.

[cheesypete]

Obviously not at school at moment (theres devotion, and then theres stupidity!)

@Willott - thanks for your advice up to this point. Changing the gateway to 10.4.192.252 was the "blindingly obvious" variable i couldnt see - made perfect sense considering i had been following the rules of setting vlan devices to the switch ip they were connected to (but for some reason not those on core / vlan1)

@Katy - will look at that in morning. Thank you

[MicrosoftTechy]

@Katy is correct you must ensure all client devices connected to the access layer have their default gateway set to the SVI ( Switch Virtual Interface ) address of the respective VLAN on the core. Once the packets arrive at your core layer you must the have a default route 0.0.0.0/0 on the core pointing to your router that I presume is connected to the internet. As there is no NAT taking place on this link core<--->next router ( internet ) you must ensure you update its routing table with the NLRI ( Network Layer Reachability Information ) back to the segments on the core otherwise, he won't know how to pass the traffic back and the traffic will blackhole.

 

Best option if you core device supports it would connect a point-to-point link between the core and the magical internet router and on the core side apply an IP to the physical interface and do the same on the magical internet box. so core_Gi1/0/1<10.0.0.1/30 ---- 10.0.0.2/30>internet_Gi10/1 and set the following routes up

 

core

0.0.0.0/0 next-hop=10.0.0.2 ( if I don't have the route in my table for the destined traffic ill pass it to the magical router )

 

 

Magical Internet Box

0.0.0.0/0 DONT PLAY WITH THIS hehe add the prefixes separately or you will break the internet

192.168.1.0/24 next-hop=10.0.0.1 ( Great I know how to send it back to the core )

192.168.2.0/24 next-hop=10.0.0.1 ( Great I know how to send it back to the core )

192.168.3.0/24 next-hop=10.0.0.1 ( Great I know how to send it back to the core )

 

Example subnets above ( these would be the segments the clients are in on the core )

 

Hope this helps

 

- - - Updated - - -

@Katy is correct you must ensure all client devices connected to the access layer have their default gateway set to the SVI ( Switch Virtual Interface ) address of the respective VLAN on the core. Once the packets arrive at your core layer you must the have a default route 0.0.0.0/0 on the core pointing to your router that I presume is connected to the internet. As there is no NAT taking place on this link core<--->next router ( internet ) you must ensure you update its routing table with the NLRI ( Network Layer Reachability Information ) back to the segments on the core otherwise, he won't know how to pass the traffic back and the traffic will blackhole.

 

Best option if you core device supports it would connect a point-to-point link between the core and the magical internet router and on the core side apply an IP to the physical interface and do the same on the magical internet box. so core_Gi1/0/1<10.0.0.1/30 ---- 10.0.0.2/30>internet_Gi10/1 and set the following routes up

 

core

0.0.0.0/0 next-hop=10.0.0.2 ( if I don't have the route in my table for the destined traffic ill pass it to the magical router )

 

 

Magical Internet Box

0.0.0.0/0 DONT PLAY WITH THIS hehe add the prefixes separately or you will break the internet

192.168.1.0/24 next-hop=10.0.0.1 ( Great I know how to send it back to the core )

192.168.2.0/24 next-hop=10.0.0.1 ( Great I know how to send it back to the core )

192.168.3.0/24 next-hop=10.0.0.1 ( Great I know how to send it back to the core )

 

Example subnets above ( these would be the segments the clients are in on the core )

 

Hope this helps

 

Jack

[Katy]

you must ensure you update its routing table with the NLRI ( Network Layer Reachability Information ) back to the segments on the core otherwise, he won't know how to pass the traffic back and the traffic will blackhole

Ah yes knew I'd missed one step out - if you don't have access to the router you need to get whoever does to add a static route for all your VLANs pointing at your core switch IP as @MicrosoftTechy said.

[cheesypete]

Thanks for advice up to this point

Have escalated to those who control the router - will let you know!