same IP address on two interfaces

m4rtin

Am I correct that JUNOS allows one to configure two interfaces with the same IP address? Looks like it's possible to configure this:

root@M10i> show configuration 
## Last commit: 2012-05-31 07:44:58 UTC by root
version 10.4R8.5;
system {
    root-authentication {
        encrypted-password "$1$X62k3nip$rneAWXEDwHxYDo9T6rjL0."; ## SECRET-DATA
    }
    syslog {
        user * {
            any emergency;
        }
        file messages {
            any notice;
            authorization info;
        }
        file interactive-commands {
            interactive-commands any;
        }
    }
}
interfaces {
    ge-1/1/0 {
        unit 0 {
            family inet {
                address 10.10.10.1/30;  
            }
        }
    }
    ge-1/2/0 {
        unit 0 {
            family inet {
                address 10.10.10.1/30;
            }
        }
    }
}

root@M10i>

But of course only one of those ports can have the configuration active:

root@M10i> show interfaces ge-1/1/0 terse 
Interface               Admin Link Proto    Local                 Remote
ge-1/1/0                up    up  
ge-1/1/0.0              up    up   inet     10.10.10.1/30   

root@M10i> show interfaces ge-1/2/0 terse    
Interface               Admin Link Proto    Local                 Remote
ge-1/2/0                up    up  
ge-1/2/0.0              up    up   inet    

root@M10i>

Is the configuration actually applied always to the first port? Are there any useful user-cases where ability to configure same IP address to more than one interface comes in handy?

Forsaken_GA

It can be useful in cutover situations, when you need to move the IP from one port to another. Then you just need to down one port, bring the other up, and you're failover time is kept to a minimum

m4rtin

Forsaken_GA wrote: »

It can be useful in cutover situations, when you need to move the IP from one port to another. Then you just need to down one port, bring the other up, and you're failover time is kept to a minimum

That's exactly the user-case I thought, but looks like it does not work. For example if I have a following configuration:

root@M10i> show configuration interfaces ge-1/1/0    
unit 0 {
    family inet {
        address 10.10.10.1/30;
    }
}

root@M10i> show configuration interfaces ge-1/2/0    
unit 0 {
    family inet {
        address 10.10.10.1/30;
    }
}

root@M10i>

..and interface ge-1/1/0 is the one which gets the actual configuration:

root@M10i> show interfaces ge-1/1/0 terse    
Interface               Admin Link Proto    Local                 Remote
ge-1/1/0                up    up  
ge-1/1/0.0              up    up   inet     10.10.10.1/30   

root@M10i> show interfaces ge-1/2/0 terse    
Interface               Admin Link Proto    Local                 Remote
ge-1/2/0                up    up  
ge-1/2/0.0              up    up   inet    

root@M10i>

..then it does not "move" configuration from ge-1/1/0 to ge-1/2/0 if I disconnect the cable from ge-1/1/0:

root@M10i> show interfaces ge-1/1/0 terse            
Interface               Admin Link Proto    Local                 Remote
ge-1/1/0                up    down
ge-1/1/0.0              up    down inet     10.10.10.1/30   

root@M10i> show interfaces ge-1/2/0 terse    
Interface               Admin Link Proto    Local                 Remote
ge-1/2/0                up    up  
ge-1/2/0.0              up    up   inet    

root@M10i>

Even if I pull out the ge-1/1/0 PIC situation remains the same:

root@M10i> show interfaces ge-1/1/0 terse                       
error: device ge-1/1/0 not found

root@M10i> show interfaces ge-1/2/0 terse                       
Interface               Admin Link Proto    Local                 Remote
ge-1/2/0                up    up  
ge-1/2/0.0              up    up   inet    

root@M10i>

Any other ideas?

Forsaken_GA

admin down ge-1/2/0 to start with

then admin down ge-1/1/0, move the cable, admin up ge-1/2/0 and see what happens

networker050184

At that point its quicker to just move the cable and commit the change for the IP move. One of the nicer things about Juniper when coming from the Ciso side of the house.

ccnxjr

Seems like a clever hack.
I would've used VRRP on 2 routers, but never tried it on the same device using different interfaces...

m4rtin

Forsaken_GA wrote: »

admin down ge-1/2/0 to start with

then admin down ge-1/1/0, move the cable, admin up ge-1/2/0 and see what happens

If I do as you described, ge-1/2/0 will get the configuration:

[edit]
root@M10i# show | compare
[edit interfaces]
!    inactive: ge-1/1/0 { ... }

[edit]
root@M10i# commit and-quit
commit complete
Exiting configuration mode

root@M10i> show route

inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/30      *[Direct/0] 00:00:02
                    > via ge-1/2/0.0
10.10.10.1/32      *[Local/0] 00:00:02
                      Local via ge-1/2/0.0

root@M10i>

This is rather obvious because interface ge-1/1/0 transmit state is disabled. I was hoping this to happen automatically(without configuring) in case the cable from ge-1/1/0 is removed and port line protocol goes down

networker050184 wrote: »

At that point its quicker to just move the cable and commit the change for the IP move. One of the nicer things about Juniper when coming from the Ciso side of the house.

So in a nutshell configuring multiple interfaces with same configuration allows one to easily activate those preconfigured interfaces later? There are no other advantages or user cases to same IP address on two or more interfaces?

Megakazbek

Well, if you are using some virtualization scenario, it's possible that two interfaces are in different routing instances and just happen to have (or intentionally assigned) the same IP address.

networker050184

The quickest way to take care of this scenario IMO is to just rename the interface and commit while the cable is being moved. Minimal downtime and you don't have to worry about going through the trouble of trying to configure multiple interfaces with the same IP.

Aldur

The only reason IMO to have the same IP address on different interfaces is some possible virtualization scenarios, like what Megakazbek said. For migrations, like networker has said, it's better to use the rename function.

m4rtin

networker050184 wrote: »

The quickest way to take care of this scenario IMO is to just rename the interface and commit while the cable is being moved. Minimal downtime and you don't have to worry about going through the trouble of trying to configure multiple interfaces with the same IP.

ok. As I understand, "rename" causes all the configuration associated with one interface to move to another interface? If so, it's similar to "replace pattern"(?). Like example here:

root@M10i> show interfaces ge-1/2/0 terse 
Interface               Admin Link Proto    Local                 Remote
ge-1/2/0                up    up  
ge-1/2/0.0              up    up   inet     10.10.10.1/30   

root@M10i> configure 
Entering configuration mode

[edit]
root@M10i# rename interfaces ge-1/2/0 to ge-1/1/0   

[edit]
root@M10i# commit and-quit 
commit complete
Exiting configuration mode

root@M10i> show interfaces ge-1/2/0 terse    
Interface               Admin Link Proto    Local                 Remote
ge-1/2/0                up    up  

root@M10i> show interfaces ge-1/1/0 terse    
Interface               Admin Link Proto    Local                 Remote
ge-1/1/0                up    up  
ge-1/1/0.0              up    up   inet     10.10.10.1/30   

root@M10i> 

zoidberg

Yes, it will causes all the configuration associated with one interface to move to another interface, but only under the interface hierarchy.

If you do replace pattern from the root level, you have the added advantage that not only do you change the interface configuration but you will change other references to that interface elsewhere in the configuration, such as interfaces assigned to protocols or in VRs or zones.

Just be sure to carefully review a show | compare if you use replace pattern to make sure your match/replace didn't occur in any extra and unexpected places.

Ahriakin

Replace pattern is one of the single greatest commands of the CLI, such a simple and effective time-saver it's a wonder it's not standard for other vendors too. I had to replace a bunch if IOCs in one of our clusters a few weeks back with a different type, modules/port numbers/routing-instances/security-zones all changing, a major overhaul by normal standards.... the entire MOP was 6 lines of replace commands.
Sweet