On occasion, I use traceroute with the option that allows a different viewpoint (as in the IP loose source route option). Today, I tried to: traceroute -g 134.164.8.2 192.156.135.34 traceroute to 192.156.135.34 (192.156.135.34), 30 hops max, 40 byte packets 1 esnet-rt2 (192.16.1.244) 6 ms 4 ms 18 ms 2 lanl3-e-lanl1.es.net (134.55.20.139) 4 ms 4 ms 4 ms 3 llnl-e-llnl2.es.net (134.55.12.225) 40 ms 37 ms 56 ms 4 fix-west-cpe.SanFrancisco.mci.net (192.203.230.18) 53 ms 42 ms 52 ms 5 border3-hssi2-0.SanFrancisco.mci.net (204.70.34.9) 52 ms 49 ms 56 ms 6 core-fddi-0.SanFrancisco.mci.net (204.70.2.161) 55 ms 66 ms 55 ms 7 core-hssi-2.LosAngeles.mci.net (204.70.1.41) 55 ms 78 ms 64 ms 8 core-hssi-2.Houston.mci.net (204.70.1.33) 88 ms 87 ms 90 ms 9 core-hssi-2.Atlanta.mci.net (204.70.1.25) 105 ms 113 ms 110 ms 10 border1-fddi0-0.Atlanta.mci.net (204.70.2.50) 171 ms 119 ms 112 ms 11 suranet-cpe.Atlanta.mci.net (204.70.16.6) 121 ms 120 ms 111 ms 12 atu2-atu-cf.sura.net (192.221.42.2) 111 ms 142 ms 111 ms 13 jck1-atu2-c1.sura.net (128.167.2.2) 142 ms jck1-atu2-c3mb.sura.net (128.167.4.2) 143 ms jck1-atu2-c1.sura.net (128.167.2.2) 226 ms 14 wes-jck1-c1.sura.net (192.221.5.34) 176 ms !S I thought that it was still reasonable for service providers to allow that option while possibly denying it on an interface to a customers network. What's the ruling on that? Thanks, Phil
On occasion, I use traceroute with the option that allows a different viewpoint (as in the IP loose source route option). Today, I tried to:
traceroute -g 134.164.8.2 192.156.135.34
traceroute to 192.156.135.34 (192.156.135.34), 30 hops max, 40 byte packets 1 esnet-rt2 (192.16.1.244) 6 ms 4 ms 18 ms 2 lanl3-e-lanl1.es.net (134.55.20.139) 4 ms 4 ms 4 ms 3 llnl-e-llnl2.es.net (134.55.12.225) 40 ms 37 ms 56 ms 4 fix-west-cpe.SanFrancisco.mci.net (192.203.230.18) 53 ms 42 ms 52 ms 5 border3-hssi2-0.SanFrancisco.mci.net (204.70.34.9) 52 ms 49 ms 56 ms 6 core-fddi-0.SanFrancisco.mci.net (204.70.2.161) 55 ms 66 ms 55 ms 7 core-hssi-2.LosAngeles.mci.net (204.70.1.41) 55 ms 78 ms 64 ms 8 core-hssi-2.Houston.mci.net (204.70.1.33) 88 ms 87 ms 90 ms 9 core-hssi-2.Atlanta.mci.net (204.70.1.25) 105 ms 113 ms 110 ms 10 border1-fddi0-0.Atlanta.mci.net (204.70.2.50) 171 ms 119 ms 112 ms 11 suranet-cpe.Atlanta.mci.net (204.70.16.6) 121 ms 120 ms 111 ms 12 atu2-atu-cf.sura.net (192.221.42.2) 111 ms 142 ms 111 ms 13 jck1-atu2-c1.sura.net (128.167.2.2) 142 ms jck1-atu2-c3mb.sura.net (128.167.4.2) 143 ms jck1-atu2-c1.sura.net (128.167.2.2) 226 ms 14 wes-jck1-c1.sura.net (192.221.5.34) 176 ms !S
I thought that it was still reasonable for service providers to allow that option while possibly denying it on an interface to a customers network.
What's the ruling on that?
With all of the hullaballou recently surrounding network security, I would expect to start seeing more and more customer-access routers disallowing loose source-routed traffic. - paul _______________________________________________________________________________ Paul Ferguson US Sprint tel: 703.689.6828 Managed Network Engineering internet: paul@hawk.sprintmrn.com Reston, Virginia USA http://www.sprintmrn.com
In any case, the router that is stomping on the LSRR packets is the customer router, and does not belong to the ISP, SURAnet. - roy - ------------------------------------------------------------------------- | roy alcala | MCI | | IP Development | 2100 Reston Parkway | | roy@mci.net | Reston, Virginia 22091 | | beep-roy@mci.net (pager) | (703) 715-7425 | | (800) SKY-PAGE PIN 1633689 | (703) 715-7066 FAX | ------------------------------------------------------------------------- | finger roy@mci.net for other information | -------------------------------------------------------------------------
On occasion, I use traceroute with the option that allows a different viewpoint (as in the IP loose source route option). Today, I tried to:
traceroute -g 134.164.8.2 192.156.135.34
traceroute to 192.156.135.34 (192.156.135.34), 30 hops max, 40 byte packets 1 esnet-rt2 (192.16.1.244) 6 ms 4 ms 18 ms 2 lanl3-e-lanl1.es.net (134.55.20.139) 4 ms 4 ms 4 ms 3 llnl-e-llnl2.es.net (134.55.12.225) 40 ms 37 ms 56 ms 4 fix-west-cpe.SanFrancisco.mci.net (192.203.230.18) 53 ms 42 ms 52 ms 5 border3-hssi2-0.SanFrancisco.mci.net (204.70.34.9) 52 ms 49 ms 56 ms 6 core-fddi-0.SanFrancisco.mci.net (204.70.2.161) 55 ms 66 ms 55 ms 7 core-hssi-2.LosAngeles.mci.net (204.70.1.41) 55 ms 78 ms 64 ms 8 core-hssi-2.Houston.mci.net (204.70.1.33) 88 ms 87 ms 90 ms 9 core-hssi-2.Atlanta.mci.net (204.70.1.25) 105 ms 113 ms 110 ms 10 border1-fddi0-0.Atlanta.mci.net (204.70.2.50) 171 ms 119 ms 112 ms 11 suranet-cpe.Atlanta.mci.net (204.70.16.6) 121 ms 120 ms 111 ms 12 atu2-atu-cf.sura.net (192.221.42.2) 111 ms 142 ms 111 ms 13 jck1-atu2-c1.sura.net (128.167.2.2) 142 ms jck1-atu2-c3mb.sura.net (128
.167.4.2) 143 ms jck1-atu2-c1.sura.net (128.167.2.2) 226 ms
14 wes-jck1-c1.sura.net (192.221.5.34) 176 ms !S
I thought that it was still reasonable for service providers to allow that option while possibly denying it on an interface to a customers network.
What's the ruling on that?
With all of the hullaballou recently surrounding network security, I would expect to start seeing more and more customer-access routers disallowing loose source-routed traffic.
- paul
______________________________________________________________________________ _ Paul Ferguson US Sprint tel: 703.689.6828 Managed Network Engineering internet: paul@hawk.sprintmrn.co m Reston, Virginia USA http://www.sprintmrn.com
We depend on LSRR for nearly all of our diagnosis. My attitude is pretty simple. LSRR is a mandatory part of IP. If no LSRR, it's not IP, and the problem report goes immediately to the owner of the router in question. That said, I understand the practicalities of excluding all LSRR at the site level. We strongly encourage sites to have at least one address (with IP forwarding enabled) on the outside of their firewall. And if a site is having a problem and insists on not running IP, I have no tools capable of diagnosing their external connectivity. --MM--
participants (4)
-
C. Philip Wood -
Matt Mathis -
paul＠hawksbill.sprintmrn.com -
roy alcala