I'm surprised to see that every looking glass I know is only reachable via an interface made for humans, not for programs. When you want to query the LG via a program (for instance to monitor your routes on a distant LG), you need to emulate an human being and parse HTML (or sometimes Cisco text) replies. Does anyone operate looking glasses with an interface made for programs such as XML-RPC <URL:http://www.xml-rpc.org/>, SOAP <URL:http://www.soapware.org/>, Java RMI, Corba (no, I'm joking) or Microsoft COM (joking again)? What do you think of a standard XML-RPC API for looking glasses?
Hi Stephane,
I'm surprised to see that every looking glass I know is only reachable via an interface made for humans, not for programs. When you want to query the LG via a program (for instance to monitor your routes on a distant LG), you need to emulate an human being and parse HTML (or sometimes Cisco text) replies.
Public looking glass are for humans. I do not want my looking-glass being heavily loaded by cron tool. looking-glass use router CPU and i do not want to see a foolish guy to put a : * * * * * Crontab ... Route-server is a solution to have load CPU router. Vincent.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Vincent Gillet Sent: Wednesday, January 23, 2002 4:46 AM To: Stephane Bortzmeyer Cc: nanog@merit.edu Subject: Re: Looking glasses with programmatic interface? Hi Stephane,
I'm surprised to see that every looking glass I know is only reachable via an interface made for humans, not for programs. When you want to query the LG via a program (for instance to monitor your routes on a distant LG), you need to emulate an human being and parse HTML (or sometimes Cisco text) replies.
Public looking glass are for humans. I do not want my looking-glass being heavily loaded by cron tool. looking-glass use router CPU and i do not want to see a foolish guy to put a : * * * * * Crontab ... Route-server is a solution to have load CPU router. Vincent. ----- This raises a good point. Since most LGs are running on a dedicated web server somewhere inside of a network, one could very easily install zebra on this webserver with a read-only BGP image from several internal routers [say all the borders]. This has two benefits: a) Queries do not bog down production routers in fact the load is linear, and b) The LG tool only need look at localhost for all answers. This only costs 120mb of RAM per view and saves network overhead to boot. Traceroutes may need to still go out to the end router, but I doubt anyone would allow a query to those in an automated fashion. Deepak Jain AiNET
### On Wed, 23 Jan 2002 14:39:45 -0500, "Deepak Jain" <deepak@ai.net> ### casually decided to expound upon "Vincent Gillet" <vgi@zoreil.com>, ### "Stephane Bortzmeyer" <bortzmeyer@gitoyen.net> the following thoughts ### about "RE: Looking glasses with programmatic interface?": DJ> This raises a good point. Since most LGs are running on a dedicated web DJ> server somewhere inside of a network, one could very easily install zebra on DJ> this webserver with a read-only BGP image from several internal routers [say DJ> all the borders]. This has two benefits: a) Queries do not bog down DJ> production routers in fact the load is linear, and b) The LG tool only need DJ> look at localhost for all answers. This only costs 120mb of RAM per view and DJ> saves network overhead to boot. I did something similar to this by hacking rsd to not export any learned routes, peered it with several border and core routers and then dumped the routing table once every 15 minutes into a program which reformatted it into RPSL objects that was then imported into irrd as a database. I used the source field to specify the router it was seen from. One could then query irrd for routes using whois. And one could also use the different search commands to get routes by AS, router, etc... DJ> Traceroutes may need to still go out to the end router, but I doubt anyone DJ> would allow a query to those in an automated fashion. Or one could create an automated network health monitoring system that tracks path changes... Check out what Caimis did. -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
I'm surprised to see that every looking glass I know is only reachable via an interface made for humans, not for programs. When you want to query the LG via a program (for instance to monitor your routes on a distant LG), you need to emulate an human being and parse HTML (or sometimes Cisco text) replies.
send code <tm>
### On Wed, 23 Jan 2002 10:24:25 +0100, Stephane Bortzmeyer ### <bortzmeyer@gitoyen.net> casually decided to expound upon ### nanog@merit.edu the following thoughts about "Looking glasses with ### programmatic interface?": SB> What do you think of a standard XML-RPC API for looking glasses? There was some discussion during the OPS Area meeting at the London IETF on using XML for router configuration. I'm not certain anyone might have been willing to extend some of those concepts into the area of table dumps but you never know. At my previous employ, I had architected a non-router based solution for a distributed looking glass which involved dedicated route-listener boxes and peering sessions to obtain both internal and external routing table views. We began talks with NextHop (we were going to use gated) on incorporating our design requirements for a streaming datafeed which could then be collected and stored in a distributed datastore to be queried later via SQL or obtained as an object via a CORBA interface. I don't know how far NextHop had progressed on implimentation. Unfortunately, in light of market conditions and tightened budgets my employers felt that this was an unnecessary project and support for it was cut by my management. Maybe if there's renewed interest, further work can be continued in this area. -- /*===================[ Jake Khuon <khuon@NEEBU.Net> ]======================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | --------------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| N E T W O R K S | +=========================================================================*/
participants (5)
-
Deepak Jain -
Jake Khuon -
Randy Bush -
Stephane Bortzmeyer -
Vincent Gillet