# Rename Network Interface

**URL:** <https://forum.ansible.com/t/rename-network-interface/835>\
**Category:** Get Help\
**Tags:** playbook, network\
**Created:** [September 15, 2023, 8:24pm UTC](https://forum.ansible.com/t/rename-network-interface/835 "2023-09-15T20:24:56Z")\
**Posts on this page:** 1\
**Showing post:** 16

<div class="post-metadata">

**Author:** ![utoddl](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/utoddl/32/249_2.png) [@utoddl](https://forum.ansible.com/u/utoddl)\
**Post date:** [September 22, 2023, 6:12pm UTC](https://forum.ansible.com/t/rename-network-interface/835/16 "2023-09-22T18:12:16Z")

</div>

The `eth0` case seems to be the “normal” one. Is my guess is correct that `eth0_1` is a secondary IP defined on the same hardware/macaddress as `eth0`? I set up a secondary IP on my primary internet interface, but I’m on wireless and that device name is `wlp82s0`, so we’re already enough different — my udev rules are probably not like yours at all (what OS are you on, btw?) — that comparisons may get iffy. Unfortunately, that doesn’t give me an `ansible_wlp82s0_1`. It’s only listed as a `"ipv4_secondaries"` sub-dict under `ansible_wlp82s0`. Hmm.

There was another thread the other day, [get-the-name-of-an-interface-for-a-given-ip](http://forum.ansible.com/t/facts-get-the-name-of-an-interface-for-a-given-ip/712/14), where the same problem was dealt with albeit for a different purpose. The solution there was to loop over the `ansible_<interfaces>` data to add the benign defaults for otherwise missing data for the secondary addresses. The whole point was to avoid blowing up on missing data.

It looks like you’ve got 3 options: (1) use a technique similar to that in the linked thread above so you’ve got sufficiently fleshed out dicts for your secondary IPs, (2) skip the `src_interfaces` that don’t have `macaddress` defined (simplest by far, but has implications wrt why you’re renaming these interfaces), and finally (3) reconsider what’s driving the desire to rename these interfaces and attack _that_ as the problem to solve rather than – to be blunt – tossing away the udev work done by your distro for questionable gain. Granted, why you’re trying to do this has not been discussed, it’s your business not mine, etc. But after the tiny bit of reading I’ve done over the last 48 hours on udev rules and device naming, I’d need to hear an extremely compelling argument before I’d go down that road. And maybe you have one. I just wanted to include #3 because, speaking for myself, sometimes I fixate on implementing a solution to a problem that shouldn’t be solved, but rather eliminated further upstream.

I would still like to see what your `ansible_facts['eth0_1']` looks like (assuming that’s the one blowing up on you).

---

_[View the full topic](https://forum.ansible.com/t/rename-network-interface/835)._
