[AusNOG] International link issue

Simon Knight simon.knight at gmail.com
Fri Feb 24 14:35:05 EST 2012


I also agree with the comment about pushing it to the control plane.
If the repository can be part of the workflow then it becomes useful
to the operator. Having to duplicate entries means they are  likely to
be out of date.
Rtconfig goes some way towards this, but has its own problems:
https://lists.isc.org/pipermail/irrtoolset/2009-October/000605.html

Making the repository the authoritative database provides an incentive
for it to be maintained.

On 24 February 2012 13:55, David Hughes <David at hughes.com.au> wrote:
>
> This doesn't have to be a router-based, real-time solution.  And in my opinion it shouldn't be.  This is an OSS role and could easily be handled behind the scenes.  Using RPSL tools like rtconfig and regularly pushing out prefix lists that have changed would not be difficult to implement nor onerous on the equipment in the data path.
>
> As Geoff said, getting a source you can trust is the tricky bit.  And I agree with Macca, the RIR's are an obvious place to start looking for a solution.
>
>
> David
> ...
>
>
>
> On 24/02/2012, at 1:09 PM, Aaron Swayn wrote:
>
>> I was thinking the same thing.. getting the data together is the easy bit IMO, but interacting with the control plane in near-real time will be interesting. I'm surprised the vendor's haven't jumped onto this one yet. We can do IDP, AV, CF, etc but not linking prefix filters to external DB's seems simple, but I'm no JunOS/IOS designer either.
>>
>> Someone should put in a feature request. :)
>>
>> -----Original Message-----
>> From: McDonald Richards [mailto:macca at vocus.com.au]
>> Sent: Friday, 24 February 2012 2:01 PM
>> To: Geoff Huston
>> Cc: Aaron Swayn; Ausnog at ausnog.net
>> Subject: Re: [AusNOG] International link issue
>>
>> Tie route registrys in with the address registrys. Make a prefix owner elect an origin ASN at the RR level and come up with a system for delegation.
>>
>> The next challenge is getting it into the router control plane...
>>
>> Macca
>>
>>
>>
>> On 24/02/2012, at 1:51 PM, Geoff Huston <gih at apnic.net> wrote:
>>
>>> On 24/02/2012, at 12:13 PM, Aaron Swayn wrote:
>>>
>>>> I’ve seen Mr BGP, Geoff Huston lurks on these forums from time to time (I think he appeared a few day ago). Might be a good time to suggest his next monthly column onhttp://www.potaroo.net/ for March to cover ISP BGP peering design. Seems the list has some significant interest in how, where, why and best practices. I believe Geoff has written a few books on ISP’s over the many years and could share some valuable insights (and maybe some war stories too from his days at Telstra)
>>>>
>>>
>>>
>>> I'll let the Telstra folk talk about Telstra - it's been many years since I worked for them so no doubt much of my recollections about their network are out of date in any case.
>>>
>>> But more generally I'd offer the advice to _always_ use route filters in BGP for your customer and peer links. And that applies to your outbound advertisements as well as filtering inbound advertisements. So its incumbent on both parties to exercise control - this kind of belt and suspenders multiple control structure ensures that single typo problems should not escalate into exported routing nightmares!
>>>
>>> And that way you can hopefully avoid the worst of the third party damage from fat finger slip ups that we all (me too in past years) do from time to time, and if you do stuff up then with filtering in place the network you damage should be limited to just your own!
>>>
>>> On the topic of how to maintain route filters, I was never a big fan of route registries in the past, but this is something that I'm coming around on. To get everyone to spend the time to maintain their own RRDB entries and keep them up to date has always been a massive ask, and in the past I was ready to condemn route registries as being little more that a collection of amorphous data, some of which was real and current, some of which was historic or just plain wrong, and no way to tell which was which.
>>>
>>> But frankly we really don't have any alternative as far as I can see. In this case routing security won't help at all, and we really have nothing else around. But I have to also observe  what we are doing at the moment is pretty lousy and adherence is piecemeal (e.g. yesterday's route leak) - many providers and exchanges operate their own route registries (or not!), and an ISP with multiple external connections has to take on a maintenance task of maintaining routing information in a number of provider and exchange databases. There really has to be a better way to do this.
>>>
>>> So the question I have is - how can we make a route registry process efficient, accurate, consistent, workable and generally useful?
>>>
>>> cheers,
>>>
>>> Geoff
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog



More information about the AusNOG mailing list