Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1594
  • Last Modified:

Calling all Cisco Experts - Got a good one for you!

I've been scratching my head over this one for a few weeks and can't quite put my finger on a solution. I need to bounce ideas off the crowd here...

Situation:
Server sitting on 172.16.2.x subnet receives updates from GPS transponders in multiple vehicles whenever they move
Server broadcasts updated position information in custom "PDU" packets in local subnet broadcast 172.16.2.255/udp port 3000
Server#2 receives broadcasts and updates database with web front-end

So far, so good.

Now, I have a p2p ISDN connection to this network from another network that is 10.1.1.x
Routing between the two sites is not a problem. I can access the web front-end and I can see the vehicle positions as they move.
What my developers *want* is to see the "raw" PDU packets on the 10.1.1.x LAN so that several other applications can pick up the same information and update themselves accordingly.
What I *have* is a java wrapper running on Server #2 that captures the broadcast packets, and sends them through a tcp socket connection (port X on one side --> port Y on the other side) to another host on the 10.1.1.0 subnet that can then re-send them on the LAN as 10.1.1.255 packets. This sort of works, but is kludgy at best.

What I have tried to do was to use NAT on the 172.16.2.1 interface, sort of like this:
 ip nat inside source udp 10.1.1.255 3000 172.16.2.1.16 3000  {where .16 = router interface}

Even with ip directed broadcast enabled
Even with ip forward-protocol udp 3000  enabled
Debug ip udp - I can see all the packets destined for 172.16.2.255/3000 whiz by..
Nothing. Nada. Zip. Zilch shows up on the 10.1.1.x side..

Now, if my remote side was, say, 10.10.2.0, we could simply change the broadcast mask for the PDU packets to 10.255.255.255 and I could route them to the other side, no problem. We do that all the time. This situation is unique in that we *cannot* change the IP subnets on either side.

Anybody have any ideas how I can propogate/re-generate these broadcasts across subnets?


0
lrmoore
Asked:
lrmoore
  • 11
  • 4
  • 2
  • +5
2 Solutions
 
harbor235Commented:
Youo need to enable a couple of things:

1) ip forward-protocol udp 3000  enabled
2) ip helper-address <address of the router interface forwarding to>

Here is a good reference doc:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017d169.html#wp1084408

harbor235
0
 
lrmooreAuthor Commented:
Thanks, harbor235,
1)If you read my post, I already have ip forward-protocol 3000 enabled
2) ip helper-address .... hmmm....

All of the following conditions must be met in order for a UDP or IP packet to be helpered by the ip helper-address command:
•The MAC address of the received frame must be all-ones broadcast address (ffff.ffff.ffff) <<== I don't know about this one, but I'll check with a sniffer

•The IP destination address must be one of the following:
 all-ones broadcast (255.255.255.255), <<== nope
 subnet broadcast for the receiving interface, <== 172.16.2.255 = OK
 or major-net broadcast for the receiving interface if the no ip classless command is also configured. <== would have to be 172.16.255.255 = nope

•The IP time-to-live (TTL) value must be at least 2 <== I'll have to check this, too
•The IP protocol must be UDP (17). <<== OK
•The UDP destination port must be for TFTP, Domain Name System (DNS), Time, NetBIOS, ND, BOOTP or DHCP packet,
<<<or a UDP port specified by the ip forward-protocol udp global configuration command>>>  == OK

I dodn't think that ip helper-address would need to be specified as long as I had the forward protocol configured, and ip directed-broadcast enabled on the interface..



0
 
harbor235Commented:
lrmoore,

I would try the ip-helper command directed to the host you want the brodcast traffic to hit. Yoou can configure multiple ip-helper commands per interface
for multiple servers.

You guys always catch me on not reading the entire post, but its hard getting any questions to answer with you around. ;}



harbor235
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
pedrowCommented:
<sigh>
dang developers....

So, as long as we're talking about unrealistic developer ideas injected into our world of logic and order, I wonder how something like this might work:
What would happen if you used a static route to back up your static nat translation, or perhaps instead?

i.e.
ip route 10.1.1.255 255.255.255.255 <next hop>

Since we're talking udp, it's not like there's state involved...you could probably push the packet along to it's destination. Maybe adding a secondary ip address on this server's interface might help it.

The other option, which might be kinda ugly is doing something like a l2tpv3 tunnel to bridge the lan across the wan. You'd do it in conjunction with dot1q tagging, which you could probably do on the remote host. We had to build those out for customers when we were migrating their colocations between datacenters...It worked well in our environment, but I've never done it over isdn and smaller types of equipment. I haven't done it in a few years, so maybe it's supported on more platforms now.

 
 
0
 
lrmooreAuthor Commented:
>its hard getting any questions to answer with you around
LOL!  Don't worry, work is starting to pick up the pace and I have *no* internet access at this gig. There's room for you here!  Everything I have to do at work is from rote memory because I can't hop on the Internet and lookup anything in real time. Test what I can, do what I can, take good notes, go home and research. I don't have anyone else around that can even spell Cisco and their eyes glaze over if I try to explain what I'm doing....

I'll try with the ip helper-address with a broadcast
  ip helper-address 10.1.1.255

I've not had to do that before in the same situation if the remote side is same class A network and can use a classful broadcast, just enable the forward-protocol and ip directected-broadcast.

I'm thinking that the ISDN link, not being a broadcast medium may have something to do with it..

I've also thought about assigning a secondary 10.x.x.x ip address to the router interface, and to the server itself, but the programmers said it would take a major rewrite of the application to be able to 'choose' which assigned address to use as the broadcast, and/or to use them both at the same time...


0
 
JFrederick29Commented:
What about using bridging on the ethernet and BRI interface of the local router and on the ethernet and BRI interface of the remote router, then, assigning addresses from the 172.16.2.x subnet to the remote router interface (secondary) and the server as a second address.  If you use the broadcast keyword on the ISDN interface, broadcasts should be bridged/forwarded to the remote LAN, shouldn't they???

Maybe some useful information here:

http://www.cisco.com/en/US/tech/tk801/tk379/technologies_configuration_example09186a008009433e.shtml
0
 
grbladesCommented:
I asked a friend to have a look at your question as I haven't done much in this area. This is his response :-

I might be missing the point....but

"What I have tried to do was to use NAT on the 172.16.2.1 interface, sort of
like this:
 ip nat inside source udp 10.1.1.255 3000 172.16.2.1.16 3000  {where .16 =
router interface}"

***Why 10.1.1.255  isn't this supposed to be the source address?????

Surley the broadcasts are sourced from address 172.16.2.x ???
And addressed to 172.16.2.255?

So shouldn't the nat read something like:

ip nat inside source route-map PDU 172.16.2.16 3000

access-list 101 permit udp  host 172.16.2.x host 172.16.2.16

route-map PDU permit 10
 match ip address 101


Not sure where to spec the ports (maybe on the ip nat line, maybe in the
access list, maybe both...)
0
 
lrmooreAuthor Commented:
Thanks for popping in, guys!
I've thought about bridging, but I don't think that's an option because of the two different network subnets that can't be changed. Even if we widen the broadcast mask on the far side to 172.16.255.255, with a bridged connection the packets would be seen on the 10.1.1.x subnet as raw 172.16.255.255 broadcasts and will be ignored.

grblades, trust me, the nat is correct the way I have it set up. Same way you set up a router if the 172.16.2.16 interface is your "public" IP... to map a private mail server to public ip:

 ip nat inside source static tcp <private> 25 <public> 25

  ip nat inside source static udp <private_broadcast> 3000 <public interface> 3000

I'm simply trying to use the 10.1.1.255 broadcast address as the private IP.. I've never tried using a broadcast address as the inside host, but thought I'd give it a try....
I have also tested to a specific host, 10.1.1.29, and that didn't work either....

0
 
JFrederick29Commented:
But, if the server on the 10.1.1.x subnet has an interface with a 172.16.2.x address, it should listen and process the bridged broadcasts.
0
 
lrmooreAuthor Commented:
Can't do that. I don't control the 172.16.2.x subnet and I need to propgate the broadcast to the 10.1.1.x LAN so that multiple hosts on 10.1.1.x see 10.1.1.255 broadcast.

0
 
pedrowCommented:
more nat possibilities?
ip nat inside source udp 10.1.1.255 3000 172.16.2.255 3000

since the router isn't seeing a packet destined for it's specific interface (.16), maybe NAT is failing because it's not really seeing a match.

Were you seeing translations?

0
 
lrmooreAuthor Commented:
Never saw a translate...
I didn't think about 172.16.2.255, but I can sure try it...
0
 
lrmooreAuthor Commented:
Well, I changed the nat statement to

ip nat inside source static udp 10.1.1.255 3000 172.16.2.255 3000
Added ip helper-address 10.1.1.255 to the Lan interface
Added an access-list
  access-list 109 permit udp host 172.16.2.65 eq 3000 any
  access-list 109 permit icmp host 172.16.2.65 any
  access-list 109 permit ip host 172.16.2.104 any

=dot 65 is the udp broadcast server
=dot 104 is the web front-end

access-list 9 permit 172.16.2.65
debug list 9
debug ip udp


Unfortunately, at the time I was actually there, either the process on the server crapped out or both servers were down because I couldn't even ping either one from the router (before I even applied the acl 109) and never saw a broadcast... one of the progarmmers was on his way over there to see what was going on. Maybe I'll get to try again tomorrow...

On a side note, I fired up Ethereal and found a whole bunch of local LAN broadcasts between two hosts that I wasn't expecting. 192.168.64.111/8000 <--> 192.168.64.112/8000
&(*&W#<!! develpers just make up their own network and plug them into the switch... "just testing" ...
I'm with Pedrow... <sigh>
But, hey, I look at it like this
1) I'm employed
2) I'm not bored
3) I get to play on EE and call it "work" and get paid for it!

0
 
MarkDozierCommented:
Is it at all possible tha the issue is the jave wrapper. is ti causing it to exceed the MTU size.
0
 
srikrishnakCommented:
wooo....tons of information for me here to improve my cisco knowledge...
0
 
lrmooreAuthor Commented:
Mark,
No. The java wrapper is working as a temporary workaround.
Thanks for thinking about it, though..

0
 
pedrowCommented:

>  wooo....tons of information for me here to improve my cisco knowledge...

wellllll, perhaps...in a rube goldberg sort of way... ;)

I guess you could say we're trying to use standard methods in non-standard ways, and should be predicated with some sort of disclaimer. In fact, if we figure out a solution, it should probably get some sort of negative flag so as to never show up under the EE 'hot solutions' section...




0
 
ruddgCommented:
lrmoore, it seems to me that the best solution would be to broadcast the packets to 255.255.255.255 rather than any specific subnet -- this would enable the default use of 'ip forward-protocol' and 'ip directed-broadcast' commands without the need for NAT entries.  I have never used directed broadcast features for packets that were not either directed at specific remote subnets or *everything* -- so I cannot offer much help with the NAT problem.  My best guess is that your problem lies in that step.  I do not think that the 'ip helper-address' command will contribute to the goal in this case (but of course I could be wrong ;-)  Neither can I lab up an experiment at the moment because my gear is serving as an emergency solution for a customer... sorry not to be of more use.
0
 
lrmooreAuthor Commented:
>Neither can I lab up an experiment at the moment because my gear is serving as an emergency solution for a customer
LOL! So is mine! Poor budget planning always turns into an "emergency" need for the stuff we've been telling them they need to purchase for months and just haven't gotten around to it...

The all 1's broadcast may be do-able... I'll check with the developers.  Thanks!
0
 
MarkDozierCommented:
"I guess you could say we're trying to use standard methods in non-standard ways, "
This is noramlly called inovation or product devolopment.
0
 
pedrowCommented:
awww...c'mong lrmoore....didn't you implement some changes on Friday before mother's day?
0
 
lrmooreAuthor Commented:
Well, actually... I did have to remove the ip helper-address. For some odd reason their local clients weren't getting IP addresses.... evidently the router is quicker to proxy than the server is to offer sometimes... oops...
0
 
lrmooreAuthor Commented:
Sorry for the delay.. took some vacation and had a little family reunion of sorts..
Will be getting back on this today/tomorrow.

In the meantime, can I get some of you smart guys to take a look at this one?
http://www.experts-exchange.com/Networking/Q_21414930.html#14009366

Thanks!
0
 
lrmooreAuthor Commented:
YAAAHOOOOOO!!!!!

Here's what did it.....

1) developers changed broadcast to 255.255.255.255 to UDP port 3005

2)
 ip forward-protocol udp 3005
 ip nat inside source static udp 10.1.1.255 3005 172.16.2.255 3005
 
No "ip helper-address" required.

Gotta split this with ruddg for the all 1's broadcast tip, and pedrow for the tip to nat the broadcast address of the interface
0
 
ruddgCommented:
Cool! :-)
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 11
  • 4
  • 2
  • +5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now