Ping Issues – Why Can’t Ping Address Across Routed Link

In simple case:

• You need only one VR. Multiple VR are needed when you want separate routing tables for different groups of interfaces (i.e. for different clients).
• If you can select destination for packet using only destination IP (and as I understand - you can), then you not need PBF. PBF is needed if you want to send packets with same destination IP to different next hops based on source IP/port and/or destination port.

And with your specific question:

• Based on Palo Knowledge Base you can have asymmetric routing between zones if you use:
  set deviceconfig setting session tcp-reject-non-syn no
set deviceconfig setting tcp asymmetric-path bypass
  
• But maybe you should rethink merging ZONE1, ZONE2 and ZONE3 into one zone because another article suggest that these commands effectively disable higher level scanning for asymmetric traffic. You probably can bypass this with adding artificial VR and scanning traffic between VR (where it will be symmetric), but this in effect will be same as merging zones - just more complicated.

There are a few ways to accomplish a back-to-back frame-relay connection.

A quick search returns the following options:

• Back-to-Back Frame-Relay using sub-interfaces
• Back-to-Back Frame-Relay Hybrid Switching

Your configuration is closer to hybrid switching, however, you're missing a few key elements.

Frame-Relay

Either R1 or R2 will need to have frame-relay switching enabled to act as the frame-relay switch.

R1(config)#frame-relay switching

The newly designated frame switch's Serial0/0 interface needs to be changed to the frame-relay interface type dce in order to provide LMI.

R1(config)#int s0/0
R1(config-if)#frame-relay intf-type dce

Finally you don't need to include the no keepavlive syntax when performing hybrid switching.

EIGRP

Your matching(required) static frame-relay map statements may include the broadcast statement in order for EIGRP to establish a neighbor adjacency.

R1(config)#int s0/0
R1(config-if)# frame-relay map ip 131.1.12.2 100 broadcast

R2(config)#int s0/0
R2(config-if)# frame-relay map ip 131.1.12.1 100 broadcast

IP: s=131.1.12.1 (local), d=224.0.0.10 (Serial0/0), len 60, sending broad/multicast
Serial0/0(o): dlci 100(0x1841), pkt type 0x800(IP), datagramsize 64
Serial0/0(o):Pkt sent on dlci 100(0x1841), pkt type 0x800(IP), datagramsize 64

Without the broadcast statement, EIGRP messages sent to the multicast address 224.0.0.10 will fail to be encapsulated.

IP: s=131.1.12.1 (local), d=224.0.0.10 (Serial0/0), len 60, sending broad/multicast
Serial0/0: broadcast search
Serial0/0:encaps failed on broadcast for link 7(IP)
IP: s=131.1.12.1 (local), d=224.0.0.10 (Serial0/0), len 60, encapsulation failed

Unicast EIGRP

Or, instead of using the broadcast keyword with your static frame-relay map statements to avoid encapsulation failures, you can specify EIGRP unicast neighbors under EIGRP process 100 and your adjacency should form.

R1(config-if)#router eigrp 100
R1(config-router)#neighbor 131.1.12.2 s0/0
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.2 (Serial0/0) is down: Static peer configured
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.2 (Serial0/0) is up: new adjacency

R2(config-if)#router eigrp 100
R2(config-router)#neighbor 131.1.12.1 s0/0
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.1 (Serial0/0) is down: Static peer configured
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 131.1.12.1 (Serial0/0) is up: new adjacency