On Fri, 07 April 2000, Scott Call wrote:
As we (ATG) are about to move into PAIX, SIX, and MAE-East ATM, I wanted to ask what the members of Nanog used to manage their peering with others (software wise). Currently we are all Cisco based, but Juniper and others are also eventualities.
I've looked at the RtConfig program and it seems like a place to start, but I get the feeling that this is not the method most use.
Most folks configure provider-to-provider BGP peering sessions manually. Fortunately they change fairly infrequently. A few use some automated tools to push and collect router configurations, and macro or script tools like M4 and Perl. Even fewer use RtConfig or other database driven configuration tools. ANS had the closest to fully automated their peering configurations, but they're gone now. The basic problem is most providers have homegrown systems which can't share data with other providers. RPSL/IRRDB are attempts to communicate the information between providers, but generally different providers use very different forms and procedures. Sprint used a completely different method of exchanging information about BGP configutions than Cable&Wireless does. So if you peer with 50 different people, you may have 55 different processes (yes, some providers have more than one process even within their own company). I suspect Randy will explain its not a problem with Verio, but Verio is a exception.
Hello Sean, Sean Donelan wrote:
On Fri, 07 April 2000, Scott Call wrote:
As we (ATG) are about to move into PAIX, SIX, and MAE-East ATM, I wanted to ask what the members of Nanog used to manage their peering with others (software wise). Currently we are all Cisco based, but Juniper and others are also eventualities.
I've looked at the RtConfig program and it seems like a place to start, but I get the feeling that this is not the method most use.
Most folks configure provider-to-provider BGP peering sessions manually.
Fortunately they change fairly infrequently. A few use some automated tools to push and collect router configurations, and macro or script tools like M4 and Perl. Even fewer use RtConfig or other database driven configuration tools. ANS had the closest to fully automated their peering configurations, but they're gone now.
The basic problem is most providers have homegrown systems which can't share data with other providers. RPSL/IRRDB are attempts to communicate the information between providers, but generally different providers use very different forms and procedures. Sprint used a completely different method of exchanging information about BGP configutions than Cable&Wireless does. So if you peer with 50 different people, you may have 55 different processes (yes, some providers have more than one process even within their own company).
To make sure I understand your message, do you mean RPSL/IRR are not used by most of the providers? Do they really have to configure manual line by line using CLI? I heard otherwise from some other people (who might not be entirely correct :-) I'm trying to understand how BGP4 policy are being configured by ISPs. Your input is highly appreciated.
I suspect Randy will explain its not a problem with Verio, but Verio is a exception.
To make sure I understand your message, do you mean RPSL/IRR are not used by most of the providers?
Whether one uses RPSL/IRR or not ...
Do they really have to configure manual line by line using CLI?
... does not necessarily have any bearing on how routers are configured. I have tools that are capable of integrating policy information from RADB (using peval; I don't use RtConfig) or from private databases (updated privately with the peer who has requested to share their policy that way) and turning that information into the right vendor-specific statement of policy. The process of "uploading" policy changes is also automatic. At no time are configuration statements entered at a router's CLI prompt. Stephen
participants (3)
-
HANSEN CHAN -
Sean Donelan -
Stephen Stuart