VoIP VLAN Issues V1910/2915-8

[RFVIT]

Hi All,

I am having some issues getting our network to function correctly. I am sure I am missing something.

We have installed a new VoIP system on VLAN5. I am using a 5406zlR2 as the core switch (no routers only L3 and static routes).

Previously the network has been configured with V1910 (2014) that I believe have implemented PBR using ACL.

It is configured so that behind the native VLAN1 (using a 192 range) an address range (172.20..1.x/24) will be given via a DHCP address request. This is across most of our outlying sites, each has its own scope .2, .3 etc.

VoIP is assigned it's own DHCP scope (192.168.x.x /24) on VLAN5. It is working everywhere but where the PBR is configured.

On all outlying L3 switches on a 172 range, the incoming port #1 is set to no VLAN1, the rest untagged VLAN 1.

This gives the DHCP range assignment, but I can't get the DHCP for VLAN 5 to work.

I have changed out a few with 2915-8 POE L3 and the result is the same. 

Things I have checked -

All VLAN 5 tagged through the networks, static routes to point back to the VLAN interface from remote switch, VLAN 1 assigment of 172 address is functioning, can ping all addresses on network across networks.

Do I need a route from the core switch out to the VLAN 5 interfaces?

[Vince-Whirlwind]

If I'm understanding at least part of this, what you have is something like:

Site 1
   DATA 172.20.1.0/24
   VOICE 192.168.1.0/24

Site2
   DATA 172.20.2.0/24
   VOICE 192.168.2.0/24

And the links between them are on a different subnet ("a 192 range"). Also, VLAN1 is not trunked to each site's router.
So each site has an additional interface with an IP address in this "192 range".

Your references to VLANs are confusing - if these are all routed links, then VLANs are very interesting.

Your final question is presumably the issue - you don't have your routing setup in such a way as each site knows where each of your network's subnets are located.

I'd suggest you document your network properly before making any changes or doing any more troubleshooting. You can probably put everything there is to know about this network on one page. With that in front of you, you will save yourself an enormous amount of time and bother.

Finally, why - oh why? - do people use 192... and 172... addresses? They are ugly, take too long to write down, take up too much space on documentation, and lack flexibility.
Just use 10. addresses.

[16again]

What do you mean by "PBR using ACL"  ?
Seems to me like ports are being shared between a PC and phone (loopthrough, 2 devices on 1 switch port) , and something now goes wrong steering the phone to incorrect VLAN
Moreover , is there a drawing showing network layout used?  And configs?

Note:imho, there's nothing wrong with using 192.x and 172.y addresses, this is totally inline with RFC1918.

[Vince-Whirlwind]

---

@16again wrote:

Note:imho, there's nothing wrong with using 192.x and 172.y addresses, this is totally inline with RFC1918.

---

For me it's just an isue of convenience and aesthetic. Also, for design, I find it much easier to get the simplest possible design when you have 3 whole octets to play with.

For example, in this case, he can't summarise his site routes to a single route.
Using 10. addresses, I can use the 2nd octet (either in whole or in binary chunks) to identify a site, following which my design only needs a single route summary to identify each site.

You can use the 3rd octet for function (DATA/VOICE/etc... VLANs) or if the site is a campus, you combine Building number with either the 2nd octet or 3rd, depending on how you are scaling it.

So you might go with
10.2.0.0/16 to identify Site2, 10.3.0.0/16 Site3, etc...
10.2.0.0/20 to Identify "BuildingA", 10.2.16.0/20 "BuildingB"
10.2.0.0/22 can be your "BuildingA" DATA VLANs, 10.2.0.0/24 is Ground, LVL1 10.2.1.0/24, LVL2 10.2.2.0/24, LVL3 10.2.3.0/24
10.2.8.0/22: 10.2.8.0/24...etc... can be your "BuildingA" VOICE VLANs.

It's not just routing, this also simplifies security, and because it's logical, you reduce your risk due to the human factor and simplify support.