Faking a subet

[dbronco]

I recently posted requesting help to be able to route to a camera without a gateway https://community.cisco.com/t5/routing/camera-without-a-gateway/m-p/5159505 and am now able to ping this camera across a different subnet. 

The trouble I'm having now is with the program needed to view this camera -  it won't connect to the camera because it's not on the same subnet. I understand this sounds silly but I'm out of ideas; is there any way to essentially "trick" either device to think they're on the same subnet? 

The camera is at Site B on VLAN 20 with ip proxy-arp now enabled 

The viewing client is at Site A on VLAN 10. The PC connected here can ping the camera but the software won't find it. 

I'm using Catalyst 9300s on 17.09.04a

[David Ruess]

Are you unable to use routing? Like a routing protocols thats responsible for getting IPs on different subnets to other subnets. You can use OSPF, EIGRP, IS-IS, or even static routing.

-David

[dbronco]

I have EIGRP configured and can ping the camera across the subnet, so the routing is working. But the software doesn't like that its running on a different subnet. I've also reached out to the manufacturer to hopefully fix this with them. I was just hoping that there was another workaround that someone knew

[David Ruess]

YOu could possibly use NAT to NAT the IP address to make it seem like its on the same subnet. I believe it would be destination NAT but not 100% sure on that. If this is a limitation of the program/software, then the manufacturer may be the way to go.

[dbronco]

Thanks for bringing this up. I haven't done anything with NAT except talking about it in classes. This gave me the opportunity to configure this in my lab but as I did so, I learned it won't work in our production environment with the way our service provider has our sites configured. I learned a lot today with how this work though, so thank you!

[dbronco]

While waiting on more information from the manufacturer, I did try and NAT this across my lab for the sake of learning how to do it but haven't been successful. I've attached the running config of each. If you get a chance to review and teach me what I'm missing, I'd appreciate it. 

I believe I need I would need to do this on a sub interface to make it work but I couldn't figure out how to do that yesterday. 

The camera IP is 10.10.20.150, connected to Lab_Wall. I tried to NAT it to 10.10.10.150 in the configs. 

[Joseph W. Doherty]

Responding from my phone, so haven't (yet) seen your attachments, but I suspect for NAT to work it may need to be two way.  I.e. both hosts may need to seen with a local same subnet IP.

[Giuseppe Larosa]

Hello @dbronco ,

likely the camera discovery in the software would like to use some form of multicast. Ask the camera vendor for this.

If needed you should enable IPv4 multicast routing on your network using PIM Sparse Mode on all the routers and interfaces on the path ( including backup paths)

If the camera sends the traffic stream using multicast address it is very important to check the IP TTL used: if the default TTL is 1 the traffic would be limited to a single subnet and it could not be multicast routed to a remote destination because routers cannot increase the TTL.

You can check this with a packet capture.

You may need to configure the camera to use an higher value like 16.

Each multicast router on the path will count as one hop as it happens for unicast traffic.

Hope to help

Giuseppe

[Joseph W. Doherty]

Giuseppe raises an excellent point, multicast might be involved.

However, as the other posting describe camera was very basic, requires a "dedicated video client", and that it doesn't even allow for a gateway to be defined, I think the odds are against it using multicast, but it may.  Since it also doesn't even set an IP with a mask, either it's using classful addressing rules, and/or it might be using broadcast rather than unicast or multicast.

Did anyone, along the way, mention how useful a packet capture might be?

[dbronco]

I confirmed with Wireshark today that TTL is 128 and the camera is sending UDP. Great though, I appreciate it. 

[Joseph W. Doherty]

Sending that UDP to what destination address?  (Probably the requesting client's, and if so, negates using multicast or broadcast.)

[Giuseppe Larosa]

Hello @dbronco ,

check the destination address . Multicast IPv4 addresses are in the range 224.0.1.0 to 239.255.255.255

there are no subnets  and the range 224.0.0.X is link local and it cannot be muticast routed.

if the destination address is unicast you don't need to setup multicast routing but it it is you need it as I have explained in my previous post on this thread

Hope to help

Giuseppe

[dbronco]

Correct, its UDP directly to the client. No multicast involved. 

I'm in a class this week but hope to hear from the manufacturer soon and will update the thread with a solution. Thank you

[Joseph W. Doherty]

It's possible application isn't designed to use L3 at all.  I.e. it really needs its communicating devices in the same L2 domain.

If that's the case there are ways to extend L2 over L3, but that is something we want to avoid, as it negates the purpose of L3.

Two ways to minimize the impact of an extended L2, you create an extended L2 domain only containing such devices or you logically only extend L2 for the app's traffic.  (Or, just get video equipment designed to run across L3.)

[dbronco]

We're waiting on the a response from the advanced tech team on being able to configure the network settings for the camera. I appreciate all the suggestions and support on this.