[Xorp-hackers] BGP show tools
Kristian Larsson
kristian at spritelink.se
Thu Jun 8 12:51:34 PDT 2006
On Thu, Jun 08, 2006 at 11:41:34AM -0700, Pavlin Radoslavov wrote:
> Kristian,
>
> In general I like your proposal. I've added it to Bugzilla, so the
> info is not lost:
> http://www.xorp.org/bugzilla/show_bug.cgi?id=634
There's actually already a bug open for this and
by coincidence I opened it ;)
http://www.xorp.org/bugzilla/show_bug.cgi?id=217
I'm closing 634 and adding the info to 217. Hope
you don't mind :)
I've also added lot of the email conversations
back and forth.
I would be very interested in hearing how you
would like the tool to be written, just roughly
outlined and I'll see what I can come up with =)
Regards,
Kristian.
>
> Pavlin
>
> Kristian Larsson <kristian at spritelink.se> wrote:
>
> > I sent a mail some time ago about new format for
> > the `show bgp *`commands.. I've thought of it a
> > bit more and I would like to suggest the following
> >
> > me at mybox> show bgp peers ?
> > Possible completions:
> > <[Enter]> Execute this command
> > <AsNum> Show BGP peers with <AsNum>
> > <IP> Show BGP peer with <IP>
> >
> > me at mybox> show bgp peers
> > Total Paths Active Paths Damped Paths Paths with Penalties
> > 220568 183521 12 4
> >
> > Peer ASN Flaps Time Accepted Filtered Sent Out
> > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23
> > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down
> > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921
> > 217.10.127.17 39525 0 00:12:43 182145 0 23 0
> > 217.10.127.19 39525 0 00:11:38 182145 0 23 0
> > 2001:6E8:1:3:2:2:3:1
> > 39525 214 12w,5d,12:44:22 182213 0 23 0
> >
> > me at mybox> show bgp peers 39525
> > Peer ASN Flaps Time Accepted Filtered Sent Out
> > 217.10.127.17 39525 0 00:12:43 182145 0 23 0
> > 217.10.127.19 39525 0 00:11:38 182145 0 23 0
> >
> > me at mybox> show bgp peers 123.123.123.123
> > Peer ASN Flaps Time Accepted Filtered Sent Out
> > 123.123.123.123 12345 1028 0w,0d,0:0:43 *183521 12 8 15
> >
> >
> > The first field with the IP address of the neighbor can take the "longest" IPv4
> > addresses, ie one where all octets contain three digits. ASN (perhaps we should
> > use 'AsNum' instead?) allow the full 2byte numbers we have today.
> > Flaps is just the number of times the session has gone to established (as it is
> > called now). Time is the time since the session went to its current state.
> > The four last fields are accepted prefixes, filtered prefixes, sent prefixes and
> > outgoing prefixes. When a session is in established state these are shown, if
> > we're in another state the state is shown instead, just as in the above example.
> >
> > Accepted prefixes is pretty self explanatory.. it is the number of prefixes you
> > have received and that has passed all route-maps and filters. Filtered are those
> > that didn't quite make it due to some filter.
> > Sent prefixes are the amount of prefixes that you have sent to a peer.
> > Out is the amount of prefixes you intend to send to a peer. It's kind of
> > dual-purpose.. you can see the equivalent of the Out queue on a Cisco, ie if there
> > are any packets you need to send to keep your neighbor updated. And when the
> > session isn't up yet you can still see how many prefixes your router intends to
> > send. Great for a quick lock - "ah, my router intends to send 23 routes... that's
> > just my customer and internal routes" so that you dont't accidentally send a full
> > table to a peer or the alike.
> >
> > The asterisk (*) in the last example signifies that the router is working, ie the
> > In queue is not empty. Having a separate field for InQ seems to overdo it, the
> > asterisk is enough...
> >
> > Now some considerations.. what of IPv4 unicast, IPv4 multicast, IPv6 unicast and
> > IPv6 multicast. Should everything be displayed under one "summary" display
> > or should we have separate displays - compare to ciscos
> > `show ip bgp ipv4 multicast summary`...
> >
> > What do we do with IPv6 adresses that are to long to fit (which should be most of
> > them) or when 4 byte AS number are implemented (RIPE has a proposal so it's not
> > that far in the future)??
> > Both these scenarios would mean longer lines than 80 chars. If xorpsh is aware of
> > the term width it's not a problem. Ff the user uses a terminal wider than 80 chars
> > we'll simply use the current width to fit as much information as possible. I think
> > this is quite common today, but not common enough to completely scrap the 80wide
> > limit and if someone would use say a 100 wide terminal that might still not be
> > enough. So we need some rules for wrapping...
> > too long IPv6 address, pretty easy case:
> > We'll do it like this, just as in the above example
> > 2001:6E8:1:3:2:2:3:1
> > 39525 214 12w,5d,12:44:22 182213 0 23 0
> > Comments please.
> >
> > Then there are 4 bytes ASNs, even though I don't think there's actually any
> > standard on this yet, there are some proposals
> > http://www.ripe.net/ripe/policies/proposals/2005-12.html for one. It seems likely
> > that the model in that url will be the one commonly accepted and so when redesigning
> > these tools we might as well take that draft into consideration.
> > When doing IPv4 and 4 bytes ASN longer than 6 digits I suggest the following:
> > 123.123.123.123 65535.65535
> > 214 12w,5d,12:44:22 182213 0 23 0
> > With both long IPv6 addresses and 4 bytes ASNs longer than 6 digits it becomes a bit
> > trickier... I find the following the best utilization of space.
> > 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535
> > 214 12w,5d,12:44:22 182213 0 23 0
> > However it becomes a tad harder placing descriptions over this when there's 'mixed'
> > output...
> >
> > me at mybox> show bgp peers
> > Total Paths Active Paths Damped Paths Paths with Penalties
> > 220568 183521 12 4
> >
> > (Peer) (ASN)
> > (Peer) (ASN) Flaps Time Accepted Filtered Sent Out
> > 53.123.53.25 34853 0 0w,1d,03:45:23 Active (retry in 67s) 23
> > 87.13.214.1 4834 0 0w,4d,06:23:57 Admin Down
> > 123.123.123.123 12345 1028 100w,5d,12:23:54 183521 126051 183521 153921
> > 2000:2000:1234:DEAD:BEEF:1234:AAAA 65535.65535
> > 214 12w,5d,12:44:22 182213 0 23 0
> > This is not very clear at all, but considering the alternatives I think it is the
> > best we an achieve and as I stated before I don't think we should wrap lines if
> > the users terminal is wide enough to fit all information on one line. This ofcourse
> > requires that xorpsh is aware of the term width.
> >
> > Please leave some comments on this.
> >
> > Last time I spoke to Atanu about this he didn't like the code in the BGP show tools
> > and so they need to be rewritten, I will give it a shot but with my far from
> > perfect C skills I expect the code to be pretty ugly. If anyone wants to help out
> > you are welcome.
> >
> > Thank you
> > Regards,
> >
> > --
> > Kristian Larsson KLL-RIPE
> > IPv6 & Peering coordinator SpriteLink [AS39525]
> > +46 704 910401 kristian at spritelink.se
> >
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
--
Kristian Larsson KLL-RIPE
IPv6 & Peering coordinator SpriteLink [AS39525]
+46 704 910401 kristian at spritelink.se
More information about the Xorp-hackers
mailing list