GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17))

Jeroen Massar jeroen at
Fri Aug 17 14:38:25 CEST 2012

On 2012-08-17 14:25, Daniel Roesen wrote:
> On Fri, Aug 17, 2012 at 12:13:17PM +0100, Nick Hilliard wrote:
>> Regarding the prefix leaks: le sigh.  Don't people ever learn not to accept
>> arbitrary crap from customers?  Prefix leaks require stupidity on two
>> parts, not just one.
> Those are not necessarily "leaks". There are a lot of GRH peers who
> think they SHOULD actually send full unfiltered IBGP table and do it on
> purpose. This is probably rooted in
> stating: "The peer is requested to send as much as possible though."
> Perhaps this signup instructions should be polished up.

The "send as much as possible" line is there as that will provide
insight if a peer has those prefixes at all. Indeed, that makes bogon
detection a bit tricker when some do and some do not send these
prefixes. In the current system it would not be possible, but the idea
in my head (grh specific bgpd) would allow a peer to say 'if this
community is present it is an internal route not exported to clients'
and avoid this issue but does allow one to send all prefixes that way.
But that is a long way off, though needed for performance reasons.

As such, if possible please formulate a proper GRH peering policy that
works best for the community that uses the system, we can then put it up
on the GRH pages and inform peers of this change.


More information about the ipv6-ops mailing list