Jul
09

“Why doesn’t this PING work!?!”

Here is a simple 3 router configuration, well at least it is simple on 2 of the 3 routers. R1 and R3 are configured quite traditionally, but R2 is a bit more involved.
Here is the diagram.

ZBF Transparent VRF R2

Here are the details.

R2 is using a VRF which includes both LAN interfaces. R2 is also acting as a Zone Based Firewall in transparent mode, allowing all ICMP traffic in both directions, as well as SSH from the inside to the outside networks. R2 has a bridged virtual interface in the 10.123.0.0/24 network. All are running OSPF, but pings issued from R2 to the loopbacks of R1 and R3 are failing.

Can you identify why?
Here is the relevant output:

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   FULL/DR         00:00:39    10.123.0.3      FastEthernet0/0
10.123.0.2        1   FULL/BDR        00:00:32    10.123.0.2      FastEthernet0/0
R1#show ip route ospf
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/2] via 10.123.0.3, 00:01:33, FastEthernet0/0

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/172 ms
R1#ssh -l admin 3.3.3.3
Password: <password>

R3#show ssh
Connection Version Mode Encryption  Hmac         State                 Username
0          1.99     IN   aes128-cbc  hmac-sha1    Session started       admin
0          1.99     OUT  aes128-cbc  hmac-sha1    Session started       admin
%No SSHv1 server connections running.
R3#exit

[Connection to 3.3.3.3 closed by foreign host]
R1#

Now for R2:

R2#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DROTHER    00:00:37    10.123.0.1      BVI1
3.3.3.3           1   FULL/DR         00:00:35    10.123.0.3      BVI1

R2#show ip route ospf

R2#show policy-map type inspect zone-pair
 Zone-pair: zp-in-to-out

  Service-policy inspect : p-in-to-out

    Class-map: c-in-to-out (match-any)
      Match: protocol icmp
        4 packets, 320 bytes
        30 second rate 0 bps
      Match: protocol ssh
        3 packets, 72 bytes
        30 second rate 0 bps
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [4:390]
        icmp packets: [0:50]

        Session creations since subsystem startup or last reset 8
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [2:1:1]
        Last session created 00:02:23
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 3
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any
      Drop (default action)
        0 packets, 0 bytes
 Zone-pair: zp-out-to-in

  Service-policy inspect : p-out-to-in

    Class-map: c-out-to-in (match-all)
      Match: protocol icmp
      Inspect
        Packet inspection statistics [process switch:fast switch]
        icmp packets: [0:20]

        Session creations since subsystem startup or last reset 2
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [1:1:0]
        Last session created 00:25:24
        Last statistic reset never
        Last session creation rate 0
        Maxever session creation rate 1
        Last half-open session total 0

    Class-map: class-default (match-any)
      Match: any
      Drop (default action)
        4 packets, 96 bytes

R2#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2# show run
version 12.4
hostname R2
!
ip vrf myvrf
!
class-map type inspect match-any c-in-to-out
 match protocol icmp
 match protocol ssh
class-map type inspect match-all c-out-to-in
 match protocol icmp
!
policy-map type inspect p-in-to-out
 class type inspect c-in-to-out
  inspect
 class class-default
policy-map type inspect p-out-to-in
 class type inspect c-out-to-in
  inspect
 class class-default
!
zone security inside
zone security outside
zone-pair security zp-in-to-out source inside destination outside
 service-policy type inspect p-in-to-out
zone-pair security zp-out-to-in source outside destination inside
 service-policy type inspect p-out-to-in
bridge irb
!
interface FastEthernet0/0
 ip vrf forwarding myvrf
 no ip address
 zone-member security inside
 bridge-group 1
!
interface FastEthernet0/1
 ip vrf forwarding myvrf
 no ip address
 zone-member security outside
 bridge-group 1
!
interface BVI1
 ip vrf forwarding myvrf
 ip address 10.123.0.2 255.255.255.0
!
router ospf 1 vrf myvrf
 router-id 10.123.0.2
 network 0.0.0.0 255.255.255.255 area 0
!
bridge 1 protocol ieee
bridge 1 route ip
end

Here is R3:

R3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/DROTHER    00:00:32    10.123.0.1      FastEthernet0/1
10.123.0.2        1   FULL/BDR        00:00:31    10.123.0.2      FastEthernet0/1

R3#show ip route ospf
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.123.0.1, 00:29:36, FastEthernet0/1

R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/117/176 ms
R3#

Similar configuration scenarios are included in both our RS and SC workbooks at INE.

Take a moment, and post your ideas on why the PING from R2 is failing, and thanks for taking the time to assist!

Best wishes.


You can leave a response, or trackback from your own site.

14 Responses to “Transparent ZBF, IRB, and VRF troubleshooting.”

 
  1. Michael Kartvelishvili says:

    As I don’t have hands-on lab accessible at the moment my purely theoretical idea is:
    Shouldn’t BVI interface be assigned to some zone to be able to originate traffic? I suppose this is the reason of packets originated by the router (actually BVI interface) to be dropped by ZBF logic.

  2. M. says:

    maybe you should try vrf-aware PING from R2 ?

  3. minty says:

    You didnt ping using ping vrf myvrf 3.3.3.3

    Ian

  4. ob says:

    Agreed:

    R2# ping vrf myvrf 3.3.3.3

  5. DavidP says:

    Because vrf has independent routing table
    ping vrf myvrf 3.3.3.3 should work

  6. Anantha Subramanian Natarajan says:

    Hi,

    Is the capability vrf-lite to make multi-vrf support command missing under the ospf vrf procees on R2 ?

    Thanks

    Regards
    Anantha Subramanian Natarajan

  7. vijay says:

    ping is initiated from global vrf not from myvrf vrf, thats why… i guess also the sh ip ospf command on R2 might yeild some output if userd with vrf myvrf option.

  8. Markku says:

    You sourced the ping from the global routing table but all the related interfaces are in VRF myvrf.

  9. Nikita says:

    You also need to define the rule from zone (inside|outside) to zone self

  10. Tom says:

    I think pings from R2 should be issued with “vrf myvrf” keywords as
    routes have to be checked with “show ip route vrf myvrf ospf” command, because R2 is running ospf for vrf and not for global table.

  11. cisco'n cie says:

    Hi, a ‘ping vrf myvrf 3.3.3.3′ might be more adequate

  12. Oleg Bukhalov says:

    Hello!

    Interface BVI1 is included in VRF “myvrf” as well as ospf process, so global routing table don’t have necessary routes to R1,R3 networks. That lead us to specify VRF when ping something from R2:
    ping vrf myvrf 3.3.3.3 – should work fine

    Other logical variant is using global routing table for BVI interface and router ospf process on R2:
    !
    interface BVI1
    ip address 10.123.0.2 255.255.255.0
    !
    router ospf 1
    router-id 10.123.0.2
    network 0.0.0.0 255.255.255.255 area 0
    !
    In that case ping 3.3.3.3 should work fine also.

  13. JL says:

    Hi

    Just want to check how come we are not issuing “show ip route vrf myvrf ” , “ping vrf myvrf 3.3.3.3″ under R2.
    Am i missing some stuffs here , please let me know

    Thanks

  14. Thanks for all the great ideas and comments. From a ZBF perspective, there was no policy involving the “self” zone, so that was not a problem. The issue, as has been mentioned, was the fact that we didn’t use the routing table from the correct VRF.

    Thanks again to all!

 

Leave a Reply

Categories

CCIE Bloggers