Switching

EXISTING
set interfaces irb unit 1 family inet address 10.205.35.115/24


CHANGE REQUIRED
set interfaces irb unit 1 family inet address 10.205.35.115/25


STEPS FOLLOWED
delete interfaces irb unit 1 family inet address 10.205.35.115/24
set interfaces irb unit 1 family inet address 10.205.35.115/25


FACING ERROR
error: Overlapping subnet is configured under irb
[edit interfaces irb unit 1 family inet]
  'address 10.205.35.115/25'
error: configuration check-out failed

delete interfaces irb unit 1 family inet address 10.205.35.115/24

commit
set interfaces irb unit 1 family inet address 10.205.35.115/25

commit

Already Tried, No success

Can you show everything currently on the irb unit 1  before and after the change?

show interfaces irb unit 1

AT PRESENT THE OUTPUT IS-

#show interfaces irb unit 1

family inet;

& WHEN TRIED WITH ASSIGNING IP TO MGMT VLAN (VLAN 1)

# set interfaces irb unit 1 family inet address 10.205.35.115/25

error: Overlapping subnet is configured under irb
[edit interfaces irb unit 1 family inet]
  'address 10.205.35.115/25'
error: configuration check-out failed

This subnet 10.205.35.115/25 overlaps with another interface on the device.  You can use this to find the interface.

#show | display set | match 10.205.35.

You can then either change the interface so there is no longer an overlap.

Or move one of these interfaces into a separate routing instance.  This of course means you need to also design how the routes move in and out of that instance for the desired communications paths.

We ran into the same issue on a legacy EX4200.   The only IP on the switch was the management IP.  When it was configured a subnet was not added, so it defualted to a /32.  We needed to change this to a /24, but we ran into the same error everytime we tried to make the change.  Since it was the only IP there was zero possibility of an actual overlap.

A reboot was required to resolve our issue, but here are a couple things I would try before going for the nuclear option:

1. do a 'commit full'  - This is useful if you have a configuration that does not seem to be taking affect such as deleting an IP off an interface. 

2. Verify there are no conflicting addresses.  'show configuration | display set | match inet | no-more'

3. delete the entire interface, not just the IP address.  At least delete the family inet.

4. finally delete the family inet with its IP address and reboot to ensure that it takes affect. 

We went through these steps (and more), but the only thing that worked for us was after step 4 we were able to add the IP address without the error.  Thankfully this was a new install, so rebooting was an option for us since it did not have host on it yet.

I know this is a late reply and hopefully you have resolved your issue by now, but wanted to add it in case someone else ran across this article.

I was running into this same (or very similar) problem with an ex3300 runing Junos 15.1R6-S2.1. It is a l2 switch with a management vlan (the only interface with family inet is vlan.100). vlan.100 is configured with address 10.0.100.10/28, and I wanted that to change to /24.

Example showing the interfaces and the vlans stanzas in my lab switch

interfaces {
    vlan {
        unit 100 {
            description "management vlan";
            family inet {
                address 10.0.100.10/28;
            }
        }
    }
}
vlans {
    vlan-mgmt {
        description "management vlan";
        vlan-id 100;
        l3-interface vlan.100;
    }
}

I should be able to delete the address, and add it back with the new netmask:

root@sw-lab-ex3300# show | compare
[edit interfaces vlan unit 100 family inet]
+       address 10.0.100.10/24;
-       address 10.0.100.10/28;

root@sw-lab-ex3300# commit check
error: Overlapping subnet is configred under vlan
[edit interfaces vlan unit 100 family inet]
  'address 10.0.100.10/24'
     Overlapping subnet is configured
error: DCD Configuration check FAILED.
error: configuration check-out failed

{master:0}[edit]
root@sw-lab-ex3300# rollback
load complete

{master:0}[edit]
root@sw-lab-ex3300#

Uh-oh, that's not good. I rolled back to the running configuration and decided to research more. I followed some of the examples in this thread, and began testing in my lab. Testing in lab confirmed that I can change the netmask if I delete the l3-interface's inet address, reboot, then add the address with new netmask. This isn't a great solution, so how do I do this without a reboot? I have done it before without issue. What was different then!?

I decided to do some more lab testing with some other ex3300's that I was using. These already had other vlans and multiple l3-interfaces. I added vlan-mgmt, and the l3-interface configured with a /28 netmask, etc. Committed - no errors.

I then hen tried changing the netmask to /24 as above, and it committed with no errors this time!?

Why? It looks like this problem only appears if you only have one irb/vlan l3-interface configured on the switch. So I go back to my problem switch and I added a temporary vlan with a temporary l3-interface (this is all temporary, so doesn't matter too much what values you use - make sure it doesn't conflict with anything else, or maybe you can put it in a separate routing-instance). I do not attempt to change the management vlan netmask yet!

root@sw-lab-ex3300# show | compare
[edit interfaces vlan]
+    unit 3000 {
+        description "temporary vlan";
+        family inet {
+            address 10.255.255.254/32;
+        }
+    }
[edit vlans]
+   vlan-temp {
+       description "temporary vlan";
+       vlan-id 3000;
+       l3-interface vlan.3000;
+   }

{master:0}[edit]
root@sw-lab-ex3300# commit check
configuration check succeeds

{master:0}[edit]
root@sw-lab-ex3300# commit
configuration check succeeds
commit complete

{master:0}[edit]

So far so good!

Now I can attempt to update the management vlan's netmask:

root@sw-lab-ex3300# show | compare
[edit interfaces vlan unit 100 family inet]
+ address 10.0.100.10/24;
- address 10.0.100.10/28;

{master:0}[edit]
root@sw-lab-ex3300# commit check
configuration check succeeds

{master:0}[edit]
root@sw-lab-ex3300# commit
configuration check succeeds
commit complete

{master:0}[edit]
root@sw-lab-ex3300#

Weird quirk! I know this tread is several months old now, but I figured I would add another documented workaround for the next person that runs into this (and doesn't want to reboot their device).