Help with segregating network

[Carlomd]

Hi all,

 I'm in need of guidance on how to move fwd with a project on segregating our flat network. I've done labs in the past but never fully got a vlan network running. This is my first time actually having to do this as it's now a requirement for security compliance with a customer. I'm in the process of converting the flat network into segments and have the 4948 doing the routing for the vlans, we bought a new pan500 fw, but the flat network is still on our old ASA5510 and once the network is segmented it'll be setup on the pan500.

 So here's my setup right now on what the segmented network will look like (I'm attaching a diagram and configs also)

core sw - 4948 with vlan's 10,20,30 in a trunk, note;the current flat network is still on this sw, vlan1

server switch - sg300, I'm making this vlan 20 to put all my servers in, this also has a trunk that has vlan's 10,20,30 allowed

client w/g sw - 2960g this will be vlan 30, also has vlans 10,20,30 allowed on trunk.

Issue I'm facing, I can't ping a host from the 2960 sw, to vlan 20, but from vlan20 I can ping a host on the 2960, I have the gw and subnets set on both hosts in the vlans, the only vlan host pingable from both the 2960 and sg300 is vlan10, a hyperv server residing on vlan1(4948) that has a vm guest on vlan10.

If anyone can give some helpful pointers, would be greatly appreciated.

thanks in advanced.

[Jon Marshall]

Just some comments based on the switch configurations and the diagram.

1) you should not make the native vlan the end user vlan ie. the native vlan should be an unused vlan that does not have a L3 vlan interface for it.

And you may as well standardise on a single native vlan for every trunk since it is not routed anywhere.

2) your client vlans. You don't need to allow all vlans to each switch because your server and client switches only have a single vlan on them ie only allow the vlans you  need.

3) management interfaces on the switches -

in terms of not being able to ping from the 2960 switch do you mean the actual switch ?

If so this is because you have a L3 vlan interface with a 208.x.x.x IP and a default gateway of 192.168.x.x so this is never going to work ie. the default gateway should be in the same IP subnet.

In addition you have used the same 208.x.x.x IP on all the switches which again isn't going to work.

A standard practice is to use a completely new vlan with a new IP subnet just for management of your switches. So what I would do is create a new vlan together with a new IP subnet (private IP addressing).

Then allow that vlan on the trunk links between switches, create a L3 vlan interface for the vlan on each switch and assign an IP address from the new subnet.

Whichever IP address you use on the 4948 from that new subnet should be the "ip default-gateway <IP address>" on the other switches so you can route to and from the management subnet.

If you want to use the existing L3 vlan interface for management then each switch needs a unique IP from the same IP subnet and whichever IP you use on the 4948 is the default gateway on the other switches.

Jon

[Carlomd]

Hi Jon, thanks for the quick reply.

1. Yes we are trying to get away from that, I only have one l3 sw, which happens to have the old native client vlan on it, should I get a new l3 sw, like a 3750 or another 4948, so I can migrate cleanly on the new switch, I also need to get my windows dhcp server to provide ip's to the client vlan30.

2. ok so for ex. on int g0/1 which is my trunk on the 2960g the client sw, I only allow vlan 10 and 20 since that int is on native vlan 30, so I would need to remove vlan30

3. I mean from a host on the 2960 and I try to ping another host on another sw (sg300), it times out, I added the default gateway of 192.168.x.x on the sg300 and 2960 after reading up on another thread, I can take those out and start over.

I will redo my ip addressing, I've been using an old public ip range from our old isp as internal private addresses for many years, so basically use all private addresses (192.x.x.x) as the new management vlan, and then for the svi vlan int's I can also use the same range right, as well as dhcp.

I'm avoiding the downtime by setting up a lab that will eventually become the new network, ok thanks for the pointers, I'll keep you posted on my progress.

[Jon Marshall]

2) Not sure I follow. You allow on the trunk links the vlans in use on the switch.

So that would be the vlan in use on the switch and also the switch management vlan if you create a new vlan as I suggested in my first post.

3) pinging from host to host has  nothing to do with the default gateways on the switches. The clients should be using the IP address assigned to the vlan interface on the 4948 for their specific vlan.

I would recommend firstly changing the native vlan, allowing the right vlans on the trunks and then make sure the clients have the right default gateways and retesting.

Jon

[Carlomd]

Ok got it, I took out the def-gateways on all switches and will just use the ones on the host pcs, re-added vlan 30 that I removed from the trunk(trunk now has all 3 vlans needed), I'll give it another try, thanks.

update: it was the win7 fw, fully disabled it and it now pings from host to another host in other vlans

[Carlomd]

Hi all,

so I finally got a new switch (nexus n3k) set up with the vlans, svi's and ip's, then on the pa500 fw I have an int with 3 sub interfaces also with ip's to connect to the sw vlans.

n3k sw (with intervlan routing)

vlan10, vlan20,vlan30 in trunked uplink to fw

svi's-vlan10-172.x.10.1

vlan20-172.x.20.1

vlan30-172.x.30.1

on the fw

int 1/1 with 3 subint's

172.x.10.2

172.x.20.2

172.x.30.2

I created a route to the fw- ip route 0.0.0.0/0 172.x.10.2

then vice versa a return route to the sw 0.0.0.0/0 172.x.10.1

not sure what I missed but I can't ping from the sw to fw or the other way around, can anyone give some pointers or advice

thanks in advanced

update - got it figured out, int's needed to be trunked to the pan with allowed vlans, and on the pan make sure the mgmt. profiles are set to allow ping, didn't need routing, all the svi's are pingable from the fw and vice versa.