nanog mailing list archives
Re: not rewriting next-hop, pointing default, ...
From: Avi Freedman <freedman () netaxs com>
Date: Thu, 11 Sep 1997 21:15:49 -0400 (EDT)
no neighbor 192.41.177.73they should not care if you peer with them or not, they can have the upstream provider to give them your routes, then: ! set nexthop 192.41.177.121
The danger with this approach is, obviously, that the router that you try to do this to can go away. In which case you shoot yourself in the foot. Some day, someone will send me a valid use of 'set ip next-hop' but I haven't seen a good one yet.
The problem is not agreements. The problem is, as Scott says, detecting violation thereof is not easy. But traceroute -g is your friend.
<snip>
I also think it may be time we refuse to peer with anyone who inhibits LSR, as it seems that validation is now mandatory. I think we should be sending out a "LSR is mandatory" notice to our peers. Comments?
We have LSR turned off. We periodically run XP mappers that insert temporary /32 routes to map who sends traffic to whom, and to flag asymmetry so a human can look at it. A few routing engineers are on a mini-mailing-list that I have to get that info, esp. wrt who sends next-hop to them and who defaults to them. (eunet defaulting into uunet is OK, anyone else isn't) It's a perl/expect combo - no trace -g required.
Smaller peers. A non-trivial few are doing seriously disgusting things which are going to cost you a lot of pain and some cash. There is little incentive for larger folk to peer with smaller ones. Hence, larger peers will simply cut the smaller masses off rather than spending the resource to differentiate the bad apples from the good. Maybe you want to do something about it. And soon.
It's a danger, so the smaller peers should warn the larger peers and each other when they see extreme funniness happening.
randy
Avi
Current thread:
- Re: not rewriting next-hop, pointing default, ..., (continued)
- Re: not rewriting next-hop, pointing default, ... Sean M. Doran (Sep 11)
- Message not available
- Re: LSR and packet filters Ran Atkinson (Sep 12)
- Re: LSR and packet filters Sean M. Doran (Sep 13)
- Re: LSR and packet filters Alex "Mr. Worf" Yuriev (Sep 13)
- Re: LSR and packet filters Sean M. Doran (Sep 14)
- Re: not rewriting next-hop, pointing default, ... Alex.Bligh (Sep 12)
- Re: not rewriting next-hop, pointing default, ... Sean M. Doran (Sep 13)
- Message not available
- Re: protecting operational networks Ran Atkinson (Sep 15)
- Re: protecting operational networks Vadim Antonov (Sep 15)
- Re: not rewriting next-hop, pointing default, ... Karl Denninger (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Avi Freedman (Sep 11)
- set ip next-hop Bradley Dunn (Sep 11)
- Re: set ip next-hop Alex Rubenstein (Sep 11)
- Re: set ip next-hop Avi Freedman (Sep 11)
- Re: not rewriting next-hop, pointing default, ... Per Gregers Bilse (Sep 12)
- Re: not rewriting next-hop, pointing default, ...s Avi Freedman (Sep 12)
- Re: not rewriting next-hop, pointing default, ...s Nathan Stratton (Sep 12)
- Re: not rewriting next-hop, pointing default, ...s Avi Freedman (Sep 12)
- Re: not rewriting next-hop, pointing default, ...s Alex.Bligh (Sep 12)
- Re: not rewriting next-hop, pointing default, ...s Avi Freedman (Sep 12)
- Re: not rewriting next-hop, pointing default, ...s Nathan Stratton (Sep 12)