perfsonar development work

[Stijn Melis <>]

Hi Alessandro,

thanks a lot for this. This actually fixes my problem without the need 
to change the JAVA code, so this is everything I could hope for :D

I will update the command list as soon as possible (probably later today).

Cheers,

Stijn

Alessandro Inzerilli wrote:
> Hi Stijn and all,
>
> since I'm responsible for having compiled the list with most of the 
> controversial commands
> I modified the complete list to try to solve the issues you raised. Of 
> course this a proposal. Tell me if this sounds reasonable to you. The 
> idea behind is to simplify as much as possible parameter usage.
>
> Of course Juniper and Cisco CLI command syntax is similar but not 
> exactly the same. In most cases you can find two pretty equivalent 
> commands, but in some other is quite difficult. Sometimes you have 
> equivalent commands, which take slightly different parameters. For 
> example in some Cisco commands the prefix-length parameter is not 
> allowed, while it is allowed and optional in Juniper ones.
>
> So, while the following two commands are both valid on juniper,:
> /show route 10.0.0.0/24 or show route 10.0.0.1/
> you can only use
> /show ip route 10.0.0.0 or show ip route 10.0.0.1 /
> on Cisco routers , while the commands
> /show ip route 10.0.0.0/24 /
> gives you a syntax error.
>
> I can understand why this can result in some confusion... :-)
>
>
> Now I'll explain the changes I made to the file command by command. The 
> final result in all cases is that the number and type of  parameters in 
> the final commands (column 2 e 4) are the same.
>
>
> 1
>         2
>         3
>         4
>         5
> (1) Cisco Commands
> (Original)
>         Cisco Command (Final)
>         Juniper Command (Original)
>         Juniper Command (Final)
>         Explanation
> show ip ospf database external <ip address> 	show ip ospf database 
> external 	show ospf database extern 	 no changes
> 	Since the <ip addess> parameter is optional on cisco, we can remove it. 
> It doesn't make a big difference since the DB normally is limited
> show ip route <ip address>
>         no changes
> 	show route <prefix> /[<length>] 	show route <ip address> 	The commands 
> "show ip route" and "show  route" can be both issued without parameters, 
> which is btw not good because that way they will show all the router 
> routing table, that can be quite long. So I made the <ip addess> 
> required and took off the prefix length which is optional only on juniper.
> show IPv6 route <IPv6 address>    no changes
> 	show route table inet6 	show route <IPv6 address> 	The command "show 
> route table inet6 " on Juniper restricts the search only to the IPv6 
> routing table. While the generic "show route" looks into all routing 
> tables. Since "show route" works also with ipv6 address, I used it to 
> simplify things. As in the previous case, the parameter was made 
> required to limit the output.
> show bgp IPv6 unicast <IPv6 prefix > [<length>] 	show bgp IPv6 unicast 
> <IPv6 prefix /length> 	show route protocol bgp table inet6 <IPv6 prefix 
> /length>
>         no changes
> 	There was a mistake in cisco syntax. It was missing a "/" and the 
> "prefix length" is required. I made the lentgh required so that the two 
> commands are now the same.
> show bgp IPv6 multicast <IPv6 prefix/length>
>         no changes
> 	show route protocol bgp table inet6.2 <IPv6-prefix>[<prefix-length>] 
> show route protocol bgp table inet6.2 <IPv6-prefix/length> 	Even if 
> "length" is optional on Juniper, It was made required to be conform to 
> the cisco one.
> show IPv6 mroute <IPv6 address>   show IPv6 mroute
> 	show multicast route inet6  <IPv6-prefix/prefix-length> 	show multicast 
> route inet6
>         Removed optional <ipv6 prefix/length> to conform to ipv4 version
> show IPv6 rpf <IPv6-prefix>       no changes
>         show multicast rpf inet6 <IPv6-prefix>[<prefix-length>]
>         show multicast rpf inet6 <IPv6-prefix>
> 	Removed optional < prefix-length> on Juniper command to conform to 
> cisco one
>
>
> You'll find attached the modified complete list of commands.
> Hope this can be of help.
>
> Alessandro
>
> ------------------------------------------------
>              Alessandro Inzerilli
>
>                CONSORTIUM GARR
>     The Italian Academic and Research Network
>
> Phone   +39 06 49622562
> Fax     +39 06 49622044
> E-mail  
>
> Skype   alessandroinzerilli
> ------------------------------------------------
>
>
>
> Guilherme Fernandes wrote:
> > 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
> > >