While on the subject of IXP blocks, we also ended up redistributing the
IXP blocks and sending them to our BGP customers (who do not receive a
default) so that traceroutes and such from Looking Glasses do not break.
They can then choose to filter them as they wish.
This is backwards. Do not break the architecture to fix a broken
looking glass (or to work around bad interpretations of real-world
traceroute results). Spend a few minutes scripting your looking
glass software so that if it sees a well-known target, or an expected
real-world result (1918 addresses that YOU are using, with expected
ttl-distance), it returns a "sanitized" result to a naive
looking glass user.
I wonder if there exists the possibility of a useful (perhaps open source)
generalized expert system to interpret traceroute data?
"configure; make; make install" is probably even easier than
breaking one's filter lists to leak prefixes all over the place.
Sean. (that was a hint. you know who you are.)
Tweaking our Looking Glass software by itself would not fix the problem
(ours doesn't have this problem anyway). To fix the problem everyone
would have to tweak their Looking Glass software since the problem can
be seen when someone traceroutes from a peer or 3rd party's Looking
Glass into our customer (in the event they weren't receiving the IXP
blocks from us).
One better might be to have the Looking Glass participating routers
manipulate their source IP address for pings and traceroutes.
Router(config)#ip traceroute source-interface ?
% Unrecognized command
Router(config)#ip ping source-interface ?
% Unrecognized command
Router# set system default-address-selection
Hey that works!
Is there a way of doing this on a Cisco?
"Sean M. Doran" wrote:
It just occurred to me that one could use the extended traceroute on the
back end for a Cisco to tweak the source IP but there again, it would
not be completely effective unless everyone did this.
David McGaugh wrote:
Target IP address: 184.108.40.206
Source address: 220.127.116.11
Numeric display [n]:
Timeout in seconds :
Probe count :
Minimum Time to Live :
Maximum Time to Live :
Port Number :
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to santpoort.vuurwerk.nl (18.104.22.168)
1 sara.amsix-ge1.versatel.net (22.214.171.124) [AS 1200] 0 msec 0 msec 0 msec
2 126.96.36.199 [AS 13127] 4 msec 4 msec 4 msec
3 ge5-0-0.b1.vuurwerk.versatel.net (188.8.131.52) [AS 13127] 0 msec 4 msec 0 msec
4 santpoort.vuurwerk.nl (184.108.40.206) [AS 15942] 4 msec 0 msec 4 msec
Without giving the source address parameter, the traceroute would
originate from 220.127.116.11, which is the routers peering ip.