在作者的traceroute程序版本中，-G選項與前面所描述的-g選項是完全一樣的，不過此時是嚴格的源站選路而不是寬松的源站選路。我們可以采用這個選項來觀察在指明無效的嚴格的源站選路時其結果會是什么樣的。從圖8-5可以看出來，從作者的子網發往NSFNET的數據報的正常路由器順序是netb，gateway，butch和gabby（為了便于查看，后面所 有的輸出結果中，均省略了域名后綴.tuc .noao .edu和.telcom .arizona .edu）。我們指定了一個嚴格源路由，使其試圖將數據報從gateway直接發送到gabby，而省略了butch。 我們可以猜測到其結果會是失敗的，正如圖8 - 9所給出的結果。  這里的關鍵是在于TTL字段為3的輸出行中，RTT后面的!S。這表明traceroute程序接收到ICMP“源站路由失敗”的差錯報文：即圖6-3中type字段為3，而code字段為5。TTL字段為3的第二個RTT位置的星號表示未收到這次探查的應答信號。這與我們所猜想的一樣，gateway不可能直接發送數據報給gabby，這是因為它們之間沒有直接的連接。 TTL字段為2和3的結果都來自于gateway，對于TTL字段為2的應答來自gateway，是因為gateway接收到TTL字段為1的數據報。在它查看到（無效的）嚴格的源站選路之前，就發現TTL已過期，因此發送回ICMP超時報文。TTL字段等于3的行，在進入gateway時其TTL字段為2，因此，它查看嚴格的源站選路，發現它是無效的，因此發送回ICMP源站選路失敗 的差錯報文。 圖8-10給出了與本例相對應的tcpdump輸出結果。該輸出結果是在sun和netb之間的S L I P鏈路上遇到的。我們必須在tcpdump中指定-v選項以顯示出源站路由信息。這樣，會輸出一些像數據報ID這樣我們并不需要的結果，我們在給出結果中將這些不需要的結果刪除掉。同樣，用SSRR表示“嚴格的源站及記錄路由”。 首先注意到， sun所發送的每個UDP數據報的目的地址都是netb，而不是目的主機(westgate)。這一點可以用圖8-7的例子來解釋。類似地，-G選項所指定的另外兩個路由器（gateway和gabby）以及最終目(westgate)成為第一跳的SSRR選項。 從這個輸出結果中，還可以看出，traceroute程序所采用的定時時間（第1 5行和1 6行之間的時間差）是5秒。