Mailing List Archive: nsp: ipv6

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

Index | Next | Previous | View Threaded

jeroen at unfix

Aug 17, 2012, 5:38 AM

Post #1 of 8 (504 views)
Permalink

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

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
> http://www.sixxs.net/tools/grh/signup/
> 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.

Greets,
Jeroen

gert at space

Aug 17, 2012, 5:41 AM

Post #2 of 8 (482 views)
Permalink

Re: GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)) [In reply to]

Hi,

On Fri, Aug 17, 2012 at 02:38:25PM +0200, Jeroen Massar wrote:
> 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.

"Please send all BGP prefixes that you have in your routers, except those
that are generated in your AS or in downstream ASes and not advertised to
upstream (transit) routers"

Might be too complicated to understand, tho...

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

roger at jorgensen

Aug 17, 2012, 5:43 AM

Post #3 of 8 (487 views)
Permalink

Re: GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)) [In reply to]

> Hi,
>
> On Fri, Aug 17, 2012 at 02:38:25PM +0200, Jeroen Massar wrote:
>> 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.
>
> "Please send all BGP prefixes that you have in your routers, except those
> that are generated in your AS or in downstream ASes and not advertised to
> upstream (transit) routers"
>
> Might be too complicated to understand, tho...

"Please send us all BGP prefixes announced to your upstream (transit)" ?

--
------------------------------
Roger Jorgensen | - ROJO9-RIPE - RJ1866P-NORID
roger [at] jorgensen | - The Future is IPv6
-------------------------------------------------------

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

gert at space

Aug 17, 2012, 5:45 AM

Post #4 of 8 (483 views)
Permalink

Re: GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)) [In reply to]

Hi,

On Fri, Aug 17, 2012 at 02:43:51PM +0200, "Roger Jørgensen" wrote:
> > On Fri, Aug 17, 2012 at 02:38:25PM +0200, Jeroen Massar wrote:
> >> 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.
> >
> > "Please send all BGP prefixes that you have in your routers, except those
> > that are generated in your AS or in downstream ASes and not advertised to
> > upstream (transit) routers"
> >
> > Might be too complicated to understand, tho...
>
> "Please send us all BGP prefixes announced to your upstream (transit)" ?

No, that's not the right one. GRH wants to see "what people see", so
everything *received* from the upstream is much more worth for GRH than
"sent to upstream".

"sent to upstream" is only a useful criteria for prefixes generated
internally (to differenciate between "the aggregate" and "all the
unaggregated stuff one needs inside the AS, but the world should never
see").

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

roger at jorgensen

Aug 17, 2012, 5:50 AM

Post #5 of 8 (485 views)
Permalink

Re: GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)) [In reply to]

> Hi,
>
> On Fri, Aug 17, 2012 at 02:43:51PM +0200, "Roger Jørgensen" wrote:
>> > On Fri, Aug 17, 2012 at 02:38:25PM +0200, Jeroen Massar wrote:
>> >> 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.
>> >
>> > "Please send all BGP prefixes that you have in your routers, except
>> those
>> > that are generated in your AS or in downstream ASes and not advertised
>> to
>> > upstream (transit) routers"
>> >
>> > Might be too complicated to understand, tho...
>>
>> "Please send us all BGP prefixes announced to your upstream (transit)" ?
>
> No, that's not the right one. GRH wants to see "what people see", so
> everything *received* from the upstream is much more worth for GRH than
> "sent to upstream".
>
> "sent to upstream" is only a useful criteria for prefixes generated
> internally (to differenciate between "the aggregate" and "all the
> unaggregated stuff one needs inside the AS, but the world should never
> see").

I had it the wrong way around, I did mean recieved from your
upstream/transit... but that to excluded some date like what's generated
inside the network.

--
------------------------------
Roger Jorgensen | - ROJO9-RIPE - RJ1866P-NORID
roger [at] jorgensen | - The Future is IPv6
-------------------------------------------------------

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

dr at cluenet

Aug 17, 2012, 6:30 AM

Post #6 of 8 (482 views)
Permalink

Re: GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)) [In reply to]

On Fri, Aug 17, 2012 at 02:38:25PM +0200, Jeroen Massar wrote:
> 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.

How many peers do you think will manage to tag things up properly? :)

> 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.

"Send the set of prefixes you send to downstream BGP customers".

Plain simple.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

gert at space

Aug 17, 2012, 6:33 AM

Post #7 of 8 (480 views)
Permalink

Re: GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)) [In reply to]

Hi,

On Fri, Aug 17, 2012 at 03:30:33PM +0200, Daniel Roesen wrote:
> "Send the set of prefixes you send to downstream BGP customers".

+1

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

jeroen at unfix

Aug 17, 2012, 8:31 AM

Post #8 of 8 (481 views)
Permalink

Re: GRH Peering Policy (Was: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)) [In reply to]

On 2012-08-17 15:33, Gert Doering wrote:
> Hi,
>
> On Fri, Aug 17, 2012 at 03:30:33PM +0200, Daniel Roesen wrote:
>> "Send the set of prefixes you send to downstream BGP customers".
>
> +1

While updating I noticed that http://www.sixxs.net/tools/grh/peering/
already had:
8<---------------------
Peers should send their full-table as they would be sent to downstream
customers, similar to a transit setup, which normally means that routes
from the internal AS will be aggregated.
---------------------->8

I've added a column to the table at the top with the above line to
complement it and linked the /signup/ page to it.

Should be online now. I'll spam peers in the run of next week, as I am
trying to keep myself to an allocated timeslot in the next few days to
do some revamping of AICCU and GRH so that they are up to par for 2012
and then can take that along.

As usual, thanks for the input, that is always very well appreciated, if
anything else comes up don't hesitate to bring it up here or directly at
info [at] sixxs

Greets,
Jeroen

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads