Showing posts with label Frame-Relay. Show all posts
Showing posts with label Frame-Relay. Show all posts

Wednesday, 21 September 2011

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



Tuesday, 6 September 2011

MFR (Multilink Frame Relay FRF.16) Revisited


Some time ago I blogged briefly about MFR but only had it working with back-to-back routers because at the time, I couldn't work out how to get it to work through a Frame-Relay Switch.  After catching this statement on CCO, I finally understood that the FR Switch actually had to be MFR enabled as well.

Because of this, you can do some interesting things.

This topology will have 3 devices (R1, R2 and a FrameSwitch)

R1==MFR==FRSW--FR--R2

My crude diagram above is meant to indicate that R1 has two physical links to FRSW and is using MFR, while R2 has a single physical link to FRSW using regular frame-relay.

Why might you do this?  R1 could be a hub site serving multiple spokes like R2, and the Service Provider for whatever reason cant deliver big pipes to the hub site.  As opposed to having R1 and FRSW having just two links with the spokes distributed across the interfaces, besides any bandwidth gains, MFR also enables some resiliency (losing a single physical link can still keep all spokes connected at diminished capacity)


These are the configurations:

R1
hostname R1
!
interface MFR1
 no ip address
 frame-relay multilink bid R1-MFR1
 no frame-relay inverse-arp
!
interface MFR1.12 point-to-point
 ip address 10.1.12.1 255.255.255.0
 snmp trap link-status
 frame-relay interface-dlci 102
!
interface Serial0/0
 description FRSW S0/0
 no ip address
 encapsulation frame-relay MFR1
 no arp frame-relay
 frame-relay multilink lid R1-S0/0
!
interface Serial0/1
 description FRSW S0/1
 no ip address
 encapsulation frame-relay MFR1
 no arp frame-relay
 frame-relay multilink lid R1-S0/1


FRSW
hostname FRSW
frame-relay switching
!
interface MFR1
 no ip address
 frame-relay multilink bid FRSW-MFR1
 frame-relay intf-type dce
 frame-relay route 102 interface Serial1/0 201
!
interface Serial0/0
 description R1 S0/0
 no ip address
 encapsulation frame-relay MFR1
 clock rate 2000000
 no arp frame-relay
 frame-relay multilink lid FRSW-S0/0
!
interface Serial0/1
 description R1 S0/1
 no ip address
 encapsulation frame-relay MFR1
 clock rate 2000000
 no arp frame-relay
 frame-relay multilink lid FRSW-S0/1
!
interface Serial1/0
 description R2 S0/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 frame-relay intf-type dce
 frame-relay route 201 interface MFR1 102


R2
hostname R2
!
interface Serial0/0
 description FRSW S1/0
 no ip address
 encapsulation frame-relay
 no fair-queue
 no frame-relay inverse-arp
!
interface Serial0/0.21 point-to-point
 ip address 10.1.12.2 255.255.255.0
 frame-relay interface-dlci 201
!



Within the MFR configuration we have added some optional statements which identify the MFR bundle:

interface MFR
 frame-relay multilink bid MFRBundleIDString


And the links which make up the bundle:

interface Serial
 frame-relay multilink lid LinkIDString


This kind of thing can help with Layer 2 troubleshooting if you have a lot of peers.

R1#sh frame multi de | i BID|Peer|LID
 BID = R1-MFR1
 No. of bundle links = 2, Peer's bundle-id = FRSW-MFR1
  Serial0/1, HW state = up, link state = Up, LID = R1-S0/1
    Peer LID = FRSW-S0/1, RTT = 20 ms
  Serial0/0, HW state = up, link state = Up, LID = R1-S0/0
    Peer LID = FRSW-S0/0, RTT = 24 ms

FRSW#sh frame multi de | i BID|Peer|LID
 BID = FRSW-MFR1
 No. of bundle links = 2, Peer's bundle-id = R1-MFR1
  Serial0/1, HW state = up, link state = Up, LID = FRSW-S0/1
    Peer LID = R1-S0/1, RTT = 0 ms
  Serial0/0, HW state = up, link state = Up, LID = FRSW-S0/0
    Peer LID = R1-S0/0, RTT = 0 ms


So from above, we can see that  that the bundle is up with both links and we appear to be connected to the right peer interfaces.


So lets see the PVC status on the Frame Switch:

FRSW#sh frame pvc

PVC Statistics for interface Serial1/0 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

  input pkts 33            output pkts 29           in bytes 7428
  out bytes 4708           dropped pkts 12          in pkts dropped 12
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  switched pkts 24
  Detailed packet drop counters:
  no out intf 0            out intf down 0          no out PVC 0
  in PVC down 0            out PVC down 12          pkt too big 0
  shaping Q full 0         pkt above DE 0           policing drop 0
  pvc create time 00:10:17, last time pvc status changed 00:06:07

PVC Statistics for interface MFR1 (Frame Relay DCE)

              Active     Inactive      Deleted       Static
  Local          0            0            0            0
  Switched       1            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = MFR1

  input pkts 30            output pkts 24           in bytes 5029
  out bytes 4494           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  switched pkts 30
  Detailed packet drop counters:
  no out intf 0            out intf down 0          no out PVC 0
  in PVC down 0            out PVC down 0           pkt too big 0
  shaping Q full 0         pkt above DE 0           policing drop 0
  pvc create time 00:06:14, last time pvc status changed 00:05:54

FRSW#sh frame route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial1/0       201             MFR1            102             active
MFR1            102             Serial1/0       201             active

Looks good here, lets see what R1 and R2 have to say

R1#sh frame pvc

PVC Statistics for interface MFR1 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = MFR1.12

  input pkts 12            output pkts 19           in bytes 2802
  out bytes 3929           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 9         out bcast bytes 2889
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:08:34, last time pvc status changed 00:04:20
R1#sh frame map
MFR1.12 (up): point-to-point dlci, dlci 102(0x66,0x1860), broadcast
          status defined, active

R2#sh frame pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          1            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.21

  input pkts 18            output pkts 22           in bytes 3608
  out bytes 6062           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 17        out bcast bytes 5542
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:09:40, last time pvc status changed 00:05:30
R2#sh frame map
Serial0/0.21 (up): point-to-point dlci, dlci 201(0xC9,0x3090), broadcast
          status defined, active

And lets verify layer 3 connectivity:

R2#ping 10.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/44 ms


There are more things you can do with MFR which include the specifying the method of using the bundles (variable bandwidth class support). By default, IOS will use bandwidth class a (the MFR will stay active with downed link members as long as a single link is up),  other options include class b (all links must be active to keep the MFR interface up) or class c (a minimum threshold of links to keep the MFR interface up)

interface MFR
 frame-relay multilink bandwidth-class BandwidthClass LinkThresholdForClassC


Load Balancing:
When the MFR interface is not using FIFO queuing, the router will simly pick the interface with the empty or shortest queue to send traffic to.  If FIFO is being used then there is a default output-threshold of 300 bytes for each link, once this is exceeded, the next interface is selected.  It is possible to modify this value to a different level (this is not FRF.12 frame-relay fragmentation)

interface MFR
 frame-relay multilink output-threshold Threshold