3.8 begs for a technique better than traceroute.... see my post

 

The scenario on 3.8:  reliable policy routing

 

  • R1 is the "HUB" and has no ROUTES
  • All neigbors have default routes to R1
  • R1 has PBR on P2P link with R3 and PBR is deployed on that interface
  • PBR is designed to take the "long" way out to the destination
  • Without PBR R1 would not know what to do
  • Traceroute as a verfication tool only shows path to the endpoint
  • Wouldn't you wantto verify the PATH back to your device?  why not? prove to yourself how things work.
  • Keep reading if you want to see an "extended ping" which gives the path to and from the destination. Nice!
  • extended Ping is an handy tool.

 


Rack13R3#ping
Protocol [ip]:
Target IP address: 150.13.4.4
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 155.13.13.3
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: record
Number of hops [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[RV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.13.4.4, timeout is 2 seconds:
Packet sent with a source address of 155.13.13.3
Packet has IP options:  Total option bytes= 39, padded length=40
 Record route: <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)

Reply to request 0 (72 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (155.13.13.3)
   (155.13.45.5)
   (150.13.4.4)
   (155.13.146.4)
   (155.13.13.1)
   (155.13.13.3) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 1 (72 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (155.13.13.3)
   (155.13.45.5)
   (150.13.4.4)
   (155.13.146.4)
   (155.13.13.1)
   (155.13.13.3) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 2 (76 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (155.13.13.3)
   (155.13.45.5)
   (150.13.4.4)
   (155.13.146.4)
   (155.13.13.1)
   (155.13.13.3) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 3 (72 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (155.13.13.3)
   (155.13.45.5)
   (150.13.4.4)
   (155.13.146.4)
   (155.13.13.1)
   (155.13.13.3) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Reply to request 4 (73 ms).  Received packet has options
 Total option bytes= 40, padded length=40
 Record route:
   (155.13.13.3)
   (155.13.45.5)
   (150.13.4.4)
   (155.13.146.4)
   (155.13.13.1)
   (155.13.13.3) <*>
   (0.0.0.0)
   (0.0.0.0)
   (0.0.0.0)
 End of list

Success rate is 100 percent (5/5), round-trip min/avg/max = 72/73/76 ms
Rack13R3#trace
Rack13R3#traceroute 150.13.5.5

Type escape sequence to abort.
Tracing the route to 150.13.5.5

  1 155.13.13.1 16 msec 16 msec 16 msec
  2 155.13.146.4 16 msec 16 msec 16 msec
  3 155.13.45.5 36 msec *  36 msec
Rack13R3#traceroute 150.13.4
% Unrecognized host or address.

Rack13R3#traceroute 150.13.4.4

Type escape sequence to abort.
Tracing the route to 150.13.4.4

  1 155.13.13.1 16 msec 16 msec 12 msec
  2 155.13.0.5 40 msec 44 msec 40 msec
  3 155.13.45.4 32 msec *  28 msec
Rack13R3#
Rack13R3#
Rack13R3#
Rack13R3#
Rack13R3#

 

NET_OG

Comments

  • INE: I have a recommendation

     

    Since R1 is not an ISR I think you should change the topology here so that an ISR is taking the place of R1.  The lab is too good and the  "STAR" of this task should be an ISR since the IP SLA commands and tracccer commands are different on the 2600XM series.

     

    NET_OG

     

     

     

     

  • I totally agree with you .

     

    IP sla command are different and we dont really want "useless" command for the lab. 

     

    Thanks 

  • Just to summarize: please do not have us do IP SLA on 2600XM: the commands are different from ISR.  This task should be modified so that the IPSLA command is done on an ISR.

     

    INE TECH EDIT TEAM: please review this on next round of edits for chapter 3.

     

    NET_OG

     

     

     

  • I totally agree with you .

     

    IP sla command are different and we dont really want "useless" command for the lab. 

     

    Thanks 

     

    Using Dynamips with Cisco 3660 v12.4 image, the solution on the workbook works perfectly.

  • I am not using real gear yet, but when I do get a real rack with a 2600, this is good to know. Thanks for the heads up... Like Mouamer, I am using dynamips and with a 3725, the IP SLA configs in the solution works just fine.

Sign In or Register to comment.