)]}'
{
  "commit": "64e0ac29ddc43bb5b1a2999a8ebedbdff115e3ca",
  "tree": "00f5d62575cbc5eb4744179e21bf1ac5ccb63f55",
  "parents": [
    "76764ddcf53fa4840993c395fdf383a47ad61e8e"
  ],
  "author": {
    "name": "Paul Jakma",
    "email": "paul.jakma@hpe.com",
    "time": "Wed Nov 18 16:00:54 2015 +0000"
  },
  "committer": {
    "name": "Donald Sharp",
    "email": "sharpd@cumulusnetworks.com",
    "time": "Tue Dec 08 14:16:24 2015 -0500"
  },
  "message": "bgpd: Implicit updates in BGP may require a withdrawal from zebra RIB\n\n*  J Yu \u003cjackiesyu@hotmail.com\u003e noted a problem with bgpd of routes not\n   having their nexthop updated correctly.\n\n   Martin Winter \u003cmwinter@opensourcerouting.org\u003e pinned this down to the\n   case where a BGP route is updated from one with a valid nexthop to an\n   invalid next-hop, using a test tool. Once the problem occurs, the incorrect\n   route may remain, even after further UPDATEs, so long as the nexthop in the\n   zebra RIB does not match the BGP route\u0027s nexthop.\n\n   Jacqueline Yu then pinned the issue down further to being due to bgpd\n   sending the DELETE for the route to zebra with the new nexthop after a\n   BGP UPDATE updates an existing route, but then is found to be invalid,\n   and zebra not finding the route as it requires a match on all attributes.\n\n* bgp_zebra.c: (bgp_zebra_withdraw) When deleting a prefix, we want it gone.\n  Do not send additional matching attributes like the nexthop, which can\n  only cause incorrect non-matches.\nAcked-by: Donald Sharp \u003csharpd@cumulusnetworks.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e534bee86dddb9aaeb8bc3fa0447b5bb13b2428b",
      "old_mode": 33188,
      "old_path": "bgpd/bgp_zebra.c",
      "new_id": "186657bd8b22e7df1fe501c2c319075e20621127",
      "new_mode": 33188,
      "new_path": "bgpd/bgp_zebra.c"
    }
  ]
}