Interdomain Multicast using MSDP

This post is talking about using MSDP to join multicast domains together.

The topology here is very simple even if it does consist of 6 routers.

R1-R2-R3---------R4-R5-R6

Multicast Domain 1

R1, R2 and R3 use EIGRP as their IGP

AutoRP is used for RP election and R3 will be the RP

Multicast Domain 2

R4, R5 and R6 use OSPF as their IGP
AutoRP is used for RP election and R4 will be the RP


Both Multicast Domains are connected using BGP (R3 AS 3) and (R4 AS 4)
All routers have their loopback0 interfaces and interconnecting interfaces running PIM sparse-mode so we are using "ip pim autorp listener"

Note: AutoRP advertisements are blocked between R3 and R4 on their corresponding interfaces "ip multicast boundary 1" is applied where the 1 refers to an access list which blocks AutoRP rp candidate and mapping agent advertisements but allows all other multicast traffic

The base configurations are shown below

R1
hostname R1
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ip pim sparse-mode
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.12 point-to-point
 description PVC to R2
 ip address 10.1.12.1 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 102
!
router eigrp 123
 network 1.1.1.1 0.0.0.0
 network 10.1.12.1 0.0.0.0
 no auto-summary
!
ip pim autorp listener

R2
hostname R2
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
!
interface Loopback23
 ip address 23.23.23.2 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.21 point-to-point
 description PVC to R1
 ip address 10.1.12.2 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 201
!
interface Serial0/0.23 point-to-point
 description PVC to R3
 ip address 10.1.23.2 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 203
!
router eigrp 123
 network 2.2.2.2 0.0.0.0
 network 10.1.12.2 0.0.0.0
 network 10.1.23.2 0.0.0.0
 no auto-summary
!
ip pim autorp listener

R3
hostname R3
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip pim sparse-mode
!
interface Loopback34
 ip address 34.34.34.3 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.32 point-to-point
 description PVC to R2
 ip address 10.1.23.3 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 302
!
interface Serial0/0.34 point-to-point
 description PVC to R4
 ip address 10.1.34.3 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 304
 ip multicast boundary 1
!
router eigrp 123
 network 3.3.3.3 0.0.0.0
 network 10.1.23.3 0.0.0.0
 no auto-summary
!
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 network 34.34.34.3 mask 255.255.255.255
 neighbor 10.1.34.4 remote-as 4
 no auto-summary
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 3
ip pim send-rp-discovery Loopback0 scope 3
ip msdp peer 34.34.34.4 connect-source Loopback34
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any

R4
hostname R4
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip pim sparse-mode
!
interface Loopback34
 ip address 34.34.34.4 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
!
interface Serial0/0.43 point-to-point
 description PVC to R3
 ip address 10.1.34.4 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 403
 ip multicast boundary 1
!
interface Serial0/0.45 point-to-point
 description PVC to R5
 ip address 10.1.45.4 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 405
!
router ospf 1
 network 4.4.4.4 0.0.0.0 area 0
 network 10.1.45.4 0.0.0.0 area 0
!
router bgp 4
 no synchronization
 bgp log-neighbor-changes
 network 34.34.34.4 mask 255.255.255.255
 neighbor 10.1.34.3 remote-as 3
 no auto-summary
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 3
ip pim send-rp-discovery Loopback0 scope 3
ip msdp peer 34.34.34.3 connect-source Loopback34
!
access-list 1 deny   224.0.1.39
access-list 1 deny   224.0.1.40
access-list 1 permit any

R5
hostname R5
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip pim sparse-mode
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/0.54 point-to-point
 ip address 10.1.45.5 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 504
!
interface Serial0/0.56 point-to-point
 ip address 10.1.56.5 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 506
!
router ospf 1
 log-adjacency-changes
 network 5.5.5.5 0.0.0.0 area 0
 network 10.1.45.5 0.0.0.0 area 0
 network 10.1.56.5 0.0.0.0 area 0
!
ip pim autorp listener

R6
hostname R6
!
no ip domain lookup
ip multicast-routing
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
 ip pim sparse-mode
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/0.65 point-to-point
 ip address 10.1.56.6 255.255.255.0
 ip pim sparse-mode
 frame-relay interface-dlci 605
!
router ospf 1
 log-adjacency-changes
 network 6.6.6.6 0.0.0.0 area 0
 network 10.1.56.6 0.0.0.0 area 0
!
ip pim autorp listener

Quick verification of RP Mappings

R1/R2/R3 should have R3 as the RP:

R1#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:13:05, expires: 00:02:45

R2#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:13:25, expires: 00:02:23

R3#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
  RP 3.3.3.3 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:14:41, expires: 00:02:17


R4/R5/R6 will use R4 as their RP:

R4#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:11:28, expires: 00:02:45

R5#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:04:49, expires: 00:02:11

R6#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2v1
    Info source: 4.4.4.4 (?), elected via Auto-RP
         Uptime: 00:05:04, expires: 00:02:55

R3 and R4 each have loopback34 advertised into BGP and use this for MSDP peering.  MSDP is used to transmit the knowledge of multicast sources between domains.  PIM does not need to be run on these interfaces

R3#sh ip msdp peer
MSDP Peer 34.34.34.4 (?), AS 4
  Connection status:
    State: Up, Resets: 0, Connection source: Loopback34 (34.34.34.3)
    Uptime(Downtime): 00:04:40, Messages sent/received: 5/5
    Output messages discarded: 0
    Connection and counters cleared 00:16:10 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled

R4#sh ip msdp peer
MSDP Peer 34.34.34.3 (?), AS 3
  Connection status:
    State: Up, Resets: 0, Connection source: Loopback34 (34.34.34.4)
    Uptime(Downtime): 00:04:51, Messages sent/received: 5/5
    Output messages discarded: 0
    Connection and counters cleared 00:12:34 ago
  SA Filtering:
    Input (S,G) filter: none, route-map: none
    Input RP filter: none, route-map: none
    Output (S,G) filter: none, route-map: none
    Output RP filter: none, route-map: none
  SA-Requests:
    Input filter: none
  Peer ttl threshold: 0
  SAs learned from this peer: 0
  Input queue size: 0, Output queue size: 0
  MD5 signature protection on MSDP TCP connection: not enabled

So with everything looking ok, our objective is to verify multicast traffic can traverse the domains by having  R1 Loopback0 join multicast group 239.1.1.1 with R6 receive a response when it pings that group

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int loopback0
R1(config-if)#ip igmp join-group 239.1.1.1

Lets enable a debug to see if check ping packets arrive (we could use debug ip icmp however that presents less detail):

R1(config-if)#access-list 101 permit icmp any any
R1(config)#do deb ip pack detail 101
IP packet debugging is on (detailed) for access list 101
R1#end
*Mar  1 00:25:49.379: %SYS-5-CONFIG_I: Configured from console by console

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:42/00:02:14, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:05:42/00:02:14

R1 has R2 as the RPF neighbor for *,239.1.1.1

R2#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:04:01/00:03:25, RP 3.3.3.3, flags: S
  Incoming interface: Serial0/0.23, RPF nbr 10.1.23.3
  Outgoing interface list:
    Serial0/0.21, Forward/Sparse, 00:04:01/00:03:25

R2 has R3 as the RPF neighbor for *,239.1.1.1

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:04:27/00:02:57, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:04:27/00:02:57

R3 has nothing as the RPF neighbor for *,239.1.1.1

When R6 pings 239.1.1.1 it's RP (R4) will discover it as a new multicast source and advertise it to its MSDP peer (R3)

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 0 entries
R3#deb ip msdp routes
MSDP Routes debugging is on

R6#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.


Well that was unsuccessful let's see if R3 learnt about our multicast sources:

R3#
*Mar  1 00:04:42.431: MSDP(0): (6.6.6.6/32, 239.1.1.1), accepted
*Mar  1 00:04:42.479: MSDP(0): (10.1.56.6/32, 239.1.1.1), accepted

Yes it did - what did we see on R1?

R1#
*Mar  1 00:04:50.315: IP: s=10.1.12.1 (local), d=6.6.6.6, len 100, unroutable
*Mar  1 00:04:50.319:     ICMP type=0, code=0
*Mar  1 00:04:50.379: IP: s=10.1.12.1 (local), d=10.1.56.6, len 100, unroutable
*Mar  1 00:04:50.379:     ICMP type=0, code=0

We can see that R1 must have recieved the ping because it's attempting to respond, however R6 didn't obtain a reply since R1 doesn't know how to get back to it

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:07:35/00:02:42, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:07:35/00:02:19
(10.1.56.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42
(6.6.6.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42

We can even see that R1 is trying to build a specific path to get to the multicast sources 10.1.56.6 (R6 S0/0.65) and 6.6.6.6 (R6 Lo0) but is failing the RPF checks

R2#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:39/00:03:11, RP 3.3.3.3, flags: S
  Incoming interface: Serial0/0.23, RPF nbr 10.1.23.3
  Outgoing interface list:
    Serial0/0.21, Forward/Sparse, 00:05:39/00:02:46

R2 is able to use R3 as its RPF neighbor and pass traffic destined to 239.1.1.1 out to R1

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:05:41/00:03:02, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:05:41/00:02:41

R3 knows that someone at R2 or further downstream is subscribed to group 239.1.1.1

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 2 entries
(6.6.6.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 0, 00:02:20/00:05:10, Peer 34.34.34.4
(10.1.56.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 0, 00:02:20/00:05:10, Peer 34.34.34.4

So R3 knows about the sources and that the RP is Lo0 on R4 but doesn't know where the sources came from (BGP/AS 0)

Lets fix this by putting the sources into BGP

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router bgp 4
R4(config-router)#redistribute ospf 1
R4(config-router)#end

Let's see if that's resolved things:

R3#sh ip msdp sa-cache
MSDP Source-Active Cache - 2 entries
(6.6.6.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 4, 00:05:40/00:05:31, Peer 34.34.34.4
(10.1.56.6, 239.1.1.1), RP 4.4.4.4, BGP/AS 4, 00:05:40/00:05:31, Peer 34.34.34.4

R3 has determined these source are via BGP and can establish paths back to the sources

R3#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:08:03/00:03:17, RP 3.3.3.3, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:08:03/00:03:17
(6.6.6.6, 239.1.1.1), 00:00:19/00:02:40, flags: M
  Incoming interface: Serial0/0.34, RPF nbr 10.1.34.4
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:00:19/00:03:17
(10.1.56.6, 239.1.1.1), 00:00:19/00:02:40, flags: M
  Incoming interface: Serial0/0.34, RPF nbr 10.1.34.4
  Outgoing interface list:
    Serial0/0.32, Forward/Sparse, 00:00:19/00:03:17

This doesn't work for R1 though as it's not aware of how to get to these sources (RPF nbr 0.0.0.0)

R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:07:35/00:02:42, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:07:35/00:02:19
(10.1.56.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42
(6.6.6.6, 239.1.1.1), 00:00:17/00:02:42, flags: LJ
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:17/00:02:42

So we need to redistribute those routes into eigrp

R3#conf t
R3(config)#router eigrp 123
R3(config-router)#redistribute bgp 3 metric 1 1 1 1 1
R3(config-router)#end

This should give us a return route for the ping and resolve the RPF for the shortest path to the sources

R1#sh ip route eigrp | i EX 

D EX    34.34.34.3 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    34.34.34.4 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    6.6.6.6 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
D EX    10.1.56.0 [170/2561024256] via 10.1.12.2, 01:33:57, Serial0/0.12
R1#sh ip mroute | s 239.1.1.1
(*, 239.1.1.1), 00:13:44/stopped, RP 3.3.3.3, flags: SJCL
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:13:44/00:02:18
(10.1.56.6, 239.1.1.1), 00:00:05/00:02:56, flags: LJT
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:05/00:02:54
(6.6.6.6, 239.1.1.1), 00:00:05/00:02:56, flags: LJT
  Incoming interface: Serial0/0.12, RPF nbr 10.1.12.2
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:00:05/00:02:54

So lets give it another shot:

R6#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.1.12.1, 32 ms
Reply to request 0 from 10.1.12.1, 32 ms

On R1 we see
R1#
*Mar  1 00:12:47.815: IP: tableid=0, s=10.1.12.1 (local), d=10.1.56.6 (Serial0/0.12), routed via FIB
*Mar  1 00:12:47.815: IP: s=10.1.12.1 (local), d=10.1.56.6 (Serial0/0.12), len 100, sending
*Mar  1 00:12:47.815:     ICMP type=0, code=0
*Mar  1 00:12:47.823: IP: tableid=0, s=10.1.12.1 (local), d=6.6.6.6 (Serial0/0.12), routed via FIB
*Mar  1 00:12:47.827: IP: s=10.1.12.1 (local), d=6.6.6.6 (Serial0/0.12), len 100, sending
*Mar  1 00:12:47.827:     ICMP type=0, code=0

Success!

Backup interfaces (and some EEM)

This post is discussing the "backup interface" command and gives an example on how it could be used.

The backup interface as its name suggests specifies an interface that is not normally active but is brought online once a primary interface's line protocol goes down.  This is a router function, however for switches there is a feature (flexlinks) which is very similar (switchport backup interface) but has more layer 2 features such as keeping the flexlink peer updated with which interface should be associated with learnt MAC addresses, however that is not the focus on this posting.

On the primary interface, we specify which interface shall be our backup interface.

interface PRIMARYINT

  backup interface BACKUPINT

Once this occurs, the backup interface is placed in standby mode and the interface is brought down.

When the primary interface fails (failure does not include administratively shutting down the primary interface as IOS believes you are doing this on purpose) the backup interface is brought online on the physical and then line level.   Because of this only one side of a link needs to be set up this way.

In the example below we are going to have 3 Routers.   R1 is connected to R2 via Frame Relay, R2 is connected to R3 via Frame Relay, and R1 is connected to R3 via HDLC.  R1 will be configured with a backup interface (the HDLC will be the backup for the Frame Relay)  We'll be running a dynamic routing protocol over these links as well.

Here are the configurations:

R1
hostname R1
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
 clock rate 2000000
!
interface Serial0/1
 description direct to R3
 ip address 10.1.13.1 255.255.255.0
 clock rate 64000
!
interface Serial0/0.12 point-to-point
 backup interface Serial0/1
 frame-relay interface-dlci 102 ppp Virtual-Template1
  class FREEK
!
interface Virtual-Template1
 ip address 10.1.12.1 255.255.255.0
!
router eigrp 100
 network 1.1.1.1 0.0.0.0
 network 10.1.12.1 0.0.0.0
 network 10.1.13.1 0.0.0.0
 no auto-summary
!
map-class frame-relay FREEK
 frame-relay end-to-end keepalive mode bidirectional

R2
hostname R2
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Serial0/0
 description FR Switch
 no ip address
 encapsulation frame-relay
 clock rate 2000000
 frame-relay interface-dlci 203 ppp Virtual-Template3
!
interface Serial0/0.21 point-to-point
 description PVC to R1
 frame-relay interface-dlci 201 ppp Virtual-Template1
  class FREEK
!
interface Virtual-Template1
 ip address 10.1.12.2 255.255.255.0
!
interface Virtual-Template3
 ip address 10.1.23.2 255.255.255.0
!
router eigrp 100
 network 2.2.2.2 0.0.0.0
 network 10.1.12.2 0.0.0.0
 network 10.1.23.2 0.0.0.0
 no auto-summary
map-class frame-relay FREEK
 frame-relay end-to-end keepalive mode bidirectional

R3
hostname R3
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-dlci 302 ppp Virtual-Template1
!
interface Serial0/1
 ip address 10.1.13.3 255.255.255.0
 ip summary-address eigrp 100 0.0.0.0 0.0.0.0 255
!
interface Virtual-Template1
 ip address 10.1.23.3 255.255.255.0
!
router eigrp 100
 network 3.3.3.3 0.0.0.0
 network 10.1.13.3 0.0.0.0
 network 10.1.23.3 0.0.0.0
 no auto-summary

Lets look at some of the interfaces here

R1>sh ip int brief | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM  standby mode          down
Virtual-Access1            10.1.12.1       YES TFTP   up                    up 
Virtual-Template1          10.1.12.1       YES NVRAM  down                  down
Loopback0                  1.1.1.1         YES NVRAM  up                    up

Firstly we can see that Serial0/1 is in a standby mode condition and the line protocol is down.  Unfortunately there appears to be no regular show command to determine which interface has S0/1 as its backup interface, so we need to examine the router configuration

R1#sh run | i ^interface|^ backup
interface Loopback0
interface FastEthernet0/0
interface Serial0/0
interface Serial0/0.12 point-to-point
 backup interface Serial0/1
interface FastEthernet0/1
interface Serial0/1
interface Virtual-Template1

Here we can see that S0/0.12 has S0/1 as its backup interface

Virtual-Templates appear as down because they aren't actually active interfaces - they have a limited amount of configuration which is used as a baseline config by the Virtual-Access interfaces.  Each Virtual-Access represents a dynamic instance of an individual connection.

R1#sh int virtual-template 1
Virtual-Template1 is down, line protocol is down
  Hardware is Virtual Template interface
  Internet address is 10.1.12.1/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
....

Looking at Virtual-Access 1

R1#sh int virtual-access 1
Virtual-Access1 is up, line protocol is up
  Hardware is Virtual Access interface
  Internet address is 10.1.12.1/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP
  PPPoFR vaccess, cloned from Virtual-Template1
  Vaccess status 0x44
  Bound to Serial0/0.12 DLCI 102, Cloned from Virtual-Template1, loopback not set
  Keepalive set (10 sec)
....

We can see that if a PPP over Frame Relay connection using the PVC on S0/0.12 DLCI 102 and taking the the base IP configuration from the virtual-template.  The interface is in an up/up state because the PVC is up and there is a PPP connection established with its peer.

R1#sh frame pvc int s0/0.12 | i PVC STATUS
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE (EEK UP), INTERFACE = Serial0/0.12

On S0/0.12 we can see that we are using Frame Relay End-to-End Keep alives.  If EEK messages with our peer are non responded to, interface S0/0.12 will have its line protocol go down.

Click here if you would like to know more about using Frame-Relay Keep Alives

R1#sh int s0/01 | i line
Serial0/1 is standby mode, line protocol is down

Since S0/1 is the backup interface for S0/0.12, S0/1 will then be brought out of standby mode and the physical interface will go active.  Once S0/0.12 responds to EEK messages again, S0/1 will re-enter standby state and the physical interface will go down.

R2#sh ip int bri | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Virtual-Access1            10.1.23.2       YES TFTP   up                    up
Virtual-Template1          10.1.12.2       YES NVRAM  down                  down
Virtual-Access2            10.1.12.2       YES TFTP   up                    up
Virtual-Template3          10.1.23.2       YES NVRAM  down                  down
Loopback0                  2.2.2.2         YES NVRAM  up                    up

R2 has PVCs with R1 and R3.  To ensure that FR EEK operates, as expected, a subinterface is created in order for it too to go down if EEK messages are not responded to.

R3#sh ip int bri | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.3       YES NVRAM  up                    down
Virtual-Access1            10.1.23.3       YES TFTP   up                    up
Virtual-Template1          10.1.23.3       YES NVRAM  down                  down
Loopback0                  3.3.3.3         YES NVRAM  up                    up

R3 has a PVC to R2, and a low speed link to R1.  R3 will advertise a default route to R1 using a summarization.  As we don't want R3 to have a default route to null0, we shall set the admin distance of the summary to 255 (which means it wont get installed in the local routing table) as a general rule if we are doing route summarization we actually desire the route to null0 as it is used to sink traffic rate than potentially have traffic bouncing around the network until the TTL expires.

R3#sh run int s0/1
Building configuration...

Current configuration : 133 bytes
!
interface Serial0/1
 ip address 10.1.13.3 255.255.255.0
 ip summary-address eigrp 100 0.0.0.0 0.0.0.0 255

As this interface is normally down (brought up by R1 to come up only when its PVC to R2 is down), R1 will not distribute the default to R2

We've explained what should occur, lets test things - first lets start in the normal operating state:

R1
R1#sh ip int brief | ex unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM  standby mode          down
Virtual-Access1            10.1.12.1       YES TFTP   up                    up
Virtual-Template1          10.1.12.1       YES NVRAM  down                  down
Loopback0                  1.1.1.1         YES NVRAM  up                    up

R1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.12.2, 00:28:38, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/5273600] via 10.1.12.2, 00:28:38, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.23.0/24 [90/5145600] via 10.1.12.2, 00:28:38, Virtual-Access1
D       10.1.23.3/32 [90/5145600] via 10.1.12.2, 00:28:38, Virtual-Access1

R1#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

  1 10.1.12.2 8 msec *  12 msec

R1#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

  1 10.1.12.2 0 msec 4 msec 0 msec
  2 10.1.23.3 8 msec *  16 msec

R2
R2#sh ip int bri | exc unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Virtual-Access1            10.1.23.2       YES TFTP   up                    up 
Virtual-Template1          10.1.12.2       YES NVRAM  down                  down
Virtual-Access2            10.1.12.2       YES TFTP   up                    up 
Virtual-Template3          10.1.23.2       YES NVRAM  down                  down
Loopback0                  2.2.2.2         YES NVRAM  up                    up 
R2#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2713600] via 10.1.12.1, 00:29:32, Virtual-Access2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2713600] via 10.1.23.3, 01:10:30, Virtual-Access1
R2#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

  1 10.1.12.1 4 msec *  16 msec
R2#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

  1 10.1.23.3 0 msec *  12 msec


R3
R3#sh ip int bri | exc unassigned
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.3       YES NVRAM  up                    down
Virtual-Access1            10.1.23.3       YES TFTP   up                    up 
Virtual-Template1          10.1.23.3       YES NVRAM  down                  down
Loopback0                  3.3.3.3         YES NVRAM  up                    up 
R3#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/5273600] via 10.1.23.2, 00:25:01, Virtual-Access1
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.23.2, 00:30:40, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.12.1/32 [90/5145600] via 10.1.23.2, 00:30:43, Virtual-Access1
D       10.1.12.0/24 [90/5145600] via 10.1.23.2, 00:25:02, Virtual-Access1
R3#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

  1 10.1.23.2 4 msec 0 msec 4 msec
  2 10.1.12.1 4 msec *  16 msec
R3#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

  1 10.1.23.2 0 msec *  24 msec

So the Baseline is ok, we have reachability only using the Frame Relay links, now  Lets cause the PVC between R1 and R2 to fail.  The routers are synched to the same time source so the timestamps will have meaning across routers:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#shut
R2(config-subif)#end
Mar  1 00:56:16.133: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Virtual-Access2) is down: holding time expired
Mar  1 00:56:25.593: %FR_EEK-5-FAILED: Interface Serial0/0.21 - DLCI 201
Mar  1 00:56:25.609: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
Mar  1 00:56:26.605: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down



EIGRP detects the failure before FREEK does and the Virtual-Access interface is brought down

On R1 we see:
Mar  1 00:56:15.779: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is down: holding time expired
Mar  1 00:56:25.823: %FR_EEK-5-FAILED: Interface Serial0/0.12 - DLCI 102
Mar  1 00:56:25.835: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
Mar  1 00:56:26.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
Mar  1 00:56:28.275: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
Mar  1 00:56:29.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
Mar  1 00:56:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is up: new adjacency

EIGRP detects the failure before FREEK does and the Virtual-Access interface is brought down, and the HDLC interface (S0/1) is brought up and an EIGRP adjacency is formed

On R3 we see:
Mar  1 00:56:39.061: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
Mar  1 00:56:41.772: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.1 (Serial0/1) is up: new adjacency


So we can definitely know that when FREEK failed R1 brought int S0/1 up

R1#sh ip int bri | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM  up                    up 
Virtual-Access1            10.1.12.1       YES TFTP   down                  down
Virtual-Template1          10.1.12.1       YES NVRAM  down                  down
Loopback0                  1.1.1.1         YES NVRAM  up                    up 
R1#sh ip route eigrp
D*   0.0.0.0/0 [90/2297856] via 10.1.13.3, 00:02:49, Serial0/1

We're getting the default from R3, and all traffic is traversing the HDLC link via R3

R1#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

  1 10.1.13.3 4 msec 4 msec 0 msec
  2 10.1.23.2 4 msec *  20 msec
R1#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

  1 10.1.13.3 0 msec *  24 msec

Lets check R2

R2#sh ip int bri | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Virtual-Access1            10.1.23.2       YES TFTP   up                    up 
Virtual-Template1          10.1.12.2       YES NVRAM  down                  down
Virtual-Access2            10.1.12.2       YES TFTP   down                  down
Virtual-Template3          10.1.23.2       YES NVRAM  down                  down
Loopback0                  2.2.2.2         YES NVRAM  up                    up 
R2#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/4857856] via 10.1.23.3, 00:04:47, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2713600] via 10.1.23.3, 01:23:38, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D       10.1.13.0/24 [90/4729856] via 10.1.23.3, 00:04:50, Virtual-Access1

R2#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

  1 10.1.23.3 4 msec 0 msec 4 msec
  2 10.1.13.1 4 msec *  4 msec
R2#trace 3.3.3.3 so lo0

Type escape sequence to abort.
Tracing the route to 3.3.3.3

  1 10.1.23.3 4 msec *  4 msec


Yes, understandably with the PVC to R1 down, R2 can only go through R3, and speaking of R3:

R3#sh ip int brie | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.3       YES NVRAM  up                    up 
Virtual-Access1            10.1.23.3       YES TFTP   up                    up 
Virtual-Template1          10.1.23.3       YES NVRAM  down                  down
Loopback0                  3.3.3.3         YES NVRAM  up                    up 
R3#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2297856] via 10.1.13.1, 00:06:20, Serial0/1
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.23.2, 00:44:12, Virtual-Access1
R3#trace 1.1.1.1 so lo0

Type escape sequence to abort.
Tracing the route to 1.1.1.1

  1 10.1.13.1 0 msec *  12 msec
R3#trace 2.2.2.2 so lo0

Type escape sequence to abort.
Tracing the route to 2.2.2.2

  1 10.1.23.2 0 msec *  24 msec

All good. Lets verify that things return to normal once the PVC between R1 and R2 is restored

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#no shut
R2(config-subif)#end

Looking at R1 we see:
Mar  1 01:09:37.623: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Mar  1 01:09:38.319: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is down: interface down
Mar  1 01:09:38.623: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Mar  1 01:09:40.279: %LINK-5-CHANGED: Interface Serial0/1, changed state to standby mode
Mar  1 01:09:40.931: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is up: new adjacency
Mar  1 01:09:41.279: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

R2 shows:
Mar  1 01:09:37.595: %LINK-3-UPDOWN: Interface Virtual-Access2, changed state to up
Mar  1 01:09:38.615: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up
Mar  1 01:09:40.899: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.1 (Virtual-Access2) is up: new adjacency

And R3:
Mar  1 01:09:52.748: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.1 (Serial0/1) is down: holding time expired
Mar  1 01:10:09.095: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

We can see that once the PPPoFR Link between R1 and R2 comes up quickly and that R1 S0/1 is put into standby mode and the direct link between R1 and R3 is brought back down

R1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.12.2, 00:04:10, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/5273600] via 10.1.12.2, 00:04:10, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.23.0/24 [90/5145600] via 10.1.12.2, 00:04:10, Virtual-Access1
D       10.1.23.3/32 [90/5145600] via 10.1.12.2, 00:04:10, Virtual-Access1
R1#ping 2.2.2.2 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R2#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/2713600] via 10.1.12.1, 00:04:53, Virtual-Access2
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/2713600] via 10.1.23.3, 01:36:43, Virtual-Access1

R2#ping 3.3.3.3 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R3#sh ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/5273600] via 10.1.23.2, 00:05:33, Virtual-Access1
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.23.2, 00:56:37, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.12.1/32 [90/5145600] via 10.1.23.2, 00:05:48, Virtual-Access1
D       10.1.12.0/24 [90/5145600] via 10.1.23.2, 00:05:33, Virtual-Access1

So that's backup interfaces...  Of course, there are other ways to implement similar concepts.... EEM for example:

On R1 we insert the config below - note: we need to initially shutdown S0/1 because we don't want both interfaces to be active at the same time, and normally subinterface status is not logged, since we want match upon S0/0.12 going up or down, we will turn that on


interface Serial0/1
 shutdown
!
interface Serial0/0.12
 no backup interface Serial0/1
 logging event subif-link-status
!
event manager applet FR-Down
 event syslog pattern "%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to down"
 action 1.0 cli command "enable"
 action 2.0 cli command "conf t"
 action 3.0 cli command "int s0/1"
 action 4.0 cli command "no shut"
event manager applet FR-Up
 event syslog pattern "%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to up"
 action 1.0 cli command "enable"
 action 2.0 cli command "conf t"
 action 3.0 cli command "int s0/1"
 action 4.0 cli command "shut"
!

Now let's test it:

R1#sh ip int bri | exc unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM  administratively down down
Virtual-Access1            10.1.12.1       YES TFTP   up                    up 
Virtual-Template1          10.1.12.1       YES NVRAM  down                  down
Loopback0                  1.1.1.1         YES NVRAM  up                    up  


R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#shut
R2(config-subif)#end


On R1 we see:
Mar  1 04:51:58.346: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is down: holding time expired
Mar  1 04:52:13.382: %FR_EEK-5-FAILED: Interface Serial0/0.12 - DLCI 102
Mar  1 04:52:13.390: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to down
Mar  1 04:52:13.426: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
Mar  1 04:52:13.790: %SYS-5-CONFIG_I: Configured from console by vty0
Mar  1 04:52:14.426: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
Mar  1 04:52:15.730: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up
Mar  1 04:52:16.738: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to up
Mar  1 04:52:21.338: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is up: new adjacency

It's a similar turn of events as to what happens with the backup interface, however we see that a configuration change was made (this is where S0/1 has the no shut applied)

R1#sh ip int bri | ex unas
Interface                  IP-Address      OK? Method Status                Protocol
Serial0/1                  10.1.13.1       YES NVRAM  up                    up 
Virtual-Access1            10.1.12.1       YES TFTP   down                  down
Virtual-Template1          10.1.12.1       YES NVRAM  down                  down
Loopback0                  1.1.1.1         YES NVRAM  up                    up 

R1#sh ip route eigrp
D*   0.0.0.0/0 [90/2297856] via 10.1.13.3, 00:00:57, Serial0/1
So far, so good - lets restore the PVC

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s0/0.21
R2(config-subif)#no shut
R2(config-subif)#end

On R1 we see:
Mar  1 04:54:07.366: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0.12, changed state to up
Mar  1 04:54:07.410: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
Mar  1 04:54:07.654: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.13.3 (Serial0/1) is down: interface down
Mar  1 04:54:07.694: %SYS-5-CONFIG_I: Configured from console by vty0
Mar  1 04:54:07.926: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.1.12.2 (Virtual-Access1) is up: new adjacency
Mar  1 04:54:08.418: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
Mar  1 04:54:09.634: %LINK-5-CHANGED: Interface Serial0/1, changed state to administratively down
Mar  1 04:54:10.634: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down

R1#sh ip route eigrp
     2.0.0.0/32 is subnetted, 1 subnets
D       2.2.2.2 [90/2713600] via 10.1.12.2, 00:00:56, Virtual-Access1
     3.0.0.0/32 is subnetted, 1 subnets
D       3.3.3.3 [90/5273600] via 10.1.12.2, 00:00:56, Virtual-Access1
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D       10.1.23.0/24 [90/5145600] via 10.1.12.2, 00:00:56, Virtual-Access1
D       10.1.23.3/32 [90/5145600] via 10.1.12.2, 00:00:56, Virtual-Access1

Advantages to using the backup interface command:
1) In a show ip interface brief, you can see that the backup interface is in standby state (in the EEM config perhaps in the description you can put something there but thats it)
2) Less configuration, less chance of error
3) No modifications to the configuration - the EEM config keeps changing the config to shut/no shut interfaces

Advantage to using EEM:
1) The only thing EEM offers over the built in functionality is potentially more flexibility - with EEM could email you to let you know the PVC is down, clear counters or other things - this may be handy if you're not sitting in front of your syslog server