Mailing List Archive

>
> A) there should be an auto-refreshing "sh ip bgp summary" - it is really
> annying to type it again and again and again...
> Ok.. This is not cisco-compliant, but we could introduce "sh ip bgp su
> reloading" or something like that.
>

Getting a "top"-like interface would be useful in a lot of situations,
so please use a common keyword for it.

like:

sh ip bgp summary top
sh ip bgp neighbor x.x.x.x routes top
sh ip ospf neighbor top

and so on. That way you know what you'll get when you
? your way through the commands.

/Tony S

> Getting a "top"-like interface would be useful in a lot of
> situations, so please use a common keyword for it.
>
> like:
>
> sh ip bgp summary top
> sh ip bgp neighbor x.x.x.x routes top
> sh ip ospf neighbor top

Hi Tony,

Yeah - top reminds me of auto-refreshing and is a good name but maybe
auto-refresh is a better name since
people know what it means :-)
Oh.. But top is shorter. What do the others think?

Anyway... We need this feature, agreed?

Gunther

> Getting a "top"-like interface would be useful in a lot of
> situations, so please use a common keyword for it.
>
> like:
>
> sh ip bgp summary top
> sh ip bgp neighbor x.x.x.x routes top
> sh ip ospf neighbor top

Hi Tony,

Yeah - top reminds me of auto-refreshing and is a good name but maybe
auto-refresh is a better name since
people know what it means :-)
Oh.. But top is shorter. What do the others think?

Anyway... We need this feature, agreed?

Gunther

----- Original Message -----
From: "Gunther Stammwitz" <gstammw@gmx.net>
To: "'Tony Sarendal'" <tsar@polarcap.org>
Cc: <quagga-dev@lists.quagga.net>
Sent: Monday, August 04, 2003 7:51 PM
Subject: [quagga-dev 36] AW: Re: Idea for new features (bgp-daemon)


> > Getting a "top"-like interface would be useful in a lot of
> > situations, so please use a common keyword for it.
> >
> > like:
> >
> > sh ip bgp summary top
> > sh ip bgp neighbor x.x.x.x routes top
> > sh ip ospf neighbor top
>
> Hi Tony,
>
> Yeah - top reminds me of auto-refreshing and is a good name but maybe
> auto-refresh is a better name since
> people know what it means :-)
> Oh.. But top is shorter. What do the others think?
>
> Anyway... We need this feature, agreed?
>

Sounds like a nice idea, but I fear what it will do on my box with 160
neighbors...
With <25 lines it's nice to see this kind of info, when it's (a lot) more,
it won't be.

What I'd like to see (and I'm somewhat working on right now) is applying
some
kind of filters on the output of 'show ip bgp summary', so I can filter on
stuff like:
* link state
* peer group
* number of prefixes received
* AS number
* IP number
etc.


Teun Vink
Luna.nl NOC

>>>Getting a "top"-like interface would be useful in a lot of
>>>situations, so please use a common keyword for it.

>
> Sounds like a nice idea, but I fear what it will do on my box with 160
> neighbors...
> With <25 lines it's nice to see this kind of info, when it's (a lot) more,
> it won't be.
>

Make it behave like regular top, with commands and all.
If you only have a 24 line terminal you only get 24 lines.

> What I'd like to see (and I'm somewhat working on right now) is applying
> some
> kind of filters on the output of 'show ip bgp summary', so I can filter on
> stuff like:
> * link state
> * peer group
> * number of prefixes received
> * AS number
> * IP number
> etc.
>

If we make it behave like top we can simply add some commands to
regexp the output, only show x lines, sort in different orders
and so on.

Implement it in a nice way so it's easy to add views anywhere
it would be useful, maybe even use existing top code.

/Tony S

> What I'd like to see (and I'm somewhat working on right now)
> is applying some kind of filters on the output of 'show ip
> bgp summary', so I can filter on stuff like:
> * link state
> * peer group
> * number of prefixes received
> * AS number
> * IP number
> etc.

Hi Teun,

You are right.
It would be especially cool if one could "grep" and so.

Gunther

On Mon, 4 Aug 2003, Gunther Stammwitz wrote:

> Yeah - top reminds me of auto-refreshing and is a good name but
> maybe auto-refresh is a better name since people know what it means
> :-) Oh.. But top is shorter. What do the others think?
>
> Anyway... We need this feature, agreed?

how about making use of the snmp smux capability of bgpd and using
some existing snmp app to poll for neighbour status (eg mrtg)?

seems what the person wants can already be done - if he looks beyond
the bgpd vty.

> Gunther

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Support bacteria -- it's the only culture some people have!

----- Original Message -----
From: "Gunther Stammwitz" <gstammw@gmx.net>
To: "'Teun Vink'" <teun@moonblade.net>; "'Tony Sarendal'"
<tsar@polarcap.org>
Cc: <quagga-dev@lists.quagga.net>
Sent: Monday, August 04, 2003 8:59 PM
Subject: AW: [quagga-dev 36] AW: Re: Idea for new features (bgp-daemon)


>
> > What I'd like to see (and I'm somewhat working on right now)
> > is applying some kind of filters on the output of 'show ip
> > bgp summary', so I can filter on stuff like:
> > * link state
> > * peer group
> > * number of prefixes received
> > * AS number
> > * IP number
> > etc.
>
> Hi Teun,
>
> You are right.
> It would be especially cool if one could "grep" and so.
>
> Gunther
>
>

Right, I'll see what I can do!

Teun

Paul Jakma wrote:

>>Yeah - top reminds me of auto-refreshing and is a good name but
>>maybe auto-refresh is a better name since people know what it means
>>:-) Oh.. But top is shorter. What do the others think?
>>
>>Anyway... We need this feature, agreed?
>
>
> how about making use of the snmp smux capability of bgpd and using
> some existing snmp app to poll for neighbour status (eg mrtg)?
>
> seems what the person wants can already be done - if he looks beyond
> the bgpd vty.

I'll double that.

Building a simple script to provide top-like functionality (including
filtering, paging, etc), at any frequency, is much simpler, and IMO it's
way more natural to reside outside bgpd/ospfd/anyd. Paul suggested SNMP,
I'd say it's even simpler to do with vty-parsers, like Tcl/Expect.

(If you'd like that, I think I can provide a general framework for this
kind of functionality.)

And, I wouldn't hurry to extend the VTY functionality in such manner.

Gilad

It was proposed before on zebra mailing list to have another column in
the output of "show ip bgp summary" with the description of the
neighbor. I think this is useful and trivial to implement.


Gunther Stammwitz (Mainlab GmbH) wrote:
> Hello Quagga-Developers,
>
> During the daily use of the bgp-feature of zebra/quagga I've noticed that
> two cool features are missing:
>
> A) there should be an auto-refreshing "sh ip bgp summary" - it is really
> annying to type it again and again and again...
> Ok.. This is not cisco-compliant, but we could introduce "sh ip bgp su
> reloading" or something like that.
>
> B) it would be interesting to see which paths are actually running over a
> specific peer. At the moment you have to do a "sh ip bgp" and (somehow) grep
> it for your neighbors ip or do it on kernel-level. That's stupid...
>
> C) Maybe a defined interface to monitoring-systems like nagios could be
> really useful if you'd like to monitor if one of your session went down or
> if you are receiving too less/many prefixes or so.
>
> What do the others think ?
>
> Regards,
> Gunther
>
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev
>


--
Bogdan Zapca
Romania Data Systems NOC in Bucharest
Network Engineer
Phone: +40 21 30 10 888
Fax: +40 21 30 10 851
==------------------------------------------------------------------------==
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver
this message
to anyone. In such a case, you should destroy this message and kindly
notify the sender by reply e-mail.
==------------------------------------------------------------------------==

On Tue, 2003-08-05 at 12:10, Bogdan Zapca wrote:
> It was proposed before on zebra mailing list to have another column in
> the output of "show ip bgp summary" with the description of the
> neighbor. I think this is useful and trivial to implement.
>

Yes, this is quite easy to implement. It's one of the things I've been
toying with. Personally, I'd like to see something similar, but I'd like
to see the peer-group in which a neighbor is placed.


Teun

Paul, Gilad,

I think that we should start thinking of devices that run quagga as
appliances, which means we should assume the user only has access to the
CLI. Anything that will assist with trouble shooting and verification of
operation should be availble via the CLI.

With that in mind I think I would find a 'auto-refresh' option
useful when I'm in the midst of trouble shooting.

Juniper and Extreme have something like this (only for specific commands)
and it comes in very handy.

--
James R. Leu

On Tue, Aug 05, 2003 at 12:47:58PM +0300, Gilad Arnold wrote:
>
> Paul Jakma wrote:
>
> >>Yeah - top reminds me of auto-refreshing and is a good name but
> >>maybe auto-refresh is a better name since people know what it means
> >>:-) Oh.. But top is shorter. What do the others think?
> >>
> >>Anyway... We need this feature, agreed?
> >
> >
> > how about making use of the snmp smux capability of bgpd and using
> > some existing snmp app to poll for neighbour status (eg mrtg)?
> >
> > seems what the person wants can already be done - if he looks beyond
> > the bgpd vty.
>
> I'll double that.
>
> Building a simple script to provide top-like functionality (including
> filtering, paging, etc), at any frequency, is much simpler, and IMO it's
> way more natural to reside outside bgpd/ospfd/anyd. Paul suggested SNMP,
> I'd say it's even simpler to do with vty-parsers, like Tcl/Expect.
>
> (If you'd like that, I think I can provide a general framework for this
> kind of functionality.)
>
> And, I wouldn't hurry to extend the VTY functionality in such manner.
>
> Gilad
>
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev

James R. Leu wrote:

> I think that we should start thinking of devices that run quagga as
> appliances, which means we should assume the user only has access to the
> CLI. Anything that will assist with trouble shooting and verification of
> operation should be availble via the CLI.

Sure, no problem. How would you do 'auto-refresh' with Cisco? Naturally,
you'd write (or otherwise get your hands on) some Tcl/Expect script,
that remotely accesses you box and does exactly that: IMO, it's more
flexible and adjustable, you could port your monitored data to whatever
form you like, and so on. I'm not so sure it has to be part of the CLI.

(Note, that this is totally departed from debugging messages, which are
triggered events -- you're talking about some polling mechanism,
top-like, right?)

> Juniper and Extreme have something like this (only for specific commands)
> and it comes in very handy.

Don't know about those. At least for what was described in this thread,
I don't think this extension to vty provides something you couldn't get
right now, and quite easily. Therefore I doubt it's being worthwhile
(but of course, I'm not a user, so take this limited).

Gilad

Then here it is. It adds a "Description/Peer-group" column to "sh ip bgp
su".


Teun Vink wrote:
> On Tue, 2003-08-05 at 12:10, Bogdan Zapca wrote:
>
>>It was proposed before on zebra mailing list to have another column in
>>the output of "show ip bgp summary" with the description of the
>>neighbor. I think this is useful and trivial to implement.
>>
>
>
> Yes, this is quite easy to implement. It's one of the things I've been
> toying with. Personally, I'd like to see something similar, but I'd like
> to see the peer-group in which a neighbor is placed.
>
>
> Teun
>
>


--
Bogdan Zapca
Romania Data Systems NOC in Bucharest
Network Engineer
Phone: +40 21 30 10 888
Fax: +40 21 30 10 851
==------------------------------------------------------------------------==
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver
this message
to anyone. In such a case, you should destroy this message and kindly
notify the sender by reply e-mail.
==------------------------------------------------------------------------==

On Wed, 6 Aug 2003, James R. Leu wrote:

> That is assuming I have remote access to the box when I'm doing
> trouble shooting. If the network is melting down due to BGP I may
> have to do the 'telnet hop' to get to the problem router. Once
> there, and I'm on the CLI, I want all of the tools at my disposal.
> An 'auto-refresh' of some BGP commands (or other 'show' commands)
> might be useful.

Hmm... if you're still fixing a problem, you're not needing
auto-refresh. Auto-refresh implies you've gotten to the "i think i've
fixed it, lets observe" stage, at which point you presumably have
routing working to the website where your mrtg/some-other-snmp-thingy
lives.

anyway, doing auto-refresh in vty would be difficult, and ugly.

OTOH, doing it in a client would be easier. Eg vtysh.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
BASIC is to computer programming as QWERTY is to typing.
-- Seymour Papert

Hey Bogdan,

Great work. I'm going to check your patch this evening - but it sounds
great.

Bye,
Gunther


> -----Ursprüngliche Nachricht-----
> Von: quagga-dev-bounces@lists.quagga.net
> [mailto:quagga-dev-bounces@lists.quagga.net] Im Auftrag von
> Bogdan Zapca
> Gesendet: Mittwoch, 6. August 2003 16:38
> An: Teun Vink
> Cc: quagga-dev@lists.quagga.net
> Betreff: [quagga-dev 105] Re: Idea for new features (bgp-daemon)
>
>
> Then here it is. It adds a "Description/Peer-group" column to
> "sh ip bgp su".
>
>
> Teun Vink wrote:
> > On Tue, 2003-08-05 at 12:10, Bogdan Zapca wrote:
> >
> >>It was proposed before on zebra mailing list to have
> another column in >>the output of "show ip bgp summary" with
> the description of the >>neighbor. I think this is useful
> and trivial to implement. >> > > > Yes, this is quite
> easy to implement. It's one of the things I've been > toying
> with. Personally, I'd like to see something similar, but I'd
> like > to see the peer-group in which a neighbor is placed.
> > > > Teun > >
>
>
> --
> Bogdan Zapca
> Romania Data Systems NOC in Bucharest
> Network Engineer
> Phone: +40 21 30 10 888
> Fax: +40 21 30 10 851
> ==------------------------------------------------------------
> ------------==
> Privileged/Confidential Information may be contained in this
> message. If you are not the addressee indicated in this
> message (or responsible for delivery of the message to such
> person), you may not copy or deliver this message to anyone.
> In such a case, you should destroy this message and kindly
> notify the sender by reply e-mail.
> ==------------------------------------------------------------
> ------------==
>
>

--On Wednesday, August 6, 2003 10:22 am -0500 "James R. Leu"
<jleu@mindspring.com> wrote:

> That is assuming I have remote access to the box when I'm doing
> trouble shooting. If the network is melting down due to BGP I may have to
> do the 'telnet hop' to get to the problem router. Once there, and I'm
> on the CLI, I want all of the tools at my disposal. An 'auto-refresh' of
> some BGP commands (or other 'show' commands) might be useful.

The best way to do this, in my view - would be to hack the vty and parser
to allow something like 'repeat n show ip bgp sum' where n is the period in
seconds perhaps. Perhaps no question mark surfing after the 'repeat' as
adding that would be hard, I imagine. Only allow non-config commands.

Rick

On Tue, Aug 05, 2003 at 03:22:19PM +0200, Teun Vink wrote:
> On Tue, 2003-08-05 at 12:10, Bogdan Zapca wrote:
> > It was proposed before on zebra mailing list to have another column in
> > the output of "show ip bgp summary" with the description of the
> > neighbor. I think this is useful and trivial to implement.
> >
>
> Yes, this is quite easy to implement. It's one of the things I've been
> toying with. Personally, I'd like to see something similar, but I'd like
> to see the peer-group in which a neighbor is placed.

Can I make the suggestion that the existing reports be left alone, and
if extra information is required, it's put into a new report?

Perhaps:

Router> show ip bgp summary
and
Router> show ip bgp extended-summary

would do in this particular case.

The reason I'd like to see things done this way is that I've got a
pile of code that reads these reports, and I'd rather not be
constantly chasing Quagga's output formats.


Chris.

On Wed, 2003-08-06 at 16:54, Chris Andrews wrote:
> On Tue, Aug 05, 2003 at 03:22:19PM +0200, Teun Vink wrote:
> > On Tue, 2003-08-05 at 12:10, Bogdan Zapca wrote:
> > > It was proposed before on zebra mailing list to have another column in
> > > the output of "show ip bgp summary" with the description of the
> > > neighbor. I think this is useful and trivial to implement.
> > >
> >
> > Yes, this is quite easy to implement. It's one of the things I've been
> > toying with. Personally, I'd like to see something similar, but I'd like
> > to see the peer-group in which a neighbor is placed.
>
> Can I make the suggestion that the existing reports be left alone, and
> if extra information is required, it's put into a new report?
>
> Perhaps:
>
> Router> show ip bgp summary
> and
> Router> show ip bgp extended-summary
>
> would do in this particular case.
>
> The reason I'd like to see things done this way is that I've got a
> pile of code that reads these reports, and I'd rather not be
> constantly chasing Quagga's output formats.


That was my idea as well. Another way to do it would be:

"show ip bgp summary" shows you the 'normal' summary
"show ip bgp summary extended" shows you extra info like descriptions,
peergroups, etc.

I also want to make a _really_ short summary at the end, indicating the
number of neighbors per state (x neighbors in established, y active, z
connect, etc). This is very on boxes with lots of neighbors (like mine).

I've been testing some filters too, pretty naive stuff for now, no fancy
regexp stuff (still got to look into that), things like:

show ip bgp summary state neq established (show all neighbors not in
state 'established')
show ip bgp summary prefixes eq 0 (show all neighbors sending me 0
prefixes)


Teun

On Wed, 6 Aug 2003, Bogdan Zapca wrote:

> Then here it is. It adds a "Description/Peer-group" column to "sh ip bgp
> su".

err.. is your patch reversed? it seems to want to remove a
Description column :)

seems a good idea - but will it still all fit within a 80 char wide
terminal?

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
There are worse things in life than death. Have you ever spent an evening
with an insurance salesman?
-- Woody Allen

Rick Payne wrote:

> The best way to do this, in my view - would be to hack the vty and
> parser to allow something like 'repeat n show ip bgp sum' where n is the
> period in seconds perhaps. Perhaps no question mark surfing after the
> 'repeat' as adding that would be hard, I imagine. Only allow non-config
> commands.

Sounds puzzling to me: does this mean that vty is blocked during those
'repeat' sessions? (probably so, otherwise you can't stop those chains,
but OTOH you wouldn't want it to block the whole process) How do you
break a chain of repeated commands? How do you cope with paging? (if at
all, probably not I guess, but that means extra hacking)

I would say, if this is really a nice-to-have feature, to open a new
category of 'debug' command, such that call for an initiated report
every x seconds. This way, it's asynchronuous by most means (your vty
isn't blocked, it just triggers a repeated timer event and returns
control to you), your process keeps running as usual, the only
difference is that every once in a while you get a mass of report lines.
Minimal hacking required. (The output stream needs to be considered
here, though, probably it will be the logfile, as any other debug
message, but then again this could be set to be the stdout.)

My 0.02 NIS (that's what I got ;->)
Gilad

On Wed, Aug 06, 2003 at 11:19:04AM +0300, Gilad Arnold wrote:
>
> James R. Leu wrote:
>
> > I think that we should start thinking of devices that run quagga as
> > appliances, which means we should assume the user only has access to the
> > CLI. Anything that will assist with trouble shooting and verification of
> > operation should be availble via the CLI.
>
> Sure, no problem. How would you do 'auto-refresh' with Cisco? Naturally,
> you'd write (or otherwise get your hands on) some Tcl/Expect script,
> that remotely accesses you box and does exactly that: IMO, it's more

That is assuming I have remote access to the box when I'm doing
trouble shooting. If the network is melting down due to BGP I may have to
do the 'telnet hop' to get to the problem router. Once there, and I'm
on the CLI, I want all of the tools at my disposal. An 'auto-refresh' of
some BGP commands (or other 'show' commands) might be useful.

> flexible and adjustable, you could port your monitored data to whatever
> form you like, and so on. I'm not so sure it has to be part of the CLI.
>
> (Note, that this is totally departed from debugging messages, which are
> triggered events -- you're talking about some polling mechanism,
> top-like, right?)
>
> > Juniper and Extreme have something like this (only for specific commands)
> > and it comes in very handy.
>
> Don't know about those. At least for what was described in this thread,
> I don't think this extension to vty provides something you couldn't get
> right now, and quite easily. Therefore I doubt it's being worthwhile
> (but of course, I'm not a user, so take this limited).
>
> Gilad
>

--
James R. Leu

On Wed, 2003-08-06 at 17:17, Paul Jakma wrote:
> On Wed, 6 Aug 2003, Bogdan Zapca wrote:
>
> > Then here it is. It adds a "Description/Peer-group" column to "sh ip bgp
> > su".
>
> err.. is your patch reversed? it seems to want to remove a
> Description column :)
>
> seems a good idea - but will it still all fit within a 80 char wide
> terminal?,


Reverse diff'ing :-) at least that's what it looks like...

No, it will definately never fit in a 80 char wide terminal.
It'll depend on how long the descriptions are, but the current output
already is 80 chars wide.



Teun

I'll try not to reverse at the next diff :-D
I think that "show ip bgp summary extended" will be more appropiate -
I'm working on it.
Unfortunately, as Teun said, the current output is already 80 chars wide.

Teun Vink wrote:
> On Wed, 2003-08-06 at 17:17, Paul Jakma wrote:
>
>>On Wed, 6 Aug 2003, Bogdan Zapca wrote:
>>
>>
>>>Then here it is. It adds a "Description/Peer-group" column to "sh ip bgp
>>>su".
>>
>>err.. is your patch reversed? it seems to want to remove a
>>Description column :)
>>
>>seems a good idea - but will it still all fit within a 80 char wide
>>terminal?,
>
>
>
> Reverse diff'ing :-) at least that's what it looks like...
>
> No, it will definately never fit in a 80 char wide terminal.
> It'll depend on how long the descriptions are, but the current output
> already is 80 chars wide.
>
>
>
> Teun
>
>


--
Bogdan Zapca
Romania Data Systems NOC in Bucharest
Network Engineer
Phone: +40 21 30 10 888
Fax: +40 21 30 10 851
==------------------------------------------------------------------------==
Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver
this message
to anyone. In such a case, you should destroy this message and kindly
notify the sender by reply e-mail.
==------------------------------------------------------------------------==