Frame Relay Subinterfaces Do Not Inherit Inverse-ARP Configuration

I was very surprised to find out that Frame Relay subinterfaces do NOT inherit the Frame Relay inverse-ARP settings from the physical interface.   For instance, in the configuration below, Serial0/0.1 will inherit the Frame Relay encapsulation setting, but it will NOT inherit the “no frame-relay inverse-arp” setting:

int s0/0
 encap frame
 no frame inv
int s0/0.1 multi
 ip add 10.0.0.1 255.255.255.0
 frame interface-dlci 102

We can prove this in a lab:

r1#sh run | sec Serial0/0
interface Serial0/0
 description ->frame inverse-arp disabled at physical int
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
!
interface Serial0/0.102 multipoint
 description ->frame inverse-arp disabled at subint
 ip address 10.0.0.12 255.0.0.0
 frame-relay map ip 10.0.0.2 102 broadcast
 no frame-relay inverse-arp
!
interface Serial0/0.103 multipoint
 description ->frame inverse-arp NOT disabled at subint(assumes inheritance from physical int)
 ip address 10.0.0.13 255.0.0.0
 frame-relay interface-dlci 103

When we look at the Frame maps, we see that DLCI 103 is mapped via inverse-ARP(dynamic):
r1#sh frame map
Serial0/0.102 (up): ip 10.0.0.2 dlci 102(0×66,0×1860), static, broadcast,
              CISCO, status defined, active
Serial0/0.103 (up): ip 10.0.0.3 dlci 103(0×67,0×1870), dynamic,  broadcast,, status defined, active

Let’s shut down int s0/0(physical interface) and then debug:

r1#sh debug

Frame Relay:
  Frame Relay events debugging is on
  Frame Relay packet debugging is on

Now let’s bring s0/0 back up and view the debugging output:

*Mar  1 00:09:02: %SYS-5-CONFIG_I: Configured from console by console
*Mar  1 00:09:03: %LINK-3-UPDOWN: Interface Serial0/0, changed state to down
*Mar  1 00:09:08: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar  1 00:09:09: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up
*Mar  1 00:09:18: Serial0/0.103: preparing IP inarp on 103
*Mar  1 00:09:18: Serial0/0.103(o): dlci 103(0×1871), pkt encaps 0×0300 0×8000 0×0000 0×806 (ARP), datagramsize 34
*Mar  1 00:09:18: FR: Sending INARP Request on interface Serial0/0.103 dlci 103 for link 7(IP) <-note
*Mar  1 00:09:18: broadcast dequeue
*Mar  1 00:09:18: Serial0/0.103(o):Pkt sent on dlci 103(0×1871), pkt encaps 0×300  0×8000 0×0    0×806 (ARP), datagramsize 34
*Mar  1 00:09:25: Serial0/0(i): dlci 103(0×1871), pkt encaps 0×0300 0×8000 0×0000 0×806 (ARP), datagramsize 34
*Mar  1 00:09:25: Serial0/0.103: FR ARP input
*Mar  1 00:09:25: datagramstart = 0x79E78AE, datagramsize = 34
*Mar  1 00:09:25: FR encap = 0×18710300
*Mar  1 00:09:25: 80 00 00 00 08 06 00 0F 08 00 02 04 00 08 00 00
*Mar  1 00:09:25: 0A 00 00 03 48 D1 00 00 00 00 01 02 00 00
*Mar  1 00:09:25:
*Mar  1 00:09:25: Serial0/0.103: frame relay INARP received
*Mar  1 00:09:25: Serial0/0.103: inarp received on 103
*Mar  1 00:09:25: FR: Sending INARP Reply on interface Serial0/0.103 dlci 103 for link 7(IP)

As we can see from this example, Frame Relay inverse-ARP is definitely active on the s0/0.103 subinterface even though we disabled it at the physical interface (s0/0) level.  So unlike the encapsulation configuration, Frame Relay inverse-ARP settings are NOT inherited by the subinterface(s).

So…why do we care?  In the real world, we really do not care.  By default all DLCIs are assinged to the physical interface, so the only DLCIs that could get mapped via inverse-ARP on the subinterfaces are the DLCIs that you have assigned to the subinterface yourself (with “frame-relay interface-dlci [DLCI]“).  In other words, the frame switch can advertise a ton of DLCIs to you (use “show frame pvc” to view them), but the subinterface is only going to look at the DLCIs that you have explicitly assign to it.  If you turn off Frame Relay inverse-ARP at the physical interface, then you only need to worry about Frame Relay inverse-ARP mapping the DLCIs that you explicitly asssign to the subinterface(s).

Furthermore, it is nescessary to have an IP address configured on the interface for Frame Relay inverse-arp to work.  If there is no IP address assigned to the physical interface then disabling Frame Relay inverse-ARP at the physical level while running subinterfaces is not nescessary.

BUT…we’re not concerned about good design or real world issues in the CCIE lab.  We need to watch out for tasks like this:

Configure s0/0.103 as a multipoint Frame Relay subinterface.  Ensure that layer 2 to layer 3 dynamic mapping is not possible on this subinterface.

We need to know that simply disabling Frame Relay inverse-ARP on the physical interface and using a static Frame Relay mapping on the subinterface will not meet the requirements of this task.

About these ads