TR Forums

What I have:

HP A5120-48G EI (JE069A)
Dell PowerConnect 6248P
SonicWall NSA 4500 (router/firewall/content filter/magic box)

Technically I have 3 of the HP switches in a stack and 2 of the Dells in a stack, but for the purposes of setting this stuff up it's just 3 vendors and 3 models we have to worry about.

Ok, my understanding of VLANs is shaky. When I refer to "I" I mean the network at 192.168.100.x. Here's what the physical connections look like:

Internet
|
SonicWall
|
HP --- servers and workstations 192.168.100.x
|
Dell --- pbx and voip phones 192.168.60.x (not using SIP, have two PRI going directly into the PBX)


Now in the old days, I had this:

Internet
|
SonicWall
|
HP (old stanky switch) --- servers and workstations 192.168.100.x
|
VLAN to old pbx and stanky old phones 192.168.50.x


There was the default VLAN and the phone VLAN, the HP switch had routing enabled and 192.168.50.1 assigned to the phone VLAN interface, the SonicWall had a routing rule to dump everything going to the 192.168.50.x subnet into the HP switch and things worked.

On the new setup, I initially fumbled my way to the same thing. The new HP switch had the 192.168.60.1 gateway for the phone VLAN (VLAN 30) and the Dell had various horrible things done to make it talk to the HP. So it was like thus:

Internet
|
SonicWall
|
HP --- 192.168.100.x --- HPstank --- 192.168.50.x (keeping old phone server around for access to call recordings)
|
VLAN 30 192.168.60.1 interface on HP
VLAN 30 tagged port
|
Dell --- 192.168.60.x


I started to get some crappy call quality and thought maybe it's because the VoIP phones have to go from the Dell to the HP to get routed to the PBX and that's over 1 Gbps. Not like the PBX is on anything faster to the switch but hey. I got the Dells and physically isolated the VoIP phones and PBX from the network to minimize any drop in quality from network contention by running them all piggybacked on the regular data connection. So anyway, what I want to do is this:

Internet
|
SonicWall
|
HP --- 192.168.100.x --- HPstank --- 192.168.50.x (keeping old phone server around for access to call recordings)
|
VLAN 30 tagged port
|
Dell --- 192.168.60.1 interface on Dell --- 192.168.60.x


That way everything VoIP-related stays inside the Dell switches. Now, however, I can't access the PBX servers on the Dells. Phone system works fine. Looking at this written out, the link from HP to HPstank doesn't have a tagged/trunk VLAN and it works fine. Maybe I need to elimate the tagged port between HP and Dell? I can access the Dell on the default VLAN 1 management IP just fine so the switch itself is still connecting to the HP, just maybe not the VLAN? And to clarify, not using SIP at all, I have two PRI going directly into the PBX so this is all about getting the PBX managed from the "normal" network.

Any ideas or suggestions? Network admin work is not my area of expertise. I was a CCNA 15+ years ago and haven't touched anything since so I'm waaay rusty on this kind of stuff, especially the CLI. I've mainly been doing stuff via web management thus far. I would call the respective support lines, but my experience in setting up the initial VLAN configuration was thus:

SonicWall - we are a bunch of Indians and will always sound irate and don't want to help you the device cannot do what you are asking do not bother us thank you goodbye (after 45 minutes of transferring a few times and taking down the wrong information multiple times)
HP - oh that's an H3C switch, we don't know how to do anything with those. We'll offer suggestions if ya want and we can discover things together! (US-based, nice folks)
Dell - well that should be working, dunno why it ain't. (US-based, nice folks)

I Googled my way into getting things working, manually change port VLAN mode to "general" and frame type to "admit all" on the Dell for instance, but I'm stumbling in the dark with a lot of this stuff.

Internet
|
SonicWall

I'm not sure if the Sonicwall really is the culprit here, but in my experience Sonicwalls and Voip are a bad, bad, bad idea. It might work if you sacrifice three goats under a waning crescent moon while balancing on a floating log using a pair of left handed kiddy scissors.

At the CLEC/ISP I work for, if a customer wants SIP trunks from us running through their SonicWall we will tell them that making it work is entirely on them and offer as an alternative to rent a Cisco 2621 from us to route their Voip from an extra public IP to thier internal voip network.

I have never understoot the appeal of Sonicwall gear.

BTW, if anyone is curious, HPstank is a HP ProCurve 2848 (J4904A) where the PSU blew out but luckily I have a HP ProCurve E600 RPS (J8168A) redundant power unit that's running it now. It is a pretty ghetto thing to behold. When I get this new phone VLAN working as intended I'll probably just change the IPs of the old pbx and put it on the Dell.

Not using SIP at all. Two PRIs are coming in direct to the new PBX, it then connects to VoIP phones. So the only VLAN craziness is related to management of the PBX from the "normal" network. If I can use the Dell as a router for this stuff, I can take the route off of the SonicWall and remove it from the equation entirely. OP edited to clarify.

Can the PBX accept a trunked connection with both vlans on it straight off the Dell and then be able to talk to both networks?

Just to make sure I'm following this correctly, VLAN 1 is native, and VLAN 30 is being used for VoIP traffic? Are you using dot1p on the switches, or dot1q? The PBX might not recognize a dot1q trunked connection, but it *should* (in theory) be able to accommodate a dot1p as an access port.

Scrotos wrote:

Not using SIP at all. Two PRIs are coming in direct to the new PBX, it then connects to VoIP phones. So the only VLAN craziness is related to management of the PBX from the "normal" network. If I can use the Dell as a router for this stuff, I can take the route off of the SonicWall and remove it from the equation entirely. OP edited to clarify.

You might be able to replace it with a NetVanta 6000 series.

Hz so good wrote:

You might be able to replace it with a NetVanta 6000 series.

We have too much tied in with the SonicWall to want to replace it on a whim.

yokem55 wrote:

Can the PBX accept a trunked connection with both vlans on it straight off the Dell and then be able to talk to both networks?

Hz so good wrote:

Just to make sure I'm following this correctly, VLAN 1 is native, and VLAN 30 is being used for VoIP traffic? Are you using dot1p on the switches, or dot1q? The PBX might not recognize a dot1q trunked connection, but it *should* (in theory) be able to accommodate a dot1p as an access port.

So all my phones are in the 192.168.60.x network, too. I have 50-ish ports used on the Dell all on that network. There's only 1 connection from the Dell to the HP/rest of the network. VLAN 1 is whatever the default was for both the HP and the Dell, I haven't done anything to that really. VLAN30 is the phone/VoIP one. Plus, the PBX has to talk to a few other components via IP on the same phone network, call recorder, T1 and analog blades, etc.

I see that "dot1p" and "dot1q" are hip shorthand for IEEE 802.1P and IEEE 802.1Q:
http://en.wikipedia.org/wiki/IEEE_802.1p
http://en.wikipedia.org/wiki/IEEE_802.1Q

I honestly don't know. I'll have to look into that and get back to you.

Scrotos wrote:

I see that "dot1p" and "dot1q" are hip shorthand for IEEE 802.1P and IEEE 802.1Q:
http://en.wikipedia.org/wiki/IEEE_802.1p
http://en.wikipedia.org/wiki/IEEE_802.1Q

I honestly don't know. I'll have to look into that and get back to you.

Dot1Q is the standard trunking protocol, so if you want multiple VLANs to cross a trunk link, you'd use that. It basically adds a 32-bit "shim" to a frame (and recalcs the CRC) that carries the VLAN tag information, so frames for VLAN 30 stay on VLAN 30, even though the trunk might be carrying traffic for 10 other VLANs.

Dot1P is a slightly different protocol. It does CoS/DSCP, but it also allows VoIP and data to share a non-trunk access link. I dunno how the HP and Dell set theirs up, but in Cisco-land you'd just issue "switchport voice vlan [#]" and it automagically puts data on the native VLAN, and all voice traffic on the vlan you designated. If your PBX can't handle a dot1q trunk link, maybe you'd have to set it up as a dot1p access link?

I've got another thought. What model dell is connecting to the PBX via PRI? And what model PBX are you using?

Just dawned on me that if the ISDN PRIs are routed interfaces, VLAN information won't traverse than. According to the Cisco enterprise model, VLANs should really be used in the lower layers (L2 connections primarily), but routed L3 interfaces should be used higher up, so that VLAN tagging gets dropped on a routed interface.

It's been many moons since I've used a dedicated PBX with fractional T1s, and am used to devices that include SIP engines in hardware, so I could easily be wrong here.

But since VoIP traffic is successfully crossing to the PBX, but the Native VLAN isn't, it sounds like the PBX is stuck accepting connections only from VLAN30. To me (in my limited ability), it seems like if you can get the PRIs set into some type of switching mode that accepts both Native VLAN 1, and VoIP VLAN30, you should be golden.


A little more info would be greatly helpful. Can you capture some debug messages from the Dell and the PBX?

Also, have you created SVIs for each VLAN, with appropriate IP addrs set? Could help. And you made sure the Native VLAN wasn't administratively brought down? I've seen that happen on 2950 and 3550 cisco switches before. Is there no OOBM (Out of band management) setup you can use? I know I've done that on plenty of Adtran DSLAMs, SONET muxers, and CLEC aggregators. OOBM interfaces are on completely separate network from the chassis backplane and line cards. And you made sure that all the intermediary switches are set to trunk VLAN1 and VLAN30? If you're missing a VLAN on the opposite side of the trunk, that VLANs frames get dropped.

/Throw enough stuff at teh wall, and something is bound to stick.

Scrotos wrote:

I started to get some crappy call quality and thought maybe it's because the VoIP phones have to go from the Dell to the HP to get routed to the PBX and that's over 1 Gbps. Not like the PBX is on anything faster to the switch but hey. I got the Dells and physically isolated the VoIP phones and PBX from the network to minimize any drop in quality from network contention by running them all piggybacked on the regular data connection. So anyway, what I want to do is this:

Something else, do you have mls qos enabled on the L3 switches, and are the CoS/DSCP fields being trusted by the other switches? It's not unusual for an intermediary switch to overwrite the incoming CoS/DSCP values from another switch. With trust extended, the other switches should comply with the incoming CoS values.

"mls qos" (global config mode)
"mls qos trust cos" or "mls qos trust device [cisco-phone]" (on interface)

/I'm blanking on the MLS QOS trust extend command at the moment.

Hz so good wrote:

I've got another thought. What model dell is connecting to the PBX via PRI? And what model PBX are you using?
...
It's been many moons since I've used a dedicated PBX with fractional T1s, and am used to devices that include SIP engines in hardware, so I could easily be wrong here.

I'm pretty sure these are TDM voice PRI's going into the PBX so they aren't encapsulating ethernet or IP packets anywhere and thus can't talk to the Dell switch. These commonly come in from an ILEC or CLEC DS1 circuit or can come in on voip and then get turned into TDM PRI with a device like an AdTran Total Access 9xx device. With 2 PRI's you have 1 signaling channel and up to 47 voice channels. Or if you want a backup signaling channel, you put one on each DS1 and then have 46 voice channels.

yokem55 wrote:

Hz so good wrote:

I've got another thought. What model dell is connecting to the PBX via PRI? And what model PBX are you using?
...
It's been many moons since I've used a dedicated PBX with fractional T1s, and am used to devices that include SIP engines in hardware, so I could easily be wrong here.

I'm pretty sure these are TDM voice PRI's going into the PBX so they aren't encapsulating ethernet or IP packets anywhere and thus can't talk to the Dell switch. These commonly come in from an ILEC or CLEC DS1 circuit or can come in on voip and then get turned into TDM PRI with a device like an AdTran Total Access 9xx device. With 2 PRI's you have 1 signaling channel and up to 47 voice channels. Or if you want a backup signaling channel, you put one on each DS1 and then have 46 voice channels.

Ah, ok. I've zero experience with TA-900s. Just TA-5000s, TA-500s, TA-300s, OPTI-6100s, and the NetVanta series (up to 6000 series), so I was unaware of that.

Learn something new every day!

Speaking of ADtran, have you ever run across a problem with their S-tags getting dropped/ignored on Cisco L3 switches? I ran into that issue at a military installation, handed it off to Adtran support, and never got a usable workaround. We ended up dragging in a Navy tech, and he fixed it, but neglected to clue us in on what he'd done.

Hz so good wrote:

Speaking of ADtran, have you ever run across a problem with their S-tags getting dropped/ignored on Cisco L3 switches? I ran into that issue at a military installation, handed it off to Adtran support, and never got a usable workaround. We ended up dragging in a Navy tech, and he fixed it, but neglected to clue us in on what he'd done.

Nope. But our TA-5000's are hooked to Juniper EX switches which terminate the s-tags/vlans coming in from the 5000 and route the traffic on layer 3 out the switch to our core router so passing the s-tags through to other equipment isn't a need for us.

yokem55 wrote:

Hz so good wrote:

Speaking of ADtran, have you ever run across a problem with their S-tags getting dropped/ignored on Cisco L3 switches? I ran into that issue at a military installation, handed it off to Adtran support, and never got a usable workaround. We ended up dragging in a Navy tech, and he fixed it, but neglected to clue us in on what he'd done.

Nope. But our TA-5000's are hooked to Juniper EX switches which terminate the s-tags/vlans coming in from the 5000 and route the traffic on layer 3 out the switch to our core router so passing the s-tags through to other equipment isn't a need for us.

Ah. We were limited to interfacing with the Cisco devices installed and maintained by Navy personnel. Only one Navy tech temp assigned to us was allowed to mess with the Cisco devices, since they connected to PSNET, which is off-limits to peons like me.

Hell, all the diagrams and schematics are labelled SECRET, so no wonder I was only allowed to mess with the Adtran gear, and chastising the Schneider Electric folks for trying to use WiFi radios for backhaul, despite there being a blanket ban on all sources of radio signals, due to the fark-ton of munitions at the location. If you wanted a smoke break, you had to find the nearest shelter which was usually waaaaaaay far away from anything that might go boom.

Don't get me started on the "park 1/2 mile away and walk to the building. Don't forget your RAD badges!".

yokem55 wrote:

Hz so good wrote:

Speaking of ADtran, have you ever run across a problem with their S-tags getting dropped/ignored on Cisco L3 switches? I ran into that issue at a military installation, handed it off to Adtran support, and never got a usable workaround. We ended up dragging in a Navy tech, and he fixed it, but neglected to clue us in on what he'd done.

Nope. But our TA-5000's are hooked to Juniper EX switches which terminate the s-tags/vlans coming in from the 5000 and route the traffic on layer 3 out the switch to our core router so passing the s-tags through to other equipment isn't a need for us.

Believe it or not, but most of our TA-5000s either ended up in CLECs as aggregators, or in the Navy job, as controllers/backhaul for DLSAM shelves. The twisted pair we were allowed to use was so bad, we had to bond 8 shdsl links just to meet the minimum bandwidth requirements. And that way for every link, so I got very familiar with using those in a very short time. The Adtran cert program is an utter joke. I learned more onsite in two days, than taking those courses. I even spotted errors the higherups made in the lab config, and got those resolved in short order (snaps suspenders).

Why they wouldn't let us use the dark fiber onsite, I have no clue.

yokem55 wrote:

Hz so good wrote:

I've got another thought. What model dell is connecting to the PBX via PRI? And what model PBX are you using?
...
It's been many moons since I've used a dedicated PBX with fractional T1s, and am used to devices that include SIP engines in hardware, so I could easily be wrong here.

I'm pretty sure these are TDM voice PRI's going into the PBX so they aren't encapsulating ethernet or IP packets anywhere and thus can't talk to the Dell switch. These commonly come in from an ILEC or CLEC DS1 circuit or can come in on voip and then get turned into TDM PRI with a device like an AdTran Total Access 9xx device. With 2 PRI's you have 1 signaling channel and up to 47 voice channels. Or if you want a backup signaling channel, you put one on each DS1 and then have 46 voice channels.

Correct, the T1s aren't being routed anywhere. Here's what the system looks like, more or less:



The T1s come into the blades, then the blades communicate via IP to the main PBX blade. I know it's not a "blade" in the more common HPC or server sense, but it's the best description for these that I have as my configuration actually has them slide into a rack-mount enclosure rather than sit in the standalone desktop thing shown there.

Sorry for the spotty responses; the boss quit with 1 week notice so I've been trying to do too much to keep things running smoothly.