We have a product that runs over IP. This product comes in two halves that are supposed to be connected directly to each other over Cat 5e. All this works fine.

For reasons that are not important, we have a customer that wants to ensure that it can not work on an actual IP network and only direct. So, we changed our firmware so that the fixed IP addresses are and They work directly connected, great!

But, when I connect them through our corporate network, through multiple switches, managed and unmanaged (and possibly a router, I didn't check with IT), they still link together and function normally.

So, I assumed the firmware is broken, and not really sending over that IP, so I mirrored a switch port, grabbed Wireshark and:

Enter image description here

What is the explanation for this?

Are there any IP addresses that will not flow through a switch?

To JFL: We do not run an OS of any kind. It is an embedded system of which we control the code, so we can set the IP address to whatever we want. It can be fixed, or DHCP, so we just set it to a fixed address.

To Zac67: Generally, it's a really bad idea. It is in violation of RFC 1122. Yes, I know. That is exactly why I did it. We are in control of our own code, so no worry about it breaking. On a network I wanted it to break, which to my surprise it did not.

If you don't want those packets to cross routers link-local aka zeroconf aka APIPA addresses are what you need.

Thank you. I am aware of those addresses, but they are only 'un-routable'. I was actually hoping to do something that even a modern switch would puke on and not forward to anywhere. I was surprised (shocked actually) that a switch would forward loopback.

  • What is the operating system of the hosts that run your program? I was unable to send a packet to from Windows or MacOS.
    – JFL
    Dec 7, 2022 at 20:16
  • 1
    Please do not post comments to answers as part of your question. Instead, comment the according answer.
    – Zac67
    Dec 8, 2022 at 7:42
  • 2
    Switches don't care about IP addresses. Switches don't look at IP addresses. Switches look like direct connections but with more ports and a very minimal amount of MAC address cleverness. Dec 8, 2022 at 10:24
  • 3
    For reasons that are not important, we have a customer that wants to ensure that it can NOT work on an actual IP network and only direct. Are you sure this isn't an X-Y problem? Perhaps understanding the customer's requirements better might lead to a different solution.
    – Ron Trunk
    Dec 8, 2022 at 13:11
  • 2
    If you are going to remove most/all the benefits of using ethernet and IP, why not just use something else instead, like SPI? You can still re-use ethernet cables to physically connect both devices, but run SPI over it instead of using anything IP/Ethernet related.
    – SnakeDoc
    Dec 9, 2022 at 20:42

9 Answers 9


we changed our FW so that the fixed IP addresses are and

Generally, that's a really bad idea. It is in violation of RFC 1122:

  (g)  { 127, <any> }
                  Internal host loopback address.  Addresses of this form
                  MUST NOT appear outside a host.

If it works: fine for now, but may break any time. If it doesn't work, just do it correctly.

Basically, if you see those packets on your network, it's the source host (its implementation) that's violating RFC 1122. There's no bouncer on each network port that filters that traffic. It's the network admin's or architect's job to categorize whatever traffic as unwanted and take measures against it.

we have a customer that wants to ensure that it can NOT work on an actual IP network and only direct.

As @FrameHowitzer has pointed out, making a product use IP and not work over an IP network at the same time isn't possible. You'll have to actively configure that network to inhibit unwanted communication.

If you don't want those packets to cross routers, link-local aka zeroconf aka APIPA addresses are what you need. Simply use addresses from which are defined to be not routable. I've explicitly blackholed those addresses on all our routers, just to make sure.

On the switches, you'd need to segregate that traffic using a dedicated VLAN. Switches don't care about higher-layer addresses like IP, so they'd forward frames containing link-local or even local loopback addresses just fine - but only within a VLAN.

If the switches support L3 ACLs you could filter the exact IP addresses that you don't want on your network, e.g.

 deny ip any
 deny ip any
 (permit any any)

In a more complex configuration you could also choose to explicitly permit wanted traffic and filter all the rest.

  • 3
    It's a tad bit concerning folks with zero understanding of basic networking are designing and building a networked device. Recipe for disaster down the road... - There is no hope a complicated setup like VLAN's and such are going to get implemented here.
    – SnakeDoc
    Dec 9, 2022 at 20:40
  • Zeroconf works by the 169.254 range. I don't remember exactly how, but the router advertises the default route and is a NAT gateway; and the hosts just assign themselves addresses in the range on the LAN. But most people don't set this up. I don't blame them. I haven't seen it in decades.
    – Joshua
    Dec 10, 2022 at 4:02
  • 2
    "making a product use IP and not work over an IP network per se at the same time isn't possible". It depends on what you mean by "use IP". You can do everything the same as IPV4 or IPV6 but add in something that breaks normal implementations. For example, change the Ethertype field in the packets to 0x88B5 "EEE Std 802 - Local Experimental Ethertype". In that case other hardware won't know you are sending IP packets.
    – user4574
    Dec 10, 2022 at 4:23
  • 1
    @user4574 Sure - you could also change the IP version field to something else than 4 or 6, use exotic EtherTypes, change the checksum algorithms, ... But I wouldn't call that IP or Ethernet any more.
    – Zac67
    Dec 10, 2022 at 11:39

The way I understand the question is: "How can I make it so our thingamajig DOESN'T work over a network of any kind and only works over a direct cable connection?"

Since that is specifically the antithesis of this kind of environment, I have to imagine it is off-topic. As for an answer, you would have to figure out how to make your software use interface hardware that is not used for normal networking, perhaps over a dedicated USB connection or other local direct connection. Anything that uses a standard network interface adapter has the chance to be intercepted and run over an extended network, assuming the person doing it has enough brains and experience to make it appear to be a Local Area Network.

Alternately, you could accept that it can be run over a network but encrypt it with a proprietary method so that only your desired 2 endpoints can participate in the connection.


If you don't want your product to work on an IP network, then don't use IP.

IPv4 is transmitted using Ethernet packets with an EtherType of 0x800.

Wikipedia has a (probably non-exhaustive) list of EtherTypes.

Choose an EtherType that isn't 0x800 and, even better, doesn't collide with anything on this list (or anything else you happen to know is used) and IP hardware (such as routers) won't route your packets. Switches may still forward them though, because switches forward Ethernet packets, not IP packets.

Other good answers:

  • Karatekid430's answer: don't even use EtherType at all, just put your own non-Ethernet frames on the Ethernet PHY. I would imagine switches should drop these (but please correct me if I'm wrong here).
  • Zac67's answer: use IP addresses from in the hope that they won't be routed. Switches will still forward these - and it's possible that routers that have badly programmed firmware on them could forward them too, as you'd be relying on devices to handle this range appropriately.
  • 3
    The EtherType field is ignored by switches (may be filtered with explicit configuration), so that doesn't really work. You could use special, on-link-only multicast addresses, but those are usually broadcast by simple switches as well. Also, the OP doesn't seem to have that option and states We have a product that runs over IP.
    – Zac67
    Dec 8, 2022 at 8:56
  • 4
    If you have the ability to control the Mac, you could deliberately put the wrong checksum on every packet. E.g. calculate the correct checksum, then flip the first 16 bits. Dec 8, 2022 at 10:37
  • 2
    @Zac67 OP states the two endpoints are supposed to be directly connected on a single Cat5e cable, and that they have complete control over the firmware, so my assumption was that IP was only being used to transport packets from A to B and back again, and no other features of IP were required, and therefore framing the packets in something other than IP should be pretty trivial for them to implement. Agreed that EtherType won't affect switches, but how much OP wants to change their product depends on how "easily" they need it to "break" if connected "incorrectly".
    – Keiji
    Dec 8, 2022 at 13:21
  • 1
    @user253751 That sounds like a very good suggestion, which you should probably post as an answer!
    – Keiji
    Dec 8, 2022 at 13:22

Switches don't look at the IP address when forwarding frames. You can use whatever IP address you want, as long as the MAC addresses are correct your switch will happily forward it. It doesn't matter whether the IP adresses are,,, or anything else. Even identical IP adresses work. It's only the endpoint host (or next hop router) that will read the IPs and get confused.

If you want a switch to drop the traffic in stead of forwarding it, you might try to use a MAC address in the range "IEEE 802.1D MAC Bridge Filtered MAC Group Addresses" (01-80-C2-00-00-0x). These MAC addresses are reserved for protocols that should never be forwarded by switches, such as STP (01-80-C2-00-00-00), LLDP (01-80-C2-00-00-0E), etc.

Note that I would not recommend this in any production environment... these MAC addresses are reserved for a reason. But this might be fun to test in a lab.

Read more in the IEEE documentation or my blogpost on the topic.

  • 1
    The IEEE 802.1D MAC Bridge Filtered MAC Group Addresses is a good point - however, there are a great many (mostly unmanaged) switches that ignore 802.1D.
    – Zac67
    Dec 8, 2022 at 9:09

Here are some ideas. None guaranteed. You didn't specify how important it is that someone can't deliberately access the packets.

  • Use a weird connector and don't sell adapter cables compatible with RJ45.

  • Use normal RJ45 connectors but mix up the pins. Only your special cable will work. Make sure to wire it differently at both ends.

  • Use normal Ethernet cables, but interchange the 4 twisted pairs so they don't match up if plugged into a normal receiver. E.g. swap lanes A and D so what is normally transmitted on A is actually transmitted on D and vice versa. Some network cards can compensate for certain rearrangements so make sure to use a different one.

  • Use normal cables, but deliberately overclock or underclock your PHY so it runs way out of spec (might only need a difference of 5% or so) and normal PHYs won't sync up. You run the risk of malfunction, of course.

  • Add an extra lock-and-key physical signal. For example a certain small current must be present and must change polarity at a certain frequency, or a certain bit sequence. As long as the frequency is low, this can be superimposed on top of the data signal with no issues. If the signal isn't present, don't communicate.

  • Deliberately break the Ethernet CRCs. For example, flip the last bit. You still have a checksum but it's incompatible with normal MACs. This is totally impossible with a standard MAC so it will only work if you're using some kind of software MAC or FPGA.

Anything higher-level than that - any kind of scrambled frame or scrambled header etc - will result in a frame that can pass through switches. Switches don't really look at a frame's contents a whole lot, before deciding how to forward it. Although since they do look at the Ethernet header a little bit, here are some Ethernet header ideas that might confuse some switches enough to make them not forward your frames:

  • Send frames addressed to your own MAC address. The switch will try to send them back to you, or send them nowhere at all, instead of forwarding them to the other device because it knows that device is not their destination.

  • Send frames with invalid VLAN tag 4095 (valid VLAN numbers are 1 to 4094)

  • Send frames with the source address being the broadcast address FF:FF:FF:FF:FF:FF

  • 1
    VLAN ID 0 (null VID) is legal in a tag, it's used for no VLAN, just PCP information - see IEEE 802.1Q clause 9.6.
    – Zac67
    Dec 8, 2022 at 14:22
  • Send frames with the source address being the broadcast address "FF:FF:FF:FF:FF:FF" won't stop them from being forwarded; but will probably bring havoc when somebody else replies. I tried it. Switches don't care about messed-up source addresses.
    – Joshua
    Dec 10, 2022 at 4:08
  • I like the mix up the pins on the RJ45 idea. But you have to be careful how you mix them up. Many 10/100 Ethernet PHY chips have auto MDIX and can correct swapped +/- wires within a TX/RX pair, correct for swapped TX/RX, or both.
    – user4574
    Dec 10, 2022 at 4:42

Change your product's firmware to not use Ethernet frames over the Ethernet PHY. You can use an Ethernet PHY and place PCIe packets or something else on it.

  • Usually, an Ethernet PHY also implies an Ethernet MAC, so you're likely stuck with Ethernet frames. Also, the OP specifically asks about a product that runs over IP.
    – Zac67
    Dec 8, 2022 at 9:06
  • Yeah, they can encapsulate IP packets in other types of frames. My answer does not rule out using IP. They want to not route through L2 switches, so the solution is to replace the L2 protocol which is Ethernet frames. Dec 8, 2022 at 9:12

So from your edit, those packets with IP addresses / are sent by embedded systems which implement their own IP stacks.

Those systems are not compliant with the RFC and do send those packets on the network, which normally should not occur. Any address within must be treated as a loopback address and not go lower than layer 3 of the network stack.

Switches don't care about IP addresses, they only handle frames and whatever is inside the frame (like an IP packet) is of no concern to them. So a switch will happily forward a frame that contains an invalid IP packet, with a 127.0.0.X IP address or any other one.


If you have full control of the details of the network stack software (like in many embedded environments), you could do the following.

Change the Ethertype field in the Ethernet packets to 0x88B5 "EEE Std 802 - Local Experimental Ethertype".


In that case other hardware won't know you are sending IP packets and won't make assumptions about what's inside. Ethernet switches would probably still forward the raw Ethernet packets, but PCs would not be able to process them without custom software telling them what's in the packets.

Next do something like add in a 128-bit magic number between the 802.3 Ethertype field and the IP header. When receiving packets, throw out any that don't have that exact magic number as the first 16 bytes. All the other IPV4 or IPV6 processing is done identically, except that you started parsing it at a memory address that is 16 bytes further into the Ethernet frame.

Make sure to use a good random number generator to avoid collisions with other people who might also be doing custom stuff.

With those changes no regular IP nodes will know what to do with your packets, but it shouldn't be hard to modify your stuff to process them. This all assumes that you can modify the low-level Ethernet and IP processing firmware.


The IP address is a special address known as the localhost or loopback address. This means that it always refers to the local computer, so you can always send a message to it from your local computer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.