perfsonar development work

["Guilherme Fernandes" <>]

Stijn Melis wrote:
> Hi all,
>
Hi Stijn,

> I am in the process of fixing the design flaw in the SSTELNET MP. To get 
> you up to date, I'll do a quick explanation of the problem first:
>
> When executing some commands on both a Juniper and a Cisco router, the 
> parameters which need to be entered by the user are different. So if you 
> query both of them in the Looking Glass, you would have to type different 
> paramaters for the different devices, which isn't possible, and which also 
> goes against the whole idea of the Looking Glass itself.
>
> This was first noticed with commands which need a fixed phrase at the end 
> of the command. For example:
>
> the IP_BGP_NEIGHBOUR_ADVERTISED command on Cisco is the following:
>
> show ip bgp neighbor <ip address> advertised-routes
>
> while on Juniper it is this:
>
> show route advertising-protocol bgp <ip address>
>
> The MP treats the "advertised-routes" on the Cisco command as a parameter 
> as well, so if you want to perform this command on Cisco you would have to 
> type e.g. "157.193.214.243 advertised-routes" as a parameter, while on 
> Juniper you could just type "157.193.214.243".
>
> There are some other commands which have this same problem, but I fixed 
> this already (those are the ones marked in yellow in the excel file).
>
> However, when looking through the command list, I noticed some other 
> commands which expect a different parameter in Cisco than in Juniper 
> (marked in red in the excel file).
>
> These can be split into two groups: in one group, the Cisco command expects 
> a parameter (mostly an IP address), while on Juniper it doesn't. An example 
> of this is the IPv6_ROUTE command. On Cisco it is the following:
>
> show IPv6 route <IPv6 address>
>
> while on Juniper it is this:
>
> show route table inet6
>
> Maybe these Cisco commands give a response without a parameter as well, but 
> I'm not sure about that. Could someone shed some light on this, please?
On all of the red cases, the arguments specified for cisco are
optional "qualifiers", and I believe the same happens for the Juniper
ones. So on your example above, the actual equivalent for the juniper
command in cisco is "show IPv6 route", and passing the IPv6 address
would just narrow the information to that specific address.

> Either way, this could be fixed by not using the parameter for the Juniper 
> command, and  maybe adding a note to the response saying that the parameter 
> wasn't used.
>
> The other group has either a different syntax, or one or more parameters. 
> For example, the IPv6_MULTICAST_BGP_TABLE command on Cisco is the following:
>
> show bgp IPv6 multicast <IPv6-prefix/prefix-length>
>
> while on Juniper it is:
>
> show route protocol bgp table inet6.2 <IPv6-prefix>[<prefix-length>]
>
Are you sure this is the actual syntax for the Juniper command? I was
under the impression Juniper also used the "IPv6-prefix/prefix-length"
syntax (I don't have access to a Juniper right now to test it).

I can see this also happens for Cisco in the commands list:
"show bgp IPv6 unicast <IPv6 prefix network> [<length>]" is actually
<network>/<length>, so I believe the syntax for the parameter is the
same for the Juniper equivalent...

Hope that helps,

Guilherme

> The problem here lies within the fact that the user can enter his 
> parameters using either syntax, so it's a bit difficult to parse this. A 
> possible solution would be to define a common syntax for these parameters, 
> and then change this to the needed syntax when sending the command to the 
> device. However, this would require a lot of hardcoded info in the MP with 
> regards to the commands, and I would prefer to keep that to a minimum 
> (otherwise I'd have to change the source code for the MP every time 
> something changes about the commands).
> Does anyone have any ideas about this, or do I keep this as it is at the 
> moment (the last group that is, the rest is easy to fix)?
>
> Cheers,
>
> Stijn