[Xorp-hackers] BGP show tools
Pavlin Radoslavov
pavlin at icir.org
Thu Jun 8 11:41:34 PDT 2006
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
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
More information about the Xorp-hackers
mailing list