ip pim autorp listener should be named ip pim autorp forwarder

There is a fair amount of confusion about what exactly ip pim autorp listener actually does, or on which router to configure it. This probably stems from the fact that it has the word ‘listener’ in the command when it really doesn’t configure the router to listen for anything. Let’s take the following diagram into consideration for this post:

I’ve configured OSPF on all interfaces, including loopbacks, and configured ip pim sparse-mode on all interfaces

Auto-RP uses the multicast addresses of 224.0.1.39 and 224.0.1.40
224.0.1.39 is the AUTO-RP-ANNOUNCE group and is used by the mapping agent (send-rp-discovery) router to listen for routers sending candidate announcements. i.e. Candidate RPs send multicast traffic TO 224.0.1.39 and the mapping agent joins this group to RECEIVE that traffic
224.0.1.40 is the AUTO-RP-DISCOVERY group and is sent from the mapping agent out so that other multicast routers can get information on which address is the rendezvous point. i.e. The mapping agent sends traffic to this group, and all multicast routers join this group so that they can receive this traffic

The problem is that routers are running sparse-mode. How can they join a group if they don’t know the location of the RP? A classic chicken and egg scenario.

Let’s start off with a basic config. We’ll check the mroute table along the way as well as check what auto-rp packets are getting sent by which routers via wireshark. On R1 I’ve enabled ip pim on it’s interfaces and enabled ip multicast-routing. Nothing else. Let’s take a look at the mroute table:

R1#sh ip mroute | beg \(
(*, 224.0.1.40), 00:03:25/00:02:25, RP 0.0.0.0, flags: DPL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

This router is already listening to the 224.0.1.40 group. The group that contains messages from the mapping agent to let it know where the RP is. So the router is already ‘listening’ The flags are DPL and mean Dense/Pruned/Local. Checking wireshark, there is no traffic destined to 224.0.1.39 or .40 as expected.

On R1, let’s configure the router to it considers itself a candidate RP:

R1(config)#ip pim send-rp-announce lo0 scope 10 interval 5

I’m also going to debug any auto-rp messages via the other routers:

R2#debug ip pim auto-rp
PIM Auto-RP debugging is on

Wireshark shows me that R1 is sending an auto-rp packet every 5 seconds. Source is 1.1.1.1 and destination is 224.0.1.39 which is expected. 224.0.1.39 is the group that the mapping agent will join to receive these announcements.

So wireshark is showing that R2 receives these packets. Wireshark also shows that R2 does not forward these packets in a dense-mode fashion (I’m not going to paste an empty wireshark capture)

Now I’m going to enable ip pim autorp listener on R2. This will cause R2 to flood the two autorp groups in a dense mode fashion. This means R3 will receive those frames, but not forward them onto R4:

R2(config)#ip pim autorp listener

Straight away on gi2/0 of R2 I see the following packet getting sent:

This now means that R3 is receiving packets destined to 224.0.1.39, but R4 still isn’t. But let’s use this to our advantage. Let’s make R3 the mapping agent. This will cause it to consider R1 to be the RP and it will flood those frames out it’s directly connected interfaces.

R3(config)#ip pim send-rp-discovery lo0 scope 10 interval 5

R3 already received the packets destined to 224.0.1.39 via R2. This allows it to make an informed decision and maps R1 to be the RP for 224.0.0.0/4 – It then sends messages out to 224.0.1.40 which all routers are already listening for

My debug auto-rp shows the following on R1, R2, and R4:

*Jan 14 13:27:29.531: Auto-RP(0): Received RP-discovery packet of length 48, from 3.3.3.3, RP_cnt 1, ht 16
*Jan 14 13:27:29.531: Auto-RP(0): Update (224.0.0.0/4, RP:1.1.1.1), PIMv2 v1

Even R4 knows about the RP and can now join groups:

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

Group(s) 224.0.0.0/4
  RP 1.1.1.1 (?), v2v1
    Info source: 3.3.3.3 (?), elected via Auto-RP
         Uptime: 00:04:16, expires: 00:00:15

However R5 has no mappings whatsoever. This is because while R4 is receiving packets destined to 224.0.1.40, it’s not forwarding them. So let’s configure autorp listener on R4:

R4(config)#ip pim autorp listener

Straight away on R5:

*Jan 14 13:32:18.511: Auto-RP(0): Received RP-discovery packet of length 48, from 3.3.3.3, RP_cnt 1, ht 16
*Jan 14 13:32:18.511: Auto-RP(0): Added with (224.0.0.0/4, RP:1.1.1.1), PIMv2 v1

Wireshark confirms that autorp packets are now being sent out R4’s gi2/0 interface

So here I have five routers running auto-rp in sparse mode. I’ve only configured autorp listener on two routers – R2 and R4

Conclusions

  • Autorp listener doesn’t cause the router to listen for anything, rather it causes the router to dense flood groups 224.0.1.39 and 224.0.1.40 when it receives them
  • This means that routers at the end of the path, or certain routers running as the candidate RP or MA do not actually need to be configured with autorp listener
  • I mentioned certain routers, as if your topology has multiple candidate RPs or MAs then each would would need to ensure that dense flood packets from OTHER RPs or MAs are forwarded
  • Think of autorp listener as a autorp forwarder command as that’s essentially what the command does
  • Use BSR if you can. It’s an open protocol (unlike autorp, even though Junos DOES support autorp) and RPs and MAs are lean’t on a hop by hop basis through PIMv2

Saving and running TCL scripts from flash

Anyone who is studying for the CCIE knows a lot about TCL scripting. Most certainly a big timesaver.

Of course TCL scripts can also be used in the real world. You don’t want to have to type our your script all the time, so is there a better way?

Over at networking-forum.com I asked if someone could come up with a script that would check for a route in any given subnet and return a ‘No route found’ for any IP address not in my global route table. I forgot who came up with it for me (sorry) but here is an example. Let’s say I wanted to check what routes I had for the range 10.20.16.0/20 – Of course usually this would be for a public range, but work with me here. This is the script:

#set the starting IP address octets
set firstoctet 10
set secondoctet 20
set thirdoctet 16
set fourthoctet 0

#while we're less than 10.20.31.255
while { $thirdoctet <= 31 } {
      while { $fourthoctet <= 255 } {
            set ipaddr $firstoctet.$secondoctet.$thirdoctet.$fourthoctet
            set results [exec "show ip route $ipaddr"]
            
            if { [regexp "not in table" $results] } {
                  puts "No route found for $ipaddr"
            }
            
            incr fourthoctet
      }
      
      #if out of the inner loop, reset the fourth back to 0 and increment the second octet
      set fourthoctet 0
      incr thirdoctet
}

This script works wonders, but it's pretty big to have to even copy and paste in each time I want to run it.

What I've now done is save the above script into a simple text file and renamed it to 10_20_16_0.tcl - I then tftp'd is to the flash on my router

There are now a couple of ways to run this file. The first way is to manually run it when I need to. How? Like so:

Router#tclsh flash:/10.20.16.0.tcl
No route found for 10.20.16.40
No route found for 10.20.16.41

The source will simply load and execute the tcl script straight away. This is certainly handy for those scripts you only want to run now and then.

What if you want to run a script automatically? Why not use EEM :)

event manager applet TCL_RUN
 event none
 action 1.0 cli command "enable"
 action 1.1 cli command "tclsh flash:/10_20_16_0.tcl"

The beauty of using EEM is that it can track all kinds of things, and based on those events it can run tcl scripts for you.

To actually run the EEM script yourself you can do so like this:

event manager run TCL_RUN

Nice and easy :)

Native vlan subinterfaces

The subinterface is an invaluable tool in your belt. I pretty must use subinterfaces whenever I connect routers to each other via ethernet, even if initially they are only going to have a single point-to-point connection to each other.

Why? Well a subinterface allows you to stick a dot1q header on your frames. Just like running a trunk between 2 switches, it allows you to run multiple logical links between 2 routers. As noted above, even if you only have a single point-to-point connection between 2 routers I still run them. In the past I’ve had to change or add to a design. If I was running just the physical interfaces and needed to change it, I would require downtime and possibly even going to site to actually reconfigure the CPE device. If I used subinterfaces from the start I can just add another subinterface to the mix. There is ways to get around this though.

You can also mix regular and subiterfaces together on the same interface. You can also tag a subinterface as the native vlan. Let’s look at a couple of different examples and see what we see.

Let’s just start with a simple physical interface setup.
R1:

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0

R2:

interface FastEthernet0/0
 ip address 192.168.1.2 255.255.255.0
R1#ping 192.168.1.2

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

Let’s say now that for whatever reason we need to run another logical link between these 2 routers. Let’s also say that R2 happens to be on the other side of the country and we need to do this now. Well I did note above that there is a workaround for this as you can run both a physical and subinterface on the router at the same time. Let’s leave the above config in and add this:
R1:

interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.0.0.1 255.255.255.0
interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.0.0.2 255.255.255.0
R1#ping 10.0.0.2 repeat 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 28/28/28 ms
R1#ping 192.168.1.2 repeat 1

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

Both still work. Now you could log onto R2 via the 10.0.0.2 link and remove the 192.168.1.0/24 address if you wanted without worry. Wireshark shows traffic going over the physical interface has no dot1q tag, while the subinterface has a dot1q tag of 10:

Now let’s mix it up a bit. I can say that a subinterface is tagged with the native vlan. i.e. no vlan tag:
R1:

interface FastEthernet0/0.20
 encapsulation dot1Q 20 native
 ip address 20.20.20.1 255.255.255.0

R2:

interface FastEthernet0/0
 ip address 20.20.20.2 255.255.255.0 secondary
 ip address 192.168.1.2 255.255.255.0
R1#ping 20.20.20.2 repeat 1

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

On R1 I created a subinterface with the native vlan. On R2 I added a secondary IP address. Traffic for the 20.20.20.0/24 range goes over the wire without a dot1q tag. Why not just use a secondary address? Well you can stick a subinterface into a vrf, while you can’t do that with a secondary address. Your IGP behavior also changes somewhat.

I don’t quite like doing the above though. I don’t like have layer2 seperation between networks that should be separated. However it proves the point that a native subinterface’s traffic outbound is exactly the same format as a physical interface. Just a standard ethernet layer2 header with no dot1q tag.

There is another advantage to using a native subinterface. If I want to shut down the link for 20.20.20.0/24, on R1 I can shut down the subinterface. All other subinterfaces stay up. If I do this on R2 however, all subinterfaces go down:
R1:

R1(config)#int fa0/0.20
R1(config-subif)#shut
R1(config-subif)#end
R1#
*Mar  1 00:33:31.023: %SYS-5-CONFIG_I: Configured from console by console
R1#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.1.1     YES manual up                    up
FastEthernet0/0.10         10.0.0.1        YES manual up                    up
FastEthernet0/0.20         20.20.20.1      YES manual administratively down down
R2(config)#int fa0/0
R2(config-if)#shut
R2(config-if)#end
R2#
*Mar  1 00:34:51.955: %SYS-5-CONFIG_I: Configured from console by console
R2#sh ip int
*Mar  1 00:34:53.347: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar  1 00:34:54.347: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R2#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            192.168.1.2     YES manual administratively down down
FastEthernet0/0.10         10.0.0.2        YES manual administratively down down

So while the native subinterface and physical interface send traffic the same, I can shut a native subinterface without affecting any other subinterface, while the shutting down of a physical interface shuts down all the subinterfaces attached to it

Now let’s get deeper…

R1:

interface FastEthernet0/0.10
 encapsulation dot1Q 10 native
 ip address 10.10.10.1 255.255.255.0

R2:

interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.10.10.2 255.255.255.0

Here I have R1 configured with a native subinterface, while R2 is configured with a dot1q header of 10. You would expect there would be no communication between them, but you would be incorrect. I’m going to turn on debug ip packet on both routers for this to see who sees what
R1:

R1#ping 10.10.10.2 repeat 1

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

*Mar  1 00:08:07.763: IP: tableid=0, s=10.10.10.1 (local), d=10.10.10.2 (FastEthernet0/0.10), routed via FIB
*Mar  1 00:08:07.763: IP: s=10.10.10.1 (local), d=10.10.10.2 (FastEthernet0/0.10), len 100, sending.
Success rate is 0 percent (0/1)


So the ping failed, but look more closely. R1 was able to encapsulate the packet, which means it has a MAC address. Let’s look at the ARP table:

R1#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.1              -   c200.3e78.0000  ARPA   FastEthernet0/0.10
Internet  10.10.10.2              2   c201.3e78.0000  ARPA   FastEthernet0/0.10

Let’s try the other way around now.
R2:

R2#ping 10.10.10.1 repeat 1

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

*Mar  1 00:11:20.807: IP: tableid=0, s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), routed via RIB
*Mar  1 00:11:20.811: IP: s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), len 100, sending
*Mar  1 00:11:20.815: IP: s=10.10.10.2 (local), d=10.10.10.1 (FastEthernet0/0.10), len 100, encapsulation failed.
Success rate is 0 percent (0/1)


Let’s have a look at the ARP cache:

R2#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.10.1              0   Incomplete      ARPA
Internet  10.10.10.2              -   c201.3e78.0000  ARPA   FastEthernet0/0.10

Somehow R1 learned R2’s MAC address so communication was there, but it seems it’s only one way. Let’s clear the ARP cache on both and debug ARP to see what happens.

The first thing you notice when you clear the ARP cache is that the local router will send a gratuitous ARP out to let everyone else know about it. Let’s see what we see on R1 when we clear R2’s cache:
R2:

R2#clear arp
R2#
*Mar  1 00:18:45.135: ARP: flushing ARP entries for all interfaces
*Mar  1 00:18:45.143: IP ARP: sent rep src 10.10.10.2 c201.3e78.0000,
                 dst 10.10.10.2 ffff.ffff.ffff FastEthernet0/0.10

R1:

R1#
*Mar  1 00:18:31.231: IP ARP: rcvd rep src 10.10.10.2 c201.3e78.0000, dst 10.10.10.2 FastEthernet0/0.10

R1 receives this gratuitous ARP and installs the MAC address into it’s ARP cache. Wireshark shows that R2 is sending this gratuitous ARP with a dot1q tag:

What about the other way?
R1:

R1#clear arp
R1#
*Mar  1 00:20:53.847: ARP: flushing ARP entries for all interfaces
*Mar  1 00:20:53.855: IP ARP: sent rep src 10.10.10.1 c200.3e78.0000,
                 dst 10.10.10.1 ffff.ffff.ffff FastEthernet0/0.10

R2:

R2#
*Mar  1 00:21:07.831: IP ARP rep filtered src 10.10.10.1 c200.3e78.0000, dst 10.10.10.1 ffff.ffff.ffff wrong cable, interface FastEthernet0/0

R2 complains that this ARP is coming in on ‘the wrong cable’ while wireshark shows the gratuitous ARP being sent without a dot1q header as expected.

What can we get from this? Well if you have a native subinterface, it will accept both untagged AND tagged frames in the vlan, vlan 10 in my example above. However it will only SEND untagged traffic. Good to know. It can also explain why you sometimes see an ARP entry on one side, while not on the other.

SPAN, RSPAN, Layer 2 control packets and VLANS

I know the title is quite a mouthful, but I did want to cover all the above in this post. Daniel asked me to check a few things as I have ready access to real switches.

You learn in your studies that layer 2 control packets are ‘special’ – Special in the way that traffic going over the trunk between 2 switches does not follow the standard practice. Let’s use wireshark to see exactly what is going on in a bunch of scenarios. It’ll also give me the opportunity to do a bit of testing with SPAN and RSPAN.

Let’s use the basic topology:

Let’s first set up a span session on the 3750. I will monitor port gi1/0/9 in both directions and send that traffic to gi1/0/24 to be picked up by the laptop.

monitor session 1 source interface Gi1/0/9
monitor session 1 destination interface Gi1/0/24

The first thing I noticed when I plug in my laptop however is that Windows of course is very noisy. Already my capture is filling up with stuff that Windows is sending out. And so I’ve downloaded an NST ISO which I’ll listen with on the laptop.

So now that I’ve booted up into NST and got Wireshark running, I hardly see anything at all happening between the 2 switches. Where is all the layer 2 control traffic? Well the problem is that control traffic is not automatically replicated to a SPAN port. You need to enable encapsulation replication in order for it to work. Let’s do so:

C3750#conf t
C3750(config)#monitor session 1 destination interface gi1/0/24 encapsulation replicate

Let’s verify:

C3750#sh monitor session 1
Session 1
---------
Type                   : Local Session
Source Ports           :
    Both               : Gi1/0/9
Destination Ports      : Gi1/0/24
    Encapsulation      : Replicate
          Ingress      : Disabled

I can now see lot’s of control traffic in my Wireshark capture.

Both switches are already connected to each other. By default they’ll create a trunk link and vlan 1 will be the native vlan. I’ll then configure the switches to tag the native vlan and see what happens.

Let’s ensure the native vlan is not currently tagged:

C3750#sh vlan dot1q tag native
dot1q native vlan tagging is disabled

So what does my CDP/STP/DTP control packets look like in Wireshark? Note that I’m running the default mode of STP on the switch for now
I do see something odd. I am seeing an STP packet that has a dot1q tag of 1, 10 and an untagged packet. 10 I can understand because I have created vlan 10 and it has a separate STP instance. But why would the main one be tagged with vlan 1 if vlan 1 is the native vlan?
dot1q vlan 1

dot1q vlan 10

no dot1q tag

What about DTP and CDP?
DTP

CDP

Both CDP and DTP are currently sent with no vlan tag at all. CDP does carry information about the native vlan in it’s packet which is why CDP does complain when these don’t match on either end. But the important thing is that both are untagged.

Let’s now tag the native vlan and see what happens.

C3750(config)#vlan dot1q tag native
C3750#sh vlan dot1q tag native
dot1q native vlan tagging is enabled

Let’s bring up the interfaces again and see what we see.
DTP

CDP

Interesting. DTP has not tag, but CDP is using a tag of 1.

What about STP?



I’m seeing the same as what I saw above. I see a tagged vlan 1 STP frame, a tagged vlan 10 STP frame, and finally an untagged STP frame

What happens if I change the native vlan to 10? Well no need to paste output because it’s exactly the previous example. i.e. vlan 10 is now the native vlan and tagged, but CDP is still using a tag value of 1. STP and DTP remain unchanged.

Now let’s try something else. Let’s keep vlan 10 as the tagged native, but let’s remove vlan 1 from the trunk:

interface GigabitEthernet1/0/9
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 10
 switchport trunk allowed vlan 2-4094

DTP is unchanged. i.e. it’s still sending untagged traffic. CDP however is sending tagged traffic. In vlan 1!

As a quick test I created int vlan 1 on both switches in the same subnet and tried to ping accross. I could not. Therefore it looks like Cisco will use vlan 1 tagged to send certain control data, even if vlan 1 is pruned, but no user data will be allowed on that vlan.

For STP I still have the same 3 outputs. A tagged vlan 1 STP frame, A tagged vlan 10 STP frame, and an untagged STP frame.

One last thing I wanted to test now was RSPAN config. I’ve always been a little confused as to the correct config on a switch that is the RSPAN end-point, and is also sending traffic to be monitored. i.e. Let’s say that the 3550 above is monitoring traffic on vlan 2 with a destination of remote span vlan 500. The 3750 is the rspan endpoint who monitoring rspan vlan 500 and sends it out to a local port on the switch. What happens if the 3750 is also monitoring vlan 2 on it’s own ports and sending out. Do we configure the destination to vlan 500 or straight to a local port?

Let’s configure it like so:

C3750#sh monitor session all
Session 1
---------
Type                   : Remote Source Session
Source Ports           :
    Both               : Gi1/0/9
Dest RSPAN VLAN        : 500


Session 2
---------
Type                   : Remote Destination Session
Source RSPAN VLAN      : 500
Destination Ports      : Gi1/0/24
    Encapsulation      : Replicate
          Ingress      : Disabled

I’ve tested sending it to RSPAN vlan 500 and I don’t see any traffic at all. As soon as I change it to send traffic directly to the port it works.

EDIT (05/06/12) – I’ve uploaded my captures to Cloudshark so you can take them apart to do your own research
Untagged native vlan 1
Tagged native vlan 1
Tagged native vlan 10
Tagged native vlan 10 with vlan 1 removed from trunk

Frame-relay switching/bridging/back-to-back

Routing over frame-relay is pretty straightforward. Once you work out the differences between point to point and point to multipoint you’re pretty much set.

But what happens when you get to the lab and they require you to switch over frame-relay? Or have a point-to-point link through another router, but not running frame-relay switching? Or what about back to back frame-relay where no frame-relay switch is involved?

All of the above are actually not difficult, as long as you configure them each as least once.
Consider the following simply topology:

The task we’ve been given is for R1 to be a frame-relay switch. R2 and R3 need to communicate over a point to point link. The DLCI for R2 will be 203 and the DLCI for R3 will be 302. Let’s first configure R2 and R3 as a basic point-to-point:
R2:

R2#sh run | sec Serial0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.203 point-to-point
 ip address 10.23.23.2 255.255.255.0
 frame-relay interface-dlci 203

R3:

R3#sh run | sec Serial0/0
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no frame-relay inverse-arp
interface Serial0/0.302 point-to-point
 ip address 10.23.23.3 255.255.255.0
 frame-relay interface-dlci 302

At this point, let’s have a look at the PVCs from R2’s perspective:

R2#show frame pvc | include DLCI
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = DELETED, INTERFACE = Serial0/0.203

Remember DELETED means that the frame-switch has no idea about the DLCI that R2 is talking about. So let’s now configure R1 as a frame-relay switch. It’s a 3 step process. Tell the device it’s going to be a frame-relay switch. Tell the router which interfaces are going to be DCEs. And finally tell the router which DLCIs are going to be switched from one interface to another.
R1:

frame-relay switching
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 128000
 frame-relay intf-type dce
 frame-relay route 203 interface Serial0/1 302
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 clock rate 128000
 frame-relay intf-type dce
 frame-relay route 302 interface Serial0/0 203

Let’s take a look at R2 again:
R2:

R2#show frame pvc | include DLCI
DLCI = 203, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.203
R2#ping 10.23.23.3 repeat 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.23.23.3, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/11/132 ms

To quickly see what routes are configured on the frame-switch, just do this:

R1#show frame-relay route
Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial0/0       203             Serial0/1       302             active
Serial0/1       302             Serial0/0       203             active

You can of course have multiple map statements referencing different DLCIs under each DCE interface like you would expect!

Now let’s change the topology:

This time they want to run OSPF between R2 and R3. They want the OSPF network type to be broadcast. These broadcasts need to go through R1, but R1 is NOT a frame-relay switch this time. To make sure we don’t somehow bounce things of R1’s IP address, we’ll configure a /31 between R2 and R3. Essentially we’ll be bridging through R1’s frame-relay interfaces.

Let’s create the bridge-group on R2 first. R3’s will almost match, just the DLCI and IP will change:
R2:

bridge irb
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 frame-relay map bridge 201 broadcast
 bridge-group 1
!
interface BVI1
 ip address 10.23.23.2 255.255.255.254
 ip ospf network broadcast
 ip ospf 1 area 0
!
bridge 1 protocol ieee
bridge 1 route ip

The important part to notice about this is the frame-relay map bridge command. As noted above, the config on R3 is pretty identical. This is R1’s config:
R1:

bridge irb
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 frame-relay map bridge 102 broadcast
 frame-relay interface-dlci 102
 bridge-group 1
!
interface Serial0/1
 no ip address
 encapsulation frame-relay
 frame-relay map bridge 103 broadcast
 frame-relay interface-dlci 103
 bridge-group 1
!
bridge 1 protocol ieee

Does it all work?

R2#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.23.23.3        1   FULL/DR         00:00:32    10.23.23.3      BVI1
R2#ping 10.23.23.3

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

Let’s move onto the last topic, back to back frame-relay. You have the following topology:

The tasks states that you need to run frame-relay, but there is no frame-relay switch involved. We don’t even get DLCI numbers on the diagram.
For back-to-back frame-relay to work we essentially turn off our keepalives. The keepalives will be looking for the LMI messages which simply don’t exist. We then hard code the DLCI number on both sides. These DLCI numbers need to MATCH however.
Let’s configure it up:
R1:

interface Serial0/0
 ip address 10.23.23.3 255.255.255.0
 encapsulation frame-relay
 no keepalive
 clock rate 2000000
 frame-relay map ip 10.23.23.2 100
 no frame-relay inverse-arp

R1#ping 10.23.23.2

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

R1#show frame pvc | include DLCI
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = STATIC, INTERFACE = Serial0/0

You can see the PVC is static, and communication is working just fine.