Can't Use Ethernet Extenders For My IP Cameras, IT Against It

Member has mentioned that his IT department is against using Ethernet extenders because BICSI does not approve it.

What to do?


The BICSI way is to use a media converter and fiber. There are arguments to be made for that, especially in exterior runs, since fiberoptic cables are typically not conductive (unless armored). But the main downside is that power is required on the far end, and it's not always easily available.

When standards were written, extenders weren't really available. And in the BICSI mindset, allowing extenders means that worst case someone could just have one central wiring closet and use extenders to get cables where they need to go. That's a logistical nightmare, and I agree, horrible practice. So that's why BICSI would tell you fiber/media converters, or to locate another IDF with a switch/patch panel in between to serve further areas.

For a couple of cameras in a warehouse or big box store or parking lot, though, where it is not practical to locate another IDF somewhere, extend away. I can tell you from experience working in some warehouses where they located cabinets with patch panels and switches in the rafters only to serve 2-3 devices, I'd have preferred the extenders.

Get a new IT department, they're fairly commoditized these days.

I would ask the IT department to point out where BICSI explicitly denies support for Ethernet extenders. I haven't kept up with ALL the BICSI stuff in recent years, but in general they don't really "approve" many things as it relates to running services over the cable plant so much as they tend to stick to recommending standards-based products.

Would the IT department approve media convertors? Would they approve passive bridges? These are the basic components of most Ethernet extenders, there is really nothing fancy or black-art here.

What about if all the extenders terminate on their own switch? Or what if OP uses NVR appliances with PoE ports along with the extenders? That would completely isolate things from the IT department.

I'm also somewhat assuming that OP means twisted-pair based extenders. In that case if they are going to pull a cable run longer than 100 meters it might be offered that those cable runs are terminated on a separate, well-labeled panel, away from the main Cat-whatever cable plant so that those cables don't get accidently deployed as standard Ethernet runs in the future.

Get a new IT department, they're fairly commoditized these days.

That just made my day :)

Can the person who queried build their own network? Assuming a huge network doesn't need to be built it is an easy way to no longer require (as much) IT input. Range extenders may not be needed as much but they are prevalent in our industry. However, the VOIP side of IT has also made use of various range extension methods (e.g. Phybridge) for quite some time.

One thing that can't hurt is to e-mail the Director of Standards at BiSCI, Jeff Silveria (jsilveira@bicsi.org), and ask him to clarify the BiSCI position on Ethernet extenders.

I have asked him several questions and he has always responded within a day, with extremely informational responses!

Here's what he said when asked about Ethernet splicing, for example.

In my opinion, IT people have always overstep their bounds, butting into things that they have no business being in. From the sales process to the install process, the IT people are a royal pain. They overthink everything, and take simple tasks like port forwarding and turn it into common core=.

If the cameras are on their own separate physical network, on their own NIC card in the NVR, then IT needs to keep their hands off. I specifically have a clause in my contract that states if any third party goes tampering or altering any of the equipment, software, settings we install in any way, I will void the warranty.

One IT guy insisted on putting his centrally managed antivirus on the NVR, so I removed it, and made the desktop an image of the contract clause that tells him hands off. He hasnt messed with it since.

One IT guy insisted on putting his centrally managed antivirus on the NVR, so I removed it, and made the desktop an image of the contract clause that tells him hands off.

Does the contract also state that you will assume full liability in the event of a data breach on your network?

In my opinion, IT people have always overstep their bounds, butting into things that they have no business being in.

Having been an IT guy in the past (and still being sort-of IT now), I have to disagree with the "always" part, and at the same time defend their actions: they're the ones whose feet get held to the fire when ANYTHING goes wonky with the network, so it's in their best interest to at least be up-to-speed on ANYTHING network-related going on within their environs.

If the cameras are on their own separate physical network, on their own NIC card in the NVR, then IT needs to keep their hands off.

It doesn't always mean meddling, sometimes the interest is just in knowing what's being connected to their network, even if it's just a dedicated NIC on an NVR. An executive streaming full-bandwidth video to their workstation, for example, could cause issues on their LAN, and is directly related to your setup. At the very least, the IT guys should know where they can go to unplug your uplink until you can do something to throttle the bandwidth.

I specifically have a clause in my contract that states if any third party goes tampering or altering any of the equipment, software, settings we install in any way, I will void the warranty.

That's a pretty standard warranty clause anyway.

Is this a general question? Is this member a security integrator or a member of the IT team? Is the IT department a department of a business the member has a business relationship with? What kind of project requires the use of Ethernet extenders? Is the member on a project that has already begun and is now finding out the extenders or is the member is the design phase of the project?

This is a larger end user in their physical security team. They have multiple instances where they could use Ethernet extenders on an ongoing basis.

I have been in this situation more than I can remember to count; being on both sides, I can respect both points of the use of extenders. What is boils down to in this situation is the proper way of "doing something". Extenders were designed to extend a network segment beyond the network's inherent distance limitation, which is approximately 100 meters (90 meters for a horizontal run). From a network perspective, the proper way in overcoming this limitation is to introduce fiber optics; from the cost side of things, Ethernet extenders could be introduced possibly due to budget constraints.

It sounds like both of these departments do not have a good working relationship; perhaps they need to work on this before the next project comes along. If they do not have a really good working relationship, some things can be done to mitigate any tensions the two department may have. Here in Hawaii, we tend to think about “Aloha” in just about everything we do in life. Aloha which has different meanings, but in the sense that I am referring to Aloha as is peace and compassion. What I am about to explain could be construed as a bribe, but that is not my intent. If you know that a specific individual, business, co-worker, friend, family member, etc. does good, but does not get the recognition they deserve for the work they do, a donut, coffee, and a simple thank you can go a long way. When a department sends out donuts and coffee to a bunch of geeks and praise them with a "Thank You" for all that you do, would probably help out a bit on the next project that comes around that requires approval of the IT Department... just sayin'

If some kind of compromise cannot be negotiated, then management should get involved as it is directly related to OpEx/CapEx (depending on the roles they use in that company). It is cost over specifications and the two managers need to duke it out, and if that does not work, the CIO would ultimately make the final decision.

Extenders were designed to extend a network segment beyond the network's inherent distance limitation, which is approximately 100 meters (90 meters for a horizontal run). From a network perspective, the proper way in overcoming this limitation is to introduce fiber optics;

This statement is really not correct.

Standard twisted-pair Ethernet has a distance limitation of 100 meters, which is based on the fact the Ethernet is a shared-backbone system with a carrier sense/collision detection mechanism. Unlike other technologies (eg: the old Token Ring network standard), devices on an Ethernet LAN do not have a predictable or allocated time for transmitting data, they transmit when they sense a lack of other traffic on the wire.

In order for this system to work effectively, there has to be some way for the system to sense a lack of traffic and put its data on the wire in enough time. This is where the 100M limit comes from, it's primarily based on packet propagation time for the collision-detection part of the Ethernet protocol.

There are other ways to carry data on a network, using the Ethernet protocol on other mediums, or using other protocols on other mediums, that will have different length restrictions and different timing/collision sensing formats.

Distance extenders are typically passive bridges that convert twisted-pair Ethernet signals to other formats. At the base layer there is nothing different between using a fiber based and a copper based solution for extending the length of a network segment, so long as that device does not affect the overall network by skewing the timing of things and causing excessive collisions or other problems.

I would agree that the best way is to use a fiber convertor, but it's not the only correct way.

Standard twisted-pair Ethernet has a distance limitation of 100 meters, which is based on the fact the Ethernet is a shared-backbone system with a carrier sense/collision detection mechanism.

100Mbit Switched Full-duplex Ethernet networks are not limited to 100M by collision domains.

There is only one transmitter per pair.

They are limited by signal attenuation.

Hmmm... Well, I would highly recommend that you disclose your name before you call someone out on their willingness to provide feedback to the community. At least that way, when I can refer back to something, I do not have to refer you as Und 1 Man.

To be honest, I was generalizing. I did not think I had to be that specific on the max length as the presumption was it was a network segment utilizing TCP/IP encapsulated in an Ethernet frame over UTP as it was an IP camera utilizing a Ethernet Extender in 2015.

Standard twisted-pair Ethernet has a distance limitation of 100 meters, which is based on the fact the Ethernet is a shared-backbone system with a carrier sense/collision detection mechanism.

I disagree; let me explain... Wait... Back the bus up... See, here I did not say you were wrong.

I have no idea whom you are, or what skill-sets you have. This is a much more professional way to handle discussions, as some can tend to get into heated arguments on who is right and who is wrong. To be honest, I am not here to prove anything, I only want to make sure that the correct information has passed to the individual(s) that need it.

Moving on:

Since we are in the year 2015, I can safely assume the Ethernet standard that is being used is 802.3-2015, which is utilizing full-duplex. When a segment is operating in Full-duplex, the network segment is no longer limited by the timing requirements like it is with a shared half-duplex network segment, so carrier sense/collision detection mechanism is not factored on a switched network, it is actually turned off.

Furthermore, my generalized statement of "network's inherent distance limitation, which is approximately 100 meters" was in reference not specifically to UTP or any other timing considerations, but the principles of electronics and physics on a communications network utilizing cable. What defines the max distance of the network segment are the Ethernet physical standard (PHY), and the Ethernet Data Link Layer (MAC) which is 100-BaseT (The electrical properties of the link connection and the cable properties). The MAC is the lower sublayer of the data link layer, and the LLC (Logical Link Control) is the upper sublayer of the data link layer. CSMA/CD resides in the LLC of the Data Link Layer, which is what you referenced why there is a 100M limitation on Ethernet over Standard twisted-pair.

I stand by my original answer.. Aloha!

Well, I would highly recommend that you disclose your name before you call someone out on their willingness to provide feedback to the community.

Noted.

I disagree; let me explain... Wait... Back the bus up... See, here I did not say you were wrong.

Say whatever you want to say. My feelings are not going to be hurt if you say I am wrong and back that up with data. I'll be happy to increase my understanding of networking if you can do so.

Since we are in the year 2015, I can safely assume the Ethernet standard that is being used is 802.3-2015, which is utilizing full-duplex.

Personally, I would not assume that the equipment is using a standard which is less than a year old. Espeically when it comes to security gear.

When a segment is operating in Full-duplex, the network segment is no longer limited by the timing requirements like it is with a shared half-duplex network segment, so carrier sense/collision detection mechanism is not factored on a switched network, it is actually turned off.

Not exactly. Yes, collision detection is turned off, but the core protocol is still reliant on timing properties, and the maximum distance (per the spec) is still 100M. And since this whole topic seemed to spring up from an IT department overly concerned with specifications or acceptable devices, I wouldn't recommend running over-length cables and relying on a switched network to be acceptable here. We don't know what equipment is going on the other end of the cable and how that equipment would perform on an out of spec cable run.

Furthermore, my generalized statement of "network's inherent distance limitation, which is approximately 100 meters" was in reference not specifically to UTP or any other timing considerations, but the principles of electronics and physics on a communications network utilizing cable.

Principles of electronics and physics do not limit networks to 100M segments. There are several technologies running on copper cables such as DSL to 10Base-2 that have segment limits much longer than 100M, some in the kilometer range.

Getting into all of the sub-specs of Ethernet could be an entire topic unto itself, so I'll paraphrase a few things.

ALL Ethernet implementations (10Base-T, 100Base-T, 1000Base-T) have a specified max segment length of 100 Meters for twisted-pair cabling. None of the standards are guaranteed to work on longer segments, and equipment is built and tested to the 100M spec.

If a device needs to be more than 100M away from another host on the LAN there are a few acceptable ways to accomplish this:

1) Put a small switch in place. A switch acts as a repeater and will allow you to "extend" a cable in a sense. Note that there are still limitations here, you cannot put 20 switches in place to extend a segment out to 2Km.

2) Convert to an alternate physical carrier, eg: fiber or wireless.

3) Use an "extender" device, which is typically a mini-bridge converting from one signalling method to another. Note that this option has the greatest probability of slowing down the overall throughput of the link.

Note that there are still limitations here, you cannot put 20 switches in place to extend a segment out to 2Km.

Disagree.

Source?

Without manual tuning, STP has a much higher probability of breaking down when you have more than 7 hops/switches between any 2 end points.

This becomes much like the "100M limit", it's not a hard rule, but it is the sort of thing that once you go beyond these values you increase the probability of poor LAN performance dramatically (absent other tuning to accommodate).

Also, these problems won't usually happen right away, they'll crop up in a year when the accounting department suddently adds 12 more people and a another printer, or a video conferencing setup, or some other thing. Suddenly devices that could happily discover and talk to each other will fall offline, or will be slow, and so forth.

If you had a single camera and wanted it to talk to an NVR, you might be able to go 20 hops with cables of 200M each. Or you might be able to get a single run of 300M to work fine. But in the next site, the same setup may not work, for a multitude of reasons.

Without manual tuning, STP has a much higher probability of breaking down...

STP is irrelevant here. There are no multi-path considerations, because there are no loops.

You set the example: 20 switches, each 100M apart.

Also, these problems won't usually happen right away, they'll crop up in a year when the accounting department suddently adds 12 more people and a another printer, or a video conferencing setup, or some other thing.

Equivocation.

You post said 'cannot' due to a 'limitation'. If you really meant instead that you would 'increase your probability of poor performance' or that you 'can for year or so' , that is a much different statement.

Or you might be able to get a single run of 300M to work...

No, I can't. The longest I have heard anyone even claim is 170M. And even that's a stretch....

I'm not trying to debate Ethernet to the nth degree here, I'm trying to give best-practices advice, based around the common elements of the Ethernet specs so that the average installer could put together a decent LAN without fears that things would get wonky.

Extending a network with 20 switches violates every common design guideline, and also does not take the rest of the network into consideration. We also didn't say if those interim switches are dedicated solely to being "extenders", or if other devices might end up plugged into them now or in the future.

'We' didn't say anything about the switches. 'You' said

Note that there are still limitations here, you cannot put 20 switches in place to extend a segment out to 2Km.

If you meant "'shouldn't" instead of "cannot", just redact your statement. To an engineer there is a big difference between the two.

I'm trying to give best-practices advice, based around the common elements of the Ethernet specs so that the average installer could put together a decent LAN without fears that things would get wonky.

Then please stop with "You might be able to get a single run of 300 meters to work." You 'cannot'.

Then please stop with "You might be able to get a single run of 300 meters to work." You 'cannot'.

So when you say 'cannot' here, you mean as in absolutely guaranteed not to work even a little bit?

Tell you what, you setup a 300M 100Base-TX connection over any approved Category Cable and

I'll setup 20 100Base-TX switches* with 100M of Crap 5 cable between them.

One 1080p ip camera.

Post pics. Better quality wins. You win ties.

Deal?

*Best Buy has a pretty liberal return policy.

Tell you what, you setup a 300M 100Base-TX connection over any approved Category Cable and

I'll setup 20 100Base-TX switches* with 100M of Crap 5 cable between them.

OK.

Except it was a 5MP IP camera, because that's what I had handy.

Make sure you save your receipt, would hate to see you get stuck with only store credit.

I have no doubt Avigilon will work :)

Impressive but unfair since you used Avigilon. :)

Do you happen to have a cable certifier handy? I'd be curious how the numbers look at that length.

Also, I have heard that running cable on the spool actually decreases signal strength, due to inductive effects.

Maybe that's another myth worthy of shattering?

Whats the spec on that cable?, I think I'll pick some of that stuff up as well as the switches.

Dynamite stuff!

Impressive but unfair since you used Avigilon. :)

Yeah, but it's connected to a TP-Link switch, so it kinda evens out :)

Do you happen to have a cable certifier handy? I'd be curious how the numbers look at that length.

I don't, but the last time I did this the cable of course ultimately failed all tests due to length/resistance, but did OK on cross-talk and other parameters.

Also, I have heard that running cable on the spool actually decreases signal strength, due to inductive effects.

Yes. I meant to mention that in the video, the on-spool test is in some ways a worst-case scenario (though it makes it easier to keep the whole thing away from other noise sources). It can also increase the chances of crosstalk.

Whats the spec on that cable?, I think I'll pick some of that stuff up as well as the switches.

It's a Mohawk Cat5E outdoor/UV rated cable. So, the jacket is a little thicker than normal which probably helped the whole on-spool/crosstalk thing. I got it from l-com, this should be the same one.

What was the link speed, 10 or 100?

Any hard errors on the switch?

For my part, I am taking advantage of a Slammer's Special, and going with that trusted name, Tenda.

Everything was in "full auto" mode. The switch port came up at 100Mbps/Full duplex, the camera got an IP via DHCP, ACC auto-discovered it and did a firmware upgrade.

It's been running since ~3:30PM EDT with no errors reported in ACC or on the switch. I have it set for continuous recording just to keep data flowing through.

The last time I tested a "gang of switches" I got pretty good performance out to 10 switches, but it broke down around 15 switches. By that I mean DHCP wouldn't work on that network, and ARP discovery didn't work. When I gave the camera an IP address and manually added it to the ARP table on the PC I could access it OK.

I was testing something for a large site that was going to have cameras on the perimeter and someone wanted to put a switch at each pole roughly 250' apart and keep chaining the network around the perimeter. To be honest, I wasn't a fan of that topology and didn't spend any time doing things like increasing STP radius or going out of the way to try and make it work, I was just recommending against relying on such a large daisy-chained topology for practical and technological reasons.

The last time I tested a "gang of switches" I got pretty good performance out to 10 switches, but it broke down around 15 switches. By that I mean DHCP wouldn't work on that network, and ARP discovery didn't work.

IMHO, It sounds like STP was either configured incorrectly and some switches were blocking broadcast traffic thinking that there was a loop, or that the number of switches in the tree was so large, that the amount of 'learning' time when a device was first connected was so long that by the time the switch let the request pass, the device had stopped listening.

Since it was able to pass comparatively large video frames, but not tiny, ARPs and DHCP requests, it would follow that it was most likely a config issue as opposed to a physical transmission issue.

Be that as it may, STP is not necessary when there are no loops, and in the simple case that you mentioned, there is no likely reason to assume any.

So I will be using unmanaged switches, which hopefully will let everything go thru. Just give me a day to get it hooked up. It should be quite an interesting light display on the switches. I wonder if you will be able to see the signal move thru the switches or will they appear to blink simultaneously?

Also, thanks again for running the 300M test. Once CSMA/CD is out of the way, one wonders what the real limiting factor is.

If it is attenuation, then why aren't there longer allowed lengths for 100mb on cat 6a with its larger conductors? Sounds like it is less and less rooted in the physics and more on the paper. I ordered the cable you used as well, I want to see when it really starts to breakdown, maybe the whole spool will work to some degree.

Howdy, sorry for the delay, more logistics than I counted on, plus a 2 switch per household limit at MicroCenter to blame. ;)

I made a part 1 video response and created a new discussion called:

Undisclosed Vs Undisclosed Ethernet Challenge - Who Will Go The Distance?

Principles of electronics and physics do not limit networks to 100M segments. There are several technologies running on copper cables such as DSL to 10Base-2 that have segment limits much longer than 100M, some in the kilometer range.

Interesting, are you not implying that if you design hardware around the spec, that it now becomes inherently limited to 100 meters? Your words, not mine: "equipment is built and tested to the 100M spec." My source is marked below (Principles Source)

ALL Ethernet implementations (10Base-T, 100Base-T, 1000Base-T) have a specified max segment length of 100 Meters for twisted-pair cabling. None of the standards are guaranteed to work on longer segments, and equipment is built and tested to the 100M spec.

ALL Ethernet implementations DO NOT have a specified limit of 100 meters, 40GBase-T is limited to 30meters: Source: "Ethernet: The Definitive Guide, pg.201, paragraph 5 by Charles E. Spurgeon and Joann Zimmerman "

Interesting bit of data: The 100 Meter Design Goal

The 100 Meter Design Goal
Both the ANSI/TIA/EIA standards and the twisted-pair Ethernet specifications are
written with a 100 meter length design goal for segments. The 100 meter goal comes from studies that show that the vast majority of the desktops in the average office building are within 100 meters of cable length from the nearest telecommunications closet.

Source: "Ethernet: The Definitive Guide, pg.249 by Charles E. Spurgeon and Joann Zimmerman "

Principles Source: "Ethernet: The Definitive Guide, pg.56 by Charles E. Spurgeon and Joann Zimmerman "

Full-Duplex Media Segment Distances
When a segment is operating in full-duplex mode, CSMA/CD-based MAC operation is disabled. As a result, the cable length limits imposed by the round-trip timing con?straints of the CSMA/CD algorithm no longer exist. In the absence of a round-trip timing limit imposed by the CSMA/CD MAC algorithm, the only constraint on cable length is the one imposed by the signal transmission characteristics of the cable. For that reason, some full-duplex segments can be much longer than the same segments operating in half-duplex mode.

For twisted-pair cabling, it is the signal-carrying characteristics of the wires that limit segment length. The 10/100/1000BASE-T and 10GBASE-T media systems have a max?imum cabling distance recommendation of 100 meters (328 feet) for twisted-pair cable.

One last item, and it is directly related to 40GBase-T; Providing 40GBASE-T operation over twisted-pair cable is an even greater challenge, and quite difficult to do. One way to achieve better signal-handling capability over twisted-pair cabling is to use a shorter segment length, which is why there is a 30 m target length in the 40GBASE-T standard.

Source: "Ethernet: The Definitive Guide, pg.201, Paragraph 5 by Charles E. Spurgeon and Joann Zimmerman "

Signal Handling is directly related to electronics and physics

So again, I stand by my original answer.. Aloha!

Interesting, are you not implying that if you design hardware around the spec, that it now becomes inherently limited to 100 meters? Your words, not mine: "equipment is built and tested to the 100M spec."

I've worked for a number of hardware manufacturers over the years, including some large telecom equipment makers. The general approach is that something is designed and built to meet a specification, and then also cost-reduced to ensure you're not needlessly overbuilding things. Again, just to be clear, this is a generalization because we can't cover every possible edge-case and random permutation of things here.

If the Ethernet spec says "100M" then a device would be built and tested to 100M, maybe 120M to give a little bit of headroom. It likely wouldn't be tested to 200M, though it might actually work at 200M, but if you call the manufacturer and say "I've been deploying your widget on 200M network segments and this latest batch won't work at 200M" they are going to tell you "it's only rated for 100M".

ALL Ethernet implementations DO NOT have a specified limit of 100 meters, 40GBase-T is limited to 30meters

Honestly, this statement is completely pointless in the context of this discussion. For one thing 40GBase-T is not even ratified yet. Right now it's on a timeline for standardization early next year. I doubt we will see 40GBase-T in security any time soon, and there is no reason to believe it would be a common PHY on an *endpoint* device, which is the context of the conversation here.

I listed 10/100/1000-BaseT in my comment as additional clarification, just in case anyone couldn' follow the basic flow of this discussion and needed some extra detail. It seems I need to be even more precise, as you want to take this thread into some odd detours, brining up things that are not at all applicable to core concept being discussed.

The 100 Meter design goal you mentioned above was one of the components that went into some of the initial design of twisted-pair Ethernet. For most product design projects you have to set some boundaries of how you think the product will be used and what the typical user would expect. In looking at common buulding layouts, it was determined that twisted-pair Ethernet didn't need 1Km range, among other things. So once you have certain boundaries set (like a max cable length) you can define other parts of the product, like what the signalling level might need to be, or how timing should be handled and so forth.

So again, I stand by my original answer

Right, solve a technical problem with donuts. Good answer.

Like I said..... inherently limited to the distance of 100 meters. Use fiber, it is the proper way!

Curious, what manufacture are you with?

It has been a decade since I was an IT administrator, but with todays certified networks, I would not see a problem if both legs were properly terminated and certified patch panels/modular jacks/keystones/patch cables are used. The four port points should be properly labeled. Crimp RJ45 connectors at the extender would not be acceptible.

There is no way any non certified drops would be connected to my switches or would exist at mdf/idf locations. All of my camera networks are certified.

If you have to use an extender, then that means another idf location is needed. Probably 80 percent of my work nowadays are upgrades and additions to camera networks installed years ago. Find a location under 100 meters away and install a 24 Port POE switch for future business.

If you have to use an extender, then that means another idf location is needed.

That's no fun. :(

Even if the extender is rated for plenum spaces?

I represent Veracity, a manufacturer (indeed a pioneer) of Ethernet over Coax adaptors and Ethernet over UTP Extenders, amongst other things. [Please note that we offer fibre-capable products too, so my comments are meant to be informative, not pushing one technology over another].

First of all, I think this is a really interesting discussion with many useful technical points raised along with various views and opinions. I'd like to make some comments from a manufacturer's perspective.

The obvious point about copper-connected links versus fibre is that copper can deliver power via POE, which is very convenient, especially for cameras which can often be (or perhaps should be!) in hard-to-reach places to which it can be difficult or expensive to install a power spur. POE solves all of that and indeed allows remote power-cycling and reboot if a camera should hang for any reason. [Note: IP cameras are extremely reliable in this regard these days, but such situations can still occur from time to time, e.g. interrupted firmware upgrades].

Whilst IT departments can, and do, raise valid objections about uncontrolled devices on their network, it is usually not a problem so long as the devices are proven, tested, properly installed and their function, reliability and lifetime properly explained to the IT people involved. The actual extenders and links are typically on point-to-point links with only the IP camera at the far end, thus not on what the IT managers would consider critical parts of the corporate network.

One valid objection which can be raised about mid-cable UTP extenders specifically is that they often end up in odd places (roof spaces, above false ceilings, in cabling trunking, screwed to a wall), sometimes with undocumented locations. It is easy to see how IT people would be wary of improperly installed and undocumented network links as any faults or failures would be very time-consuming to trace. It all comes down to quality of installation and device selection.

An alternative to mid-cable UTP extenders is to use long range point-to-point devices, so that the base and camera ends are all properly located. Such devices can deliver full 100BaseT performance (and deliver useful POE) up to 800m (2500ft) or more, providing incredible flexibility in the positioning and installation of IP cameras around a site without going to the expense of fibre and separate power cabling.

Another perspective is that very often there is coax cable already installed and where older analog cameras are being upgraded to IP cameras. The coax cable is often embedded in the building and typically expensive or disruptive to remove and/or recable with network cable. This is the reason why there is such a large market for Ethernet-over-Coax adaptors. POE can be delivered over the coax too, making retro-fit of IP cameras extremely rapid, efficient and reliable. Usually all the coax cabling comes back to one point where it is convenient to connect all the base coax Ethernet adaptors to one or more network switches. From there, the network can be linked into the corporate network, or kept separate, depending upon requirements. In our experience, IT managers have no issue with the re-use of this cabling (which usually belongs to the security department anyway) and the connection of the end result to their network - so long as they are properly consulted.

Veracity started delivering Ethernet-over-Coax adaptors about nine years ago, followed shortly after by network extenders and long distance point-to-point devices. With few exceptions, these devices are all still in place and functioning perfectly many years later. We have found that many IT managers who were initially sceptical have been won over by the simplicity, reliability and low cost of such approaches.

Our advice therefore is to discuss in more detail with any IT departments who may be against fitting network extender or adaptor devices. Often such objections can be overcome. Sometimes, however, the IT department has the final word and won't be moved. In such cases we hope that the IT department's budget is paying for the fibre links and power spurs required !

"One valid objection which can be raised about mid-cable UTP extenders specifically is that they often end up in odd places (roof spaces, above false ceilings, in cabling trunking, screwed to a wall), sometimes with undocumented locations. It is easy to see how IT people would be wary of improperly installed and undocumented network links as any faults or failures would be very time-consuming to trace."

Now THAT is a really excellent point!

"Our advice therefore is to discuss in more detail with any IT departments who may be against fitting network extender or adaptor devices. Often such objections can be overcome."

Great unbiased, non-partisan advice, thanks! (I'm not OP, BTW, this was just a good read.)

We have extensive experience using ethernet extension devices that go back to the original developers of re-encoding ethernet and pushing it further across alternate pairs. Cat3,5 etc.
There are some caveats that we have discovered, and some are easily overcome.

1. Some devices will SYNN at 1GB to the switch, but the Camera at the far end is 100MB. We suggest you disable auto on switch ports and set them to 100.

2. Some older camera ethernet chipsets will not play nice with a single ended distance extender. Example EnableIT 828P. In this case, you move the device to the camera end and all is fine.

Single ended devices manipulate timing to get the extended distances, while a dual device EnableIT 865, re-encode the data atop an alternate NRZ encoding scheme. We have had these installed over 6 plus years, with no failures... (barring a direct lightning strike) fails the smoke test.

In fact we have many dual ended devices with IP cameras over 1,000' using old cat3 telco wire.

In our offices we have several test rolls of cat5e wire starting at 300' up to 1,000 in 100' increments and we have always tested these devices well in advance of deploying them.

If given the choice to control the install, we always use CAT5E FSTP, single end earth bonded, plus 65V 8 pin surge protection Both ends (earth bond). If you are not using all 4 pairs, we recommend you earth bond the unused pairs....

The only regulatory body (legally) is UL 497 A and B, and NEC.