multicast foolishness

This forum is dedicated to the general computer related issues we all come across on a daily basis, such as e-mail/Internet/Operating System/virus/spyware, etc questions & problems.

As we are primarily a radio discussion group, your mileage may vary on the responses.

Moderator: Queue Moderator

multicast foolishness

Postby Bill_G » Sat Mar 16, 2013 8:47 am

I'm putting in a simple two position Telex CSoft replacement for a 1990 CC2+ system. Pretty straight forward. Five base stations per site, four sites, plus SIP phones at dispatch. They kept their T1 microwave links to each site. So, everything is staying at dispatch. Essentially, a Telex CEB replacing a MOT CEB. No great mysteries. Works perfectly.

The hard part is the two laptop remote dispatch requirement. ie: two Panasonic Toughbooks so they can dispatch from an EOC, or their kitchen table in their jammies, through the Intertubes. It's not my first time at the rodeo. I've done it before. But, it is always like pulling teeth. I always have to beat it into submission with blunt objects, stone knives, and bear claws. This time was no different. And it is because of multicast. I wish I understood this better.

I've used Cisco VPN, and Juniper VPN. Royal pains to make work, and I've had to hire it out to "experts" to build a working tunnel config. This time I decided to use what Telex recommends - DCB product. It's an appliance intended for techs like me with little expertise in layer 2 / layer 3 devices. Supposedly almost plug and play. Punch in the addressing and passwords, and away it goes! Not.

If I configure the server and client as described in their docs, I have ip connectivity but not udp on the Toughbooks running Win7Pro. I can ping. I can web into the Telex boxes to look at their configs. I can web into the DCB box to work on it's config. But! No multicast packets pass. CSoft and Telex System Manager just stare at you. No audio. No tx/rx. They are stones.

On the other hand, if I enable DHCP in the client virtual adapter (the DCB client creates a virtual network adapter with a static ip you assign), and have DHCP disabled in the server (the default), Windows gives the client adapter a stateless address (169.254.x.x). Multicast works. Tx/rx good. But! No ip. No ping. No http. You can't get to the boxes except through System Manager which works from the multicast level. Very odd.

Of course Telex says "Not our box - talk to DCB", and DCB says "Never heard of that before. Your configs are wrong. Check your configs." That was helpful guys. Great idea - check my configs. Why didn't I think of that? Holy Cow. Here I am again, and this time I'm using something that no one is expert at so I can't farm it out. I gotta figure it out on my own.

I rub two brain cells together hoping for some heat, and all I get is it seems like DCB or Windows were doing packet filtering. The DCB box has some Advanced / Tunnel / Filter settings, and they all say "filters disabled". Fine. Let's enable them. You get three choices - pass packets, drop packets, and filter disabled. Let's choose pass packets. Save. Reboot. Wait. Whoa! Holy Cow - it's working on this laptop. It's working on the other laptop. Yippie! Let's put it back to the defaults of filters disabled and see what happens - it's broken again - Yea! Let's pass packets again - Yea! It's working. Leave it alone.

Hello DCB - how come? "I hate to disagree with a customer, but that's impossible. Check your configs." Okay. Check what? (crickets)

I'll take a win anyway I can. I'm not proud. The two Toughbook laptops work. All functions good. Who cares if the product manual is wrong. It's not the first time that's happened to me. Let's set up my company Win7 Acer laptop so I can support their system remotely. And guess what? It doesn't work. Here we go again with a static ip with ip connectivity but no udp, or a stateless address with udp but no ip.

Toggle all the server filters back to disabled, and now the Acer still doesn't work, but the Panasonics do. Wait a minute. Restart all three machines. None of them work now. Windows in the Toughbooks remembered something about getting to the server. Rebooting the PC's killed that. Toggle the filters again. Panasonics work. Acer still a stone until I give it a stateless addy.

Enable DHCP in the server on the trusted side. Enable DHCP in the Acer virtual adapter. It gets an addy in the correct range ... and ... it works. IP and udp. CSoft walks and talks. System Manager finds all the devices, but I get timeout errors when I try to read them. I can web into them, but I cannot fetch their configs in SM. Kill CSoft. Now SM can't see anything. No devices to be found. I can ping them. I can web in. But, System Manager says "nope, sorry, nobody there". Fire up CSoft. "Oh wait! My bad - there are lots of Telex devices now. Watch me load up the screen". Kill CSoft. SM goes dark again.

I had to put it down. That is enough foolishness for today. I have to have different configurations for different PC's running slightly different versions of Windows? And the configurations don't follow the simple rules of an appliance as the OEM promised? Oy ve.
User avatar
Bill_G
 
Posts: 2518
Joined: Thu Sep 17, 2009 5:00 am
Location: Portland, OR

Re: multicast foolishness

Postby Bill_G » Sun Mar 17, 2013 5:43 am

Just for S&G's I installed everything on my home laptop (HP/AMD with Vista Home), and got the same results - a stateless address has multicast capability but no ip, and a stateful addy has ip but no multicast. I have no idea what I fixed that made the customer Toughbooks work correctly. I think I'm going to have to buy another UT3302, and play with it until it makes sense.
User avatar
Bill_G
 
Posts: 2518
Joined: Thu Sep 17, 2009 5:00 am
Location: Portland, OR

Re: multicast foolishness

Postby Jim202 » Mon Mar 18, 2013 4:01 am

Bill_G wrote:Just for S&G's I installed everything on my home laptop (HP/AMD with Vista Home), and got the same results - a stateless address has multicast capability but no ip, and a stateful addy has ip but no multicast. I have no idea what I fixed that made the customer Toughbooks work correctly. I think I'm going to have to buy another UT3302, and play with it until it makes sense.



Have you tried to talk to the people at Telex. In the past I have found them to be very helpful with some problems I had.

Jim
Jim202
 
Posts: 3122
Joined: Sun Sep 09, 2001 4:00 pm
Location: New Orleans, LA.

Re: multicast foolishness

Postby Bill_G » Mon Mar 18, 2013 4:52 am

Jim202 wrote:
Bill_G wrote:Just for S&G's I installed everything on my home laptop (HP/AMD with Vista Home), and got the same results - a stateless address has multicast capability but no ip, and a stateful addy has ip but no multicast. I have no idea what I fixed that made the customer Toughbooks work correctly. I think I'm going to have to buy another UT3302, and play with it until it makes sense.



Have you tried to talk to the people at Telex. In the past I have found them to be very helpful with some problems I had.

Jim


Yes I did, and their short answer was "not our product". Their longer answer was they suspect a configuration issue. But, when the config is so simple, how do you get it wrong? You drop in some addressing, some session passwords, some user passwords, save it, and go. They do connect. The tunnel exists at both ends according to the logs. It just has this peculiar behavior of passing one type of packet, but not the other.
User avatar
Bill_G
 
Posts: 2518
Joined: Thu Sep 17, 2009 5:00 am
Location: Portland, OR

Re: multicast foolishness

Postby alex » Mon Mar 18, 2013 12:25 pm

What is between the Telex and VPN box? Is there a cross over cable between the two or is there another network. I would try cross over between the two boxes and see what they do. Multicast is annoying and there is a reason (sadly) that when you do this with the cisco stuff it costs some coin. One suggestion though - if you have the config files from the cisco stuff you can reuse them providing you buy the same equipment. The IP's have changed but the structure of the configs should be similar.



Alex
The Radio Information Board: http://www.radioinfoboard.com
Your source for information on: Harris/Ma-Comm/EFJ/RELM/Kenwood/ICOM/Thales, equipment.
User avatar
alex
Administrator
 
Posts: 5572
Joined: Mon Sep 03, 2001 4:00 pm
Location: Batboard NOC

Re: multicast foolishness

Postby Bill_G » Mon Mar 18, 2013 7:52 pm

alex wrote:What is between the Telex and VPN box? Is there a cross over cable between the two or is there another network. I would try cross over between the two boxes and see what they do. Multicast is annoying and there is a reason (sadly) that when you do this with the cisco stuff it costs some coin. One suggestion though - if you have the config files from the cisco stuff you can reuse them providing you buy the same equipment. The IP's have changed but the structure of the configs should be similar.



Alex


The DCB VPN appliance occupies a port on the switch along with the dozen Telex IP224 boxes and the two dispatch positions. I'm using a low tier unmanaged Cisco 24 port switch to tie it all together. The DCB UT3302 is a bridging device, not a router like equivalent Cisco and Juniper products. So, theoretically it acts as a VPN bridge for a remote device connecting to the switch. Hence the so called simplicity. There are no policies to set. No route tables to build. No gateways to configure. Nada. Plug in the untrusted ip addy, the untrusted gateway (provider device), the trusted addy, the session, tunnel, and user passwords, the level of encryption, and supposedly you are good to go.

I don't think a crossover cable is required since the switch has MDIX as do all the Telex boxes.

I know what you mean about reusing working configs for different customers. I have done that, and it's a great strategy as long as the customer doesn't want to use other functionality in the device. ie: setup the dmz for a web box, or have the tunnels in a ring topology with a failover strategy, etc etc.They find out about the gee whiz things the VPN box will do, and then they want them. I'm just trying to satisfy a secure remote dispatch capability.
User avatar
Bill_G
 
Posts: 2518
Joined: Thu Sep 17, 2009 5:00 am
Location: Portland, OR

Re: multicast foolishness

Postby alex » Tue Mar 19, 2013 6:45 am

Bill_G wrote:The DCB VPN appliance occupies a port on the switch along with the dozen Telex IP224 boxes and the two dispatch positions. I'm using a low tier unmanaged Cisco 24 port switch to tie it all together. The DCB UT3302 is a bridging device, not a router like equivalent Cisco and Juniper products. So, theoretically it acts as a VPN bridge for a remote device connecting to the switch. Hence the so called simplicity. There are no policies to set. No route tables to build. No gateways to configure. Nada. Plug in the untrusted ip addy, the untrusted gateway (provider device), the trusted addy, the session, tunnel, and user passwords, the level of encryption, and supposedly you are good to go.

I don't think a crossover cable is required since the switch has MDIX as do all the Telex boxes.

I know what you mean about reusing working configs for different customers. I have done that, and it's a great strategy as long as the customer doesn't want to use other functionality in the device. ie: setup the dmz for a web box, or have the tunnels in a ring topology with a failover strategy, etc etc.They find out about the gee whiz things the VPN box will do, and then they want them. I'm just trying to satisfy a secure remote dispatch capability.


Well - I think some basic troubleshooting may be in order and may have already been done - but I'll ask anyway.

Take one telex box, use a cross over cable, and plug it in to the DCB box. Put another dcb box back to back via cross over and connect the telex box over cross over cable. You may have to configure the DCB boxes to use static IP's for this test as they wouldn't have a DHCP server for lan.

From there take one side and put the Telex in to switch, the DCB box in to switch, and have it talk to the other DCB box over the switch, cross over to telex. Keep doing test like this slowly introducing other network components. If my first "bench" test of the above configuration fails then you have issues with the setup. Once the setup works on the bench you should be good to go.

I thought of another situation which may be worth looking at - and that is your gateway addressing. What I would do is something like this:

TELEX BOXES [static IP] -> SWITCH/RADIOLAN ->[STATIC] DCB BOX [STATIC]-> LAN ->[STATIC] DCB BOX [STATIC] -> SWITCH/RADIO LAN -> TELEX BOXES [StaticIP]

You may need to use the DCB box as the "gateway" address for all the Telex boxes in the network. Turn off DHCP. I would also look in to if the Telex boxes on each side of the RadioLan are on the same subnet. DCB boxes probably can not route the network interfaces which are the same. One should be 10.0.0.x the other 10.0.1.x.

I'm just thinking of basic network troubleshooting steps here - I do not have either the Telex Boxes or the actual DCB boxes (and have not used either) so I'm guessing. My understanding of the telex boxes is that you handle the IP transport and the telex boxes will talk to each other all day.

Personally - with the Cisco stuff - just tell them that you need two static IP addresses on either end and hook your cisco stuff up and tell them it the routers are dedicated to the radio LAN... no other stuff. If they want to play router then they buy their own equipment to do it. Easier said than done.

You can use two Cisco 2811 w/PVDM-32 cards, 4xE&M cards on each end. You may an IP tunnel between the two and connection trunks and you have 8 E&M ports between locations A&B. Happy to give you the configurations on the side or assist if you would like.... but they use UDP instead of Multicast and this helps but does add some minor delay (which if you are going over someone else network or the internet becomes a "who cares" scenario. I am almost 90% sure I can do the same thing with v.24 HDLC frames - just don't have the equipment to test this theory out - but I think I can emulate these connections for about $30 an end plus the router (in used equipment $).

Alex
The Radio Information Board: http://www.radioinfoboard.com
Your source for information on: Harris/Ma-Comm/EFJ/RELM/Kenwood/ICOM/Thales, equipment.
User avatar
alex
Administrator
 
Posts: 5572
Joined: Mon Sep 03, 2001 4:00 pm
Location: Batboard NOC

Re: multicast foolishness

Postby JAYMZ » Tue Mar 19, 2013 1:45 pm

If the setup works when you have filters on the servers turned off, have a look at those filters. Are they configurable? Could they (by default) be blocking PIM to remote users outside the home subnet?

I would NOT muck with any of your topology if you have it working with one component (server filters) taken out of it. If you want to emulate it on a computer using Cisco equipment use a free program to do that.. GNS3. If you must troubleshoot a topology that works without those filters (mostly, I know) then take it point by point. Start at the server, connectivity to the border gateway? Border gateway connectivity to the Internet? yadda yadda yadda. Break it down to its individual components and make sure everything is how it should be at each point. Could be something as stupid as not enabling PIM (Protocol Independent Multicast) for transmit over an IPSec tunnel. Or a GRE tunnel is dropping the multicast packet because the IPmc rendezvous point is not set right. All the way down to an IP address/DHCP assignment error.

And if all you need is a site to site VPN tunnel to pipe a dispatch console why not use a couple of Cisco ASA5505s to do that. I did one for an outside customer last week and as long as you have the static IPs on other end a site to site tunnel can be set up in a half an hour. And they are cheap.. you can get them on Amazon for $300 these days.
JAYMZ

"Mom and dad say I should make my life an example of the principles I believe in. But every time I do, they tell me to stop it."
Calvin
User avatar
JAYMZ
 
Posts: 2778
Joined: Sun Sep 09, 2001 4:00 pm
Location: Stony Point, NY
What radios do you own?: Radar Range

Re: multicast foolishness

Postby Bill_G » Wed Mar 27, 2013 5:53 am

It's been a week. We went through acceptance. It all worked. The procedure I wrote for the Toughbooks was easy enough for them to follow, and successfully link up the first time through a wifi.

But!

The system administrator tried to throw in a requirement that *all* support laptops needed to access the VPN after he unsuccessfully failed to connect through the client application. Out of scope. I understand his point, but it is not explicitly stated in the sales contract. He has a newer Dell Win7 laptop with a security suite I'm not familiar with. He spent four hours beating it into submission, and eventually prevailed. OTOH, an older XP laptop he resurrected connected first time, and ran perfectly.

We also ran into odd behavior with the Toughbooks when he installed Verizon wireless broadband cards. Again, out of scope - the contract doesn't state we have to support broadband cards we did not sell. He spent the weekend drilling through the configurations until he got them working. He's not pleased, but he understands why I didn't just volunteer to support everything he wants that wasn't spelled out in the contract. That's what contracts are for.

it is still amazing to me that several different boxes behave differently using the same VPN client. This is the magic I will probably never understand.
User avatar
Bill_G
 
Posts: 2518
Joined: Thu Sep 17, 2009 5:00 am
Location: Portland, OR


Return to Computer/Technical Assistance

Who is online

Users browsing this forum: No registered users and 1 guest