Consistent Management IP address

I was asked recently by a less experienced colleague of mine if there is a way to configure a single IP address that you can always use to connect to the master Routing Engine of a device that supports dual Routing Engine.

My colleague already knew about re0 and re1 configuration groups that allows you to configure distinct IP address on each Routing Engine.

However this implies that you need to know which Routing Engine is the master and then ssh/telnet to the IP address configured on that Routing Engine.

There is actually a simpler solution that allows you to configure an additional IP address that will be active on the master Routing Engine. If there is a switchover, then the IP address moves to the new master Routing Engine.

Let’s use this diagram to see how this can help us.

The EX9208 has two Routing Engines and these are the re0 and re1 groups applied that define the management IP address and the hostname of each Routing Engine:

[edit]
root@EX9208-re0# show groups
re0 {
    system {
        host-name EX9208-re0;
    }
    interfaces {
        fxp0 {
            unit 0 {
                family inet {
                    address 192.168.158.152/23;
                }
            }
        }
    }
}
re1 {
    system {
        host-name EX9208-re1;
    }
    interfaces {
        fxp0 {
            unit 0 {
                family inet {
                    address 192.168.158.153/23;
                }
            }
        }
    }
}

[edit]
root@EX9208-re0#

In this moment, RE0 is the master and RE1 is the backup:

[edit]
root@EX9208-re0# run show chassis routing-engine | no-more | match "Routing Engine|Slot|Current state|Election priority"
Routing Engine status:
  Slot 0:
    Current state                  Master
    Election priority              Master (default)
Routing Engine status:
  Slot 1:
    Current state                  Backup
    Election priority              Backup (default)

[edit]
root@EX9208-re0#

Let’s try to connect to each IP address configured on the two groups. For RE0:

lab@UBUNTU:~$ ssh root@192.168.158.152
Password:
Last login: Fri Sep  2 20:03:59 2016 from 192.168.158.253
--- JUNOS 14.2R6.5 built 2016-04-05 03:35:25 UTC
root@EX9208-re0% cli
root@EX9208-re0>

And for RE1:

lab@UBUNTU:~$ ssh root@192.168.158.153
Password:
Last login: Fri Sep  2 19:35:55 2016 from 192.168.158.253
--- JUNOS 14.2R6.5 built 2016-04-05 03:35:25 UTC
root@EX9208-re1% cli
root@EX9208-re1>

You might remember the IP addresses of each Routing Engine and assume that RE0 is the master, but switchovers can happen without user intervention(hardware failures, unexpected reboots) which will lead you to connect the backup Routing Engine.

The solution is to configure “master-only” for each management interface and allocate the additional IP address.

This means that the re0 and re1 groups will look like this:

[edit]
root@EX9208-re0# show groups
re0 {
    system {
        host-name EX9208-re0;
    }
    interfaces {
        fxp0 {
            unit 0 {
                family inet {
                    address 192.168.158.152/23;
                    address 192.168.158.154/23 {
                        master-only;
                    }
                }
            }
        }
    }
}
re1 {
    system {
        host-name EX9208-re1;
    }
    interfaces {
        fxp0 {
            unit 0 {
                family inet {
                    address 192.168.158.153/23;
                    address 192.168.158.154/23 {
                        master-only;
                    }
                }
            }
        }
    }
}

[edit]
root@EX9208-re0#

Observe that the same IP address is configured for both management interfaces.

Now, let’s test this by doing a switchover. First let’s see the current status of the Routing Engines and try to connect to the IP address that should be active only on the master Routing Engine:

[edit]
root@EX9208-re0# run show chassis routing-engine | no-more | match "Routing Engine|Slot|Current state|Election priority"
Routing Engine status:
  Slot 0:
    Current state                  Master
    Election priority              Master (default)
Routing Engine status:
  Slot 1:
    Current state                  Backup
    Election priority              Backup (default)

[edit]
root@EX9208-re0#

And if we are trying to connect to the new IP address configured, it shoudl take us to the RE0:

lab@UBUNTU:~$ ssh root@192.168.158.154
Password:
Last login: Fri Sep  2 20:17:14 2016 from 192.168.158.253
--- JUNOS 14.2R6.5 built 2016-04-05 03:35:25 UTC
root@EX9208-re0% cli
root@EX9208-re0>

Let’s do now the switchover:

root@EX9208-re0> request chassis routing-engine master switch
warning: Traffic will be interrupted while the PFE is re-initialized
Toggle mastership between routing engines ? [yes,no] (no) yes

Resolving mastership...
Connection to 192.168.158.154 closed by remote host.
Connection to 192.168.158.154 closed.
lab@UBUNTU:~$

We got disconnected and we should try again to connect to the same IP address and check which Routing Engine is the master:

lab@UBUNTU:~$ ssh root@192.168.158.154
Password:
Last login: Fri Sep  2 20:04:28 2016 from 192.168.158.253
--- JUNOS 14.2R6.5 built 2016-04-05 03:35:25 UTC

root@EX9208-re1%
root@EX9208-re1% cli
root@EX9208-re1>

root@EX9208-re1> edit
Entering configuration mode

[edit]
root@EX9208-re1# run show chassis routing-engine | no-more | match "Routing Engine|Slot|Current state|Election priority"
Routing Engine status:
  Slot 0:
    Current state                  Backup
    Election priority              Master (default)
Routing Engine status:
  Slot 1:
    Current state                  Master
    Election priority              Backup (default)

[edit]
root@EX9208-re1#

I hope you found this post informative and this is how you can configure an IP address that you can use to always connect to the master Routing Engine.

The following two tabs change content below.

• Bio
• Latest Posts

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Latest posts by Paris ARAU (see all)

• Junos Fusion – Part IV – Satellite policies and uplink failure detection - 30 July 2018
• Junos Fusion – Part III – Satellite commands and traffic forwarding - 16 July 2018
• Junos Fusion – Part II – Configuration, Administration and Operation - 16 July 2018
• Junos Fusion – Part I – Overview, Components, Ports and Software - 11 July 2018
• Vagrant – Part IV – Network topology using Juniper and Cumulus - 26 April 2018