Workbook 1 OSPF Task 38

image

 

 

Hello Community,

In this OSPF task, R5 filters 150.1.1.1 and 150.1.2.2 inbound, it receives a default route from R4, and advertises a summary address of 150.1.0.0/22 to Area 3. Area 3 devices are also filtering 150.1.1.1 and 150.1.2.2 but since they get a summary address that encompasses those addresses they should be able to reach both hosts. When the packets from Area 3 going to 150.1.1.1 or 150.1.2.2 arrive on R5's interface, R5 uses the default route pointing to R4 since R5 filters 150.1.1.1 and 150.1.2.2. R4 is able to forward packets to 150.1.1.1 since it is a neighbor of R1 in Area 1 but when trying to reach 150.1.2.2 R4 points back at R5 creating a loop. So 150.1.2.2 is unreachable so far.

I created a policy on R5 and applied it on the LAN and WAN interfaces so that any traffic going to 150.1.1.1 uses the next hop of 155.1.0.1 and traffic going to 150.1.2.2 goes to next hop 155.1.0.2. For some reason this policy route is only taking effect when the discard route is in R5's routing table (150.1.0.0/22 pointing to NULL0) and I reach 150.1.1.1 or 150.1.2.2  but with some packet loss (I get !.!.!) Then when I looked at the solution for this task, I was supposed to take off the discard route from R5's routing table (remember it summarized 150.1.0.0/22) and when I did, the policy route did not take affect and I was not able to reach 150.1.1.1 by using the default route pointing to R4 but 50.1.2.2 is no longer reachable. Can someone please explain:

1) Why the policy route only takes effect with the discard route in R5's routing table
2) Why the policy route does not takes effect when the discard route is not in R5's routing table?
3) Why do I experience packet loss?

Here's some relevant "show" output:

R5(config)#do sh run | s router ospf
router ospf 1
 router-id 150.1.5.5
 area 0 range 150.1.0.0 255.255.252.0
 distribute-list prefix R1-R2 in
R5(config)#
R5(config)#do sh ip prefix-l R1-R2
ip prefix-list R1-R2: 3 entries
   seq 5 deny 150.1.1.1/32
   seq 10 deny 150.1.2.2/32
   seq 15 permit 0.0.0.0/0 le 32
R5(config)#
R5(config)#do sh ip route ospf | i 150.1.2.2/32|150.1.1.1/32
R5(config)#!NOT IN THE ROUTING TABLE RIGHT?
R5(config)#        
R5(config)#do sh ip ospf data | i 150.1.2.2|150.1.1.1
150.1.1.1       150.1.1.1       180         0x80000034 0x0032D4 4
150.1.2.2       150.1.2.2       1840        0x80000032 0x008F60 3
150.1.6.6       150.1.1.1       180         0x80000031 0x0007BD
155.1.13.0      150.1.1.1       180         0x80000031 0x00C8C0
155.1.23.0      150.1.2.2       1840        0x80000030 0x004F2F
155.1.146.0     150.1.1.1       180         0x80000031 0x00ED4C
192.10.1.0      150.1.2.2       1840        0x80000030 0x00D4C7
150.1.4.4       150.1.1.1       180         0x80000031 0x0019AF
150.1.6.6       150.1.1.1       180         0x80000031 0x00EED5
192.10.1.254    150.1.2.2       1840        0x80000030 0x00D0CB
R5(config)#
R5(config)#!HERE YOU SEE 150.1.1.1 IS ADTERTISED BY 150.1.1.1
R5(config)#!AND 150.1.2.2 BY 150.1.2.2
R5(config)#
R5(config)#!both are in the database so they are advertised
R5(config)#!to Area 3 devices
R5(config)#
R5(config)#do sh ip route | i 150.1.0.0/22
O        150.1.0.0/22 is a summary, 00:19:55, Null0
R5(config)#
R5(config)#!DISCARD ROUTE IS IN THE ROUTING TABLE
R5(config)#
R5(config)#do sh access-l
Extended IP access list 100
    10 permit ip any host 150.1.1.1 (57 matches)
Extended IP access list 101
    10 permit ip any host 150.1.2.2 (2953 matches)
R5(config)#
R5(config)#do sh route-m
route-map R1-R2-ID, permit, sequence 10
  Match clauses:
    ip address (access-lists): 100
  Set clauses:
    ip next-hop 155.1.0.1
  Policy routing matches: 39 packets, 3798 bytes
route-map R1-R2-ID, permit, sequence 11
  Match clauses:
    ip address (access-lists): 101
  Set clauses:
    ip next-hop 155.1.0.2
  Policy routing matches: 2843 packets, 275756 bytes
R5(config)#
R5(config)#!MY POLICY ROUTE SETTING NEXT-HOP TO
R5(config)#!155.1.0.1 OR 155.1.0.2
R5(config)#
R5(config)#do sh run int e0/0 | i policy
 ip policy route-map R1-R2-ID
R5(config)#
R5(config)#do sh run int s1/0 | i policy
 ip policy route-map R1-R2-ID
R5(config)#
R5(config)#do sh run int s1/1 | i policy
 ip policy route-map R1-R2-ID
R5(config)#do sh ip route ospf | i 0.0.0.0
Gateway of last resort is 155.1.45.4 to network 0.0.0.0
O*E1  0.0.0.0/0 [110/104] via 155.1.45.4, 00:25:12, Serial1/1

Now let's see SW4

SW4(config)#!HERE WE SEE 150.1.1.1 AND 150.1.2.2 ARE NOT IN THE ROUTING TABLE
SW4(config)#do sh ip route ospf | i 150.1.2.2|150.1.1.1                     
SW4(config)#
SW4(config)#!SW4 THOUGH GETS THE SUMMARY OF 150.1.0.0/22 FROM R5:
SW4(config)#do sh ip route ospf | i 150.1.0.0/22
O IA     150.1.0.0/22 [110/67] via 155.1.108.8, 1d01h, Vlan108
SW4(config)#                
SW4(config)#do ping 150.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
!.!.!
Success rate is 60 percent (3/5), round-trip min/avg/max = 16/18/20 ms
SW4(config)#!THERE IS PACKET LOSS, LET'S TRY 150.1.2.2
SW4(config)#do ping 150.1.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
!.!.!
Success rate is 60 percent (3/5), round-trip min/avg/max = 20/21/24 ms
SW4(config)#!THERE IS PACKET LOSS TOO                
SW4(config)#!LET'S CHECK TRACEROUTE 
SW4(config)#do trace 150.1.1.1    

Type escape sequence to abort.
Tracing the route to 150.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.108.8 0 msec 0 msec 0 msec
  2 155.1.58.5 4 msec 0 msec 4 msec
  3 155.1.0.1 20 msec 20 msec *
SW4(config)#
SW4(config)#do trace 150.1.2.2

Type escape sequence to abort.
Tracing the route to 150.1.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.108.8 16 msec 0 msec 4 msec
  2 155.1.58.5 0 msec 4 msec 0 msec
  3 155.1.0.2 16 msec 16 msec *
SW4(config)#!POLICY ROUTE ON R5 SEEMS TO BE WORKING

R5(config)#!NOW LET'S TAKE OFF THE DISCARD ROUTE
R5(config)#router ospf 1
R5(config-router)#no discard-route internal
R5(config-router)#do sh ip route ospf | i 150.1.0.0/22
R5(config-router)#!DISCARD ROUTE IS GONE, LET'S GO BACK TO SW4

SW4(config)#do ping 150.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/12/16 ms
SW4(config)#do ping 150.1.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
SW4(config)#do trace 150.1.1.1

Type escape sequence to abort.
Tracing the route to 150.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.108.8 84 msec 0 msec 0 msec
  2 155.1.58.5 0 msec 0 msec 0 msec
  3 155.1.45.4 12 msec 8 msec 12 msec
  4 155.1.146.1 12 msec 16 msec *
SW4(config)#!POLICY ROUTE IS NO LONGER TAKING EFFECT
SW4(config)#
SW4(config)#do trace 150.1.2.2                     

Type escape sequence to abort.
Tracing the route to 150.1.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 155.1.108.8 0 msec 0 msec 4 msec
  2 155.1.58.5 0 msec 4 msec 4 msec
  3 155.1.45.4 20 msec 16 msec 12 msec
  4 155.1.0.5 12 msec 16 msec 16 msec
  5 155.1.45.4 24 msec 88 msec 36 msec
  6 155.1.0.5 28 msec 32 msec 32 msec
  7 155.1.45.4 36 msec 32 msec 40 msec
  8 155.1.0.5 40 msec 48 msec 36 msec
  9 155.1.45.4 48 msec 48 msec 48 msec
 10 155.1.0.5 52 msec 56 msec 56 msec
 11 155.1.45.4 68 msec 64 msec 64 msec
 12 155.1.0.5 64 msec
SW4(config)#!WE HAVE A LOOP

 

Comments

  • welshydragonwelshydragon ✭✭ ✭✭

    1) Why the policy route only takes effect with the discard route in R5's routing table
    2) Why the policy route does not takes effect when the discard route is not in R5's routing table?
    3) Why do I experience packet loss?

    Can you provide some more information?

    What PBR have you applied and to what interfaces?  Your OSPF configurations?  This may explain your behaviour.

    You should test without PBR applied.

     

     

  • GabeGabe ✭✭ ✭✭

    The global OSPF config is posted in my "show" output, but for R5 I enabled the process on a per interface basis "ip ospf 1 area x"

    The BBR is straightforward:

    access-l 100 permit ip any h 150.1.1.1
    access-l 101 permit ip any h 150.1.2.2

    route-map R1-R2-ID permit 10
     match ip add 100
     set ip next-hop 155.1.0.1
    route-map R1-R2-ID permit 20
     match ip add 101
     set ip next-hop 155.1.0.2

    Under interface e0/0, s1/1, and s1/0:
    ip policy route-map R1-R2-ID

    Thanks for looking into this

  • GabeGabe ✭✭ ✭✭

    image

     

     

    I just realized the topology I originally posted is too big so here's a smaller one. Also, the PBR should be properly configured since it does take effect when the discard route exists in the routing table (see traceroute output on SW4)

  • JoeMJoeM ✭✭✭ ✭✭✭

    I just realized the topology I originally posted is too big so here's a smaller one.

     

    Hi Gabe,

    In order to shrink the first image, just edit the post -- and then -- drag a corner of the image to the correct size.  Give it a try.

  • welshydragonwelshydragon ✭✭ ✭✭

    The global OSPF config is posted in my "show" output, but for R5 I enabled the process on a per interface basis "ip ospf 1 area x"

    The BBR is straightforward:

    access-l 100 permit ip any h 150.1.1.1
    access-l 101 permit ip any h 150.1.2.2

    route-map R1-R2-ID permit 10
     match ip add 100
     set ip next-hop 155.1.0.1
    route-map R1-R2-ID permit 20
     match ip add 101
     set ip next-hop 155.1.0.2

    Under interface e0/0, s1/1, and s1/0:
    ip policy route-map R1-R2-ID

    Thanks for looking into this

    Can you confirm what the behaviour is when the PBR is removed from your interfaces.

  • GabeGabe ✭✭ ✭✭

    This is the behavior:

    "When the packets from Area 3 going to 150.1.1.1 or 150.1.2.2 arrive on
    R5's interface, R5 uses the default route pointing to R4 since R5
    filters 150.1.1.1 and 150.1.2.2. R4 is able to forward packets to
    150.1.1.1 since it is a neighbor of R1 in Area 1 but when trying to
    reach 150.1.2.2 R4 points back at R5 creating a loop. So 150.1.2.2 is
    unreachable so far"

  • Not sure why PBR is enabled on any interfaces other than e0/0 which is the one facing SW2. The PBR config on s1/0 can be especially problematic as it will policy route 150.1.2.2 bound traffic which will first follow the default route to R4 only to be sent back to R5 via the FR interface.  

     

    Couple of thoughts:

     

    1. Remove PBR from all interfaces except for e0/0

    2. Replace set ip next-hop with set interface command in PBR configuration

    3. sh ip route on R5

    4. Turn on debug ip policy

    5. Clear all interface counters before starting the test

     

    Edit: ok. Set interface won't work here. 

     

Sign In or Register to comment.