Guys, I couldn't identify which merge commit introduced this regression. I then came to realize that our git history is becoming unnecessarily way too hard to follow. Wouldn't it be better if we start avoiding merge commits? In other words, whenever we want to merge a branch, rebase it on top of the base branch before. Then we get a clean fast-forward merge and a commit history that is easy to follow. I think we could do this at least for small branches like -isis-simpl which had only two simple commits. A merge commit for that was unnecessary IMO. On Thu, Dec 8, 2016 at 10:04 PM, Renato Westphal <renato@opensourcerouting.org> wrote:
Signed-off-by: Renato Westphal <renato@opensourcerouting.org> --- zebra/zebra_vty.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
diff --git a/zebra/zebra_vty.c b/zebra/zebra_vty.c index f32b51f..bde9431 100644 --- a/zebra/zebra_vty.c +++ b/zebra/zebra_vty.c @@ -918,6 +918,15 @@ vty_show_ip_route_detail (struct vty *vty, struct route_node *rn, int mcast) default: break; } + + /* Label information */ + if (nexthop->nh_label && nexthop->nh_label->num_labels) + { + vty_out (vty, " label %s", + mpls_label2str (nexthop->nh_label->num_labels, + nexthop->nh_label->label, buf, BUFSIZ)); + } + vty_out (vty, "%s", VTY_NEWLINE); } vty_out (vty, "%s", VTY_NEWLINE); @@ -1158,6 +1167,14 @@ vty_show_ip_route (struct vty *vty, struct route_node *rn, struct rib *rib, break; }
+ /* Label information */ + if (nexthop->nh_label && nexthop->nh_label->num_labels) + { + vty_out (vty, " label %s", + mpls_label2str (nexthop->nh_label->num_labels, + nexthop->nh_label->label, buf, BUFSIZ)); + } + if (CHECK_FLAG (rib->flags, ZEBRA_FLAG_BLACKHOLE)) vty_out (vty, ", bh"); if (CHECK_FLAG (rib->flags, ZEBRA_FLAG_REJECT)) -- 1.9.1
-- Renato Westphal