How To Configure CUBE High Availability
CUBE HA Overview
- Preservation of media and signaling for active calls
- Preservation of calls in process where media has not been established yet
- Preservation of transcoded calls
CUBE HA does not support the following:
- IPv6 addressing
- SCCP based media resources such as conference bridges, transcoders, mtp, etc.
- SRST
High Availability is similar in configuration to HSRP. However it is specifically designed for the newest Cisco Unified Border Element routers and maintaining calls in the event of a failure of one of the routers.
Calls are maintained intact without any disruption to the call. In the following image you can see a call established with the active router of an HA Pair.
When the active router becomes unavailable the standby becomes available. A Virtual IP Address is used and all routing is transferred to the standby routers Virtual IP (this virtual IP address is the same as the active router). The media and signaling of the call then continues on the standby router as if there were no interruption.
The two CUBE routers should be the same hardware and IOS version. For example you cannot have a 3900 router with an ISR 4K router as the configuration is different. In the ISR-G2 routers HA is accomplished using Hot Standby Routing Protocol(HSRP). HSRP will not be covered at this time. In ASR 1000, ISR 4K, and CSR1000 routers this is done with the Redundancy Group Infrastructure configuration which is what we are covering here.
CUBE HA Configuration
We are going to go over each configuration and how it fits in with the overall picture. Then we will go over how to verify the configuration and test it, This configuration assumes that we have an internal and an external interface there is also an interface for the checkpointing configuration which will be explained. The following network topology is what we will be working on.
Monitoring Configuration
First, we need to monitor the status of the internal and external
interfaces of vCUBE- this is Gig1 and Gig2. Monitoring the line-protocol status
of the interfaces allows the redundancy application to determine when a
resource has gone offline.
track 1 interface GigabitEthernet1
line-protocol
track 2 interface GigabitEthernet2
line-protocol
Redundancy Application Configuration
Next we will configure the
redundancy options.
redundancy
application
redundancy
group 1
name cubha
priority 101
timers delay 30 reload 60
control GigabitEthernet3 protocol 1
data GigabitEthernet3
track 1 shutdown
track 2 shutdown
The default priority is 100. The
router with the highest priority will be the active router. If something
happens to either the active router or the standby router, the priority of the
router is decremented by the decrement value. This can be configured. If the
priority of the active router goes below the standby router, the standby router
becomes the active router in the switchover.
Other circumstances which will cause a
switchover:
·
Reload or loss of power on the active router.
·
The command “redundancy application reload group
rg-number self” is issued to manually reload the active router.
Timers
timers delay 30 reload 60
Delay - The amount of time to delay
RG group’s initialization and role negotiation after the interface comes up –
Default 30 seconds. Range is 0-10000 seconds
Reload - The amount of time to
delay RG group initialization and role-negotiation after a reload – Default 60
seconds. Range is 0-10000 seconds
Checkpointing configuration
data GigabitEthernet3
This command configures the
interface used for checkpointing. “Checkpointing refers to the facility or
architecture to implement stateful switchover (SSO). It provides the mechanisms
to help synchronize state data between the active and standby route processors
or chassis in a consistent, repeatable, and well-ordered manner.”
control GigabitEthernet3 protocol 1
This command configures the
interface to exchange keepalive messages between the two routers.
track 1 shutdown
track 2 shutdown
These commands correlate to if Gig1
and Gig2 line protocol goes down - which will trigger the failover process.
Voice service voip Configuration
Let’s now turn on CUBE redundancy –
I am assuming other configurations such as interface ip addressing and voice
service voip configuration have been done.
voice service voip
redundancy-group 1
This command will prompt you for a
reload of the router. This can be done
now or after you have configured the rest.
However, a reload must happen before the HA configuration will function
correctly.
Interface Configuration
Next we will configure the internal
and external interfaces of the router. We will also need to configure Gig3
which will be used for the checkpointing or keepalives between the two routers.
interface
GigabitEthernet1
redundancy rii 1
redundancy group 1 ip 172.16.10.1 exclusive the same virtual ip
address will be used
on
the second CUBE
interface
GigabitEthernet2
redundancy rii 2
redundancy group 1 ip 10.10.10.1 exclusive the same virtual ip
address will be used
on
the second CUBE
The Command “redundancy rii”
(Redundant Interface Identifier) is used for generating a Virtual MAC (VMAC).
Use the same rii ID value on each
interface of each CUBE router that has the same Virtual IP Address (VIP). The
RG group number that was configured in the redundancy configuration is used
when assigning the Virtual IP Address (VIP).
The exclusive command means that
the interface that is associated with an active redundancy group exclusively
owns the VIP Address and the Virtual MAC. When failover occurs, the ownership
of the VIP and Virtual MAC changes. The interface associated with the now active
redundancy group programs the interface's Ethernet controller to accept the
packets going to the Virtual MAC.
The checkpointing interface only
needs the ip address. No other
configuration is necessary.
Both CUBE routers must be connected
to the same switch and be configured with an IP Address on the same subnet
interface
GigabitEthernet3
ip address 10.10.1.2 255.255.255.0
no shut
Configuration for the Second Router
Most of the configuration on the
second router will be exactly the same.
Of course, the interface ip addresses will be different. The priority in
the redundancy application will be lower than the desired active router. But,
the virtual IP address will always be the same. All dial-peers, voice
translations, etc. will all be the same so that the all functionality will be
the same upon failover.
track 1 interface GigabitEthernet1
line-protocol
track 2 interface GigabitEthernet2
line-protocol
!
redundancy
application
redundancy
group 1
name cubeha
priority 100 Must be lower
value than the first CUBE
timers delay 30 reload 60
control GigabitEthernet3 protocol 1
data GigabitEthernet3
track 1 shutdown
track 2 shutdown
!
voice service voip
redundancy-group 1 Again, this will
prompt for reload
!
interface GigabitEthernet1
redundancy
rii 1
redundancy
group 1 ip 172.16.10.1 exclusive
!
interface GigabitEthernet2
redundancy
rii 2
redundancy
group 1 ip 10.10.10.1 exclusive
!
interface GigabitEthernet3
ip
address 10.10.1.1 255.255.255.0
no
shut
Save the configuration on both
routers and reload. Even if you reloaded before when prompted.
Verification and Testing
Now let’s verify the configuration.
CUBE1#sh redundancy application
group 1
Group ID:1
Group Name:cubeha
Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE Shows the role of this
router which means CUBE 1 is
active
Peer Role: STANDBY Shows the role of the
second router which means CUBE 2
is in Standby
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes
RF Domain: btob-one
RF state: ACTIVE
Peer RF state: STANDBY HOT
CUBE2#sh redundancy application
group 1
Group ID:1
Group Name:cubeha
Administrative State: No Shutdown
Aggregate operational state : Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes
RF Domain: btob-one
RF state: STANDBY HOT
Peer RF state: ACTIVE
Testing the configuration
To test the HA configuration we
will want to get a call going through the CUBE router.
Then enter the following command:
vCUBE1#redundancy application
reload group 1 self
This can also be done on the
secondary router by putting in “peer” at the end of the command instead of “self”.
This will reload the router.
You will see that the call has transferred over to CUBE2. You can verify this by entering “show sip
call”
Please check out my YouTube Channel
Nberecbrev_dzu1982 Robert Alvey https://www.arrowsisters.com/profile/fabyanahyaleena/profile
ReplyDeletetrademdowge