[quagga-dev 13443] Re: Kernel routes does not get updated when neighbor remove the "next-hop-self" configuration

Tue, 27 Oct 2015 22:02:00 -0700

The attached “changes” file worked - but didn’t look at it as I never expected it to be a patch. 

I can confirm that this patch fixes the problem in my testbed.
I have not reviewed the patch itself. I leave this to others on the list.
The issue on the badly formatted inline patch is, that patchwork (patchwork.quagga.net) which picks up the patches from the mailing list picked up the badly formatted inline patch and ignored the attachment. Would probably be good to send an updated patch with git send-email anyway for patchwork to pick 
up the new version.

Regards,
   Martin

On 27 Oct 2015, at 16:14, J Yu wrote:
Hi Martin, I patch I sent yesterday also had an attachment which should *not* have wrapped lines and I have verified that I can apply that patch without any issue. Can you please use the attached file to my yesterday's email to apply patch? 

Thanks!


From: [email protected]
To: [email protected]
Date: Tue, 27 Oct 2015 02:46:59 -0700
CC: [email protected]; [email protected]
Subject: [quagga-dev 13438] Re: Kernel routes does not get updated when neighbor remove the "next-hop-self" configuration 

Please resend. I think this patch got corrupted by your email client.
I’ve tried to fix it by “un-wrapping” the lines, but still fail. 

(Check to make sure that it applies to latest git master and if this
works,
then please use “git send-email” to send it to list.)

Regards,
 Martin Winter


On 26 Oct 2015, at 13:43, Jacqueline Yu wrote:
Thanks Martin for adding the test case, and confirming the issue. Here 
is a
proposed change I made with diff below as well as attached --

Appreciate any comments/feedbacks...

diff --git a/bgpd/bgp_route.c b/bgpd/bgp_route.c
index 316fa5a..c424dd1 100644
--- a/bgpd/bgp_route.c
+++ b/bgpd/bgp_route.c
@@ -109,8 +109,12 @@ bgp_info_extra_free (struct bgp_info_extra
**extra)

 (*extra)->damp_info = NULL;

+      if ((*extra)->attr)
+        bgp_attr_unintern(&((*extra)->attr));
+
+      (*extra)->attr = NULL;
+
 XFREE (MTYPE_BGP_ROUTE_EXTRA, *extra);
-
 *extra = NULL;
}
}
@@ -1602,7 +1606,8 @@ bgp_process_main (struct work_queue *wq, void
*data)
struct bgp_info *old_select;
struct bgp_info_pair old_and_new;
struct listnode *node, *nnode;
-  struct peer *peer;
+  struct peer *peer, *log_peer = NULL;
+  struct attr *attr;

/* Best path selection. */
bgp_best_selection (bgp, rn, &bgp->maxpaths[afi][safi], &old_and_new); 
@@ -1638,6 +1643,8 @@ bgp_process_main (struct work_queue *wq, void
*data)
for (ALL_LIST_ELEMENTS (bgp->peer, node, nnode, peer))
{
 bgp_process_announce_selected (peer, new_select, rn, afi, safi);
+      if (log_peer == NULL)
+          log_peer = peer;
}

/* FIB update. */
@@ -1646,15 +1653,24 @@ bgp_process_main (struct work_queue *wq, void 
*data)
{
 if (new_select
&& new_select->type == ZEBRA_ROUTE_BGP
-  && new_select->sub_type == BGP_ROUTE_NORMAL)
+  && new_select->sub_type == BGP_ROUTE_NORMAL) {
bgp_zebra_announce (p, new_select, bgp, safi);
+      }
 else
{
/* Withdraw the route from the kernel. */
if (old_select
 && old_select->type == ZEBRA_ROUTE_BGP
-      && old_select->sub_type == BGP_ROUTE_NORMAL)
-    bgp_zebra_withdraw (p, old_select, safi);
+      && old_select->sub_type == BGP_ROUTE_NORMAL) {
+            if (CHECK_FLAG (old_select->flags,
BGP_INFO_NEW_NHOP_INVALID))
{
+              attr = old_select->attr;
+              old_select->attr =
(bgp_info_extra_get(old_select))->attr;
+      bgp_zebra_withdraw (p, old_select, safi);
+              old_select->attr = attr;
+            } else {
+      bgp_zebra_withdraw (p, old_select, safi);
+            }
+          }
}
}

@@ -2105,7 +2121,7 @@ bgp_update_main (struct peer *peer, struct
prefix *p,
struct attr *attr,
struct bgp *bgp;
struct attr new_attr;
struct attr_extra new_extra;
-  struct attr *attr_new;
+  struct attr *attr_new, *saved_attr;
struct bgp_info *ri;
struct bgp_info *new;
const char *reason;
@@ -2302,8 +2318,9 @@ bgp_update_main (struct peer *peer, struct
prefix *p,
struct attr *attr,
bgp_damp_withdraw (ri, rn, afi, safi, 1);
}

-      /* Update to new attribute.  */
-      bgp_attr_unintern (&ri->attr);
+      /* Update to new attribute.  Save the old attr to be freed
after we
decide
+         the new attribute has next hop that's reachable or not */
+      saved_attr = ri->attr;
 ri->attr = attr_new;

 /* Update MPLS tag.  */
@@ -2318,10 +2335,11 @@ bgp_update_main (struct peer *peer, struct
prefix
*p, struct attr *attr,
ret = bgp_damp_update (ri, rn, afi, safi);
if (ret == BGP_DAMP_SUPPRESSED)
{
-      bgp_unlock_node (rn);
-      return 0;
-    }
- }
+              bgp_attr_unintern (&saved_attr);
+              bgp_unlock_node (rn);
+              return 0;
+            }
+        }

 /* Nexthop reachability check. */
 if ((afi == AFI_IP || afi == AFI_IP6)
@@ -2331,13 +2349,26 @@ bgp_update_main (struct peer *peer, struct
prefix
*p, struct attr *attr,
 || (peer->sort == BGP_PEER_EBGP && peer->ttl != 1)
 || CHECK_FLAG (peer->flags, PEER_FLAG_DISABLE_CONNECTED_CHECK)))
{
-  if (bgp_nexthop_lookup (afi, peer, ri, NULL, NULL))
-    bgp_info_set_flag (rn, ri, BGP_INFO_VALID);
-  else
-    bgp_info_unset_flag (rn, ri, BGP_INFO_VALID);
- }
-      else
+          if (bgp_nexthop_lookup (afi, peer, ri, NULL, NULL)) {
+            bgp_info_set_flag (rn, ri, BGP_INFO_VALID);
+            bgp_attr_unintern (&saved_attr);
+ bgp_info_unset_flag (rn, ri, BGP_INFO_NEW_NHOP_INVALID); 
+          } else {
+            bgp_info_unset_flag (rn, ri, BGP_INFO_VALID);
+            bgp_info_set_flag (rn, ri, BGP_INFO_NEW_NHOP_INVALID);
+            if (!ri->extra)
+              ri->extra = bgp_info_extra_new();
+            else
+              if (ri->extra->attr)
+                bgp_attr_unintern(&(ri->extra->attr));
+            ri->extra->attr = saved_attr;
+          }
+        }
+      else {
   bgp_info_set_flag (rn, ri, BGP_INFO_VALID);
+        bgp_attr_unintern (&saved_attr);
+        bgp_info_unset_flag (rn, ri, BGP_INFO_NEW_NHOP_INVALID);
+      }

 /* Process change. */
 bgp_aggregate_increment (bgp, p, ri, afi, safi);
diff --git a/bgpd/bgp_route.h b/bgpd/bgp_route.h
index 3d2eea5..60c9b54 100644
--- a/bgpd/bgp_route.h
+++ b/bgpd/bgp_route.h
@@ -40,6 +40,9 @@ struct bgp_info_extra

/* MPLS label.  */
u_char tag[3];
+
+  /* Attribute structure. Only for invalid next hop update case  */
+  struct attr *attr;
};

struct bgp_info
@@ -82,6 +85,7 @@ struct bgp_info
#define BGP_INFO_COUNTED (1 << 10)
#define BGP_INFO_MULTIPATH      (1 << 11)
#define BGP_INFO_MULTIPATH_CHG  (1 << 12)
+#define BGP_INFO_NEW_NHOP_INVALID (1 << 13)

/* BGP route type.  This can be static, RIP, OSPF, BGP etc.  */
u_char type;


On Sat, Oct 24, 2015 at 7:50 PM, Martin Winter <
[email protected]> wrote:


To add to this issue:

I’ve hacked some test together for this and can confirm the
problem.
It actually has nothing specifically to do with next-hop-self.
The problem is seen if a BGP update changes from a reachable next-hop 
to an unreachable next-hop:
BGP updates the BGP table first, then sends the update to Zebra - but 
sends the update (the withdraw in this case) with the NEW nexthop.
Zebra
fails to find the specific route to withdraw and will then drop the
withdraw.
The result is a stale (old) route in Zebra (Zebra RIB only - not
BGP).
What makes it worse, is that even a close of the BGP session won’t 
fix
this. In my tests, only a restart of BGPd (or Zebra) fixes the
problem.

To reproduce the issue, use my (ugly, but functional) BGPtool:
https://git-us.netdef.org/projects/NETDEF/repos/bgptool/
and checkout the branch “test/invalid-valid-invalid” (or commit
a0af1816)
See doc at

https://git-us.netdef.org/projects/NETDEF/repos/bgptool/browse/README_valid-invalid.md?at=test/invalid-valid-invalid
on how to reproduce this.

I’ve reproduce this issue in the latest Quagga Master (commit
ca8ec20
as of Sep 29, 2015)

Regards,
Martin Winter
[email protected]
PS: I did not spend the time looking into solution, just providing a 
way
to reproduce the issue (and confirming it)



On 1 Oct 2015, at 17:47, Jacqueline Yu wrote:
Here are the corresponding BGP log and Zebra log I have for this and 
I

observed similar failure on 0.99.24 as well as 0.99.22 --

BGP log --

2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got total
byte
length 6
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got type 2, 
length 2
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: Bytes now: 6
2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd UPDATE w/ attr: nexthop 
10.8.0.1, origin ?, localpref 100, path 200 50

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 0.0.0.0/0

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 10.150.0.0/16

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 20.0.0.0/8

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 60.0.0.0/8

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 120.0.0.0/8

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 120.1.1.0/24

2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got total
byte
length 6
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got type 2, 
length 2
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: Bytes now: 6
2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd UPDATE w/ attr: nexthop 
200.100.1.2, origin ?, localpref 100, path 200 50

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 100.100.1.0/24

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 100.100.2.0/24

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 100.100.3.0/24

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 100.100.4.0/24

2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got total
byte
length 6
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got type 2, 
length 2
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: Bytes now: 6
2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd UPDATE w/ attr: nexthop 
200.200.200.2, origin ?, localpref 100, path 200 50

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 200.200.250.14/32

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 200.200.250.15/32

2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got total
byte
length 6
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: got type 2, 
length 2
2015/09/21 16:52:06 BGP: [AS4SEG] Parse aspath segment: Bytes now: 6
2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd UPDATE w/ attr: nexthop 
200.200.200.3, origin ?, localpref 100, path 200 50

2015/09/21 16:52:06 BGP: 200.200.200.1 rcvd 200.200.250.16/32

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete 0.0.0.0/0
nexthop
10.8.0.1 metric 0
2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete 10.150.0.0/16 
nexthop 10.8.0.1 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete 20.0.0.0/8
nexthop
10.8.0.1 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete 60.0.0.0/8
nexthop
10.8.0.1 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete 120.0.0.0/8
nexthop
10.8.0.1 metric 0
2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete 120.1.1.0/24 
nexthop
10.8.0.1 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete
100.100.1.0/24
nexthop 200.100.1.2 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete
100.100.2.0/24
nexthop 200.100.1.2 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete
100.100.3.0/24
nexthop 200.100.1.2 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete
100.100.4.0/24
nexthop 200.100.1.2 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete
200.200.250.14/32
nexthop 200.200.200.2 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete
200.200.250.15/32
nexthop 200.200.200.2 metric 0

2015/09/21 16:52:06 BGP: Zebra send: IPv4 route delete
200.200.250.16/32
nexthop 200.200.200.3 metric 0


Zebra log --

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [13]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_NEXTHOP_LOOKUP] 4

2015/09/21 16:52:06 ZEBRA: zread_ipv4_nexthop_lookup: looking up
10.8.0.1

2015/09/21 16:52:06 ZEBRA: zsend_ipv4_nexthop_lookup: No matching
rib
entry
found.

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [13]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_NEXTHOP_LOOKUP] 4

2015/09/21 16:52:06 ZEBRA: zread_ipv4_nexthop_lookup: looking up
200.100.1.2

2015/09/21 16:52:06 ZEBRA: zsend_ipv4_nexthop_lookup: No matching
rib
entry
found.

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [13]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_NEXTHOP_LOOKUP] 4

2015/09/21 16:52:06 ZEBRA: zread_ipv4_nexthop_lookup: looking up
200.200.200.2

2015/09/21 16:52:06 ZEBRA: zsend_ipv4_nexthop_lookup: No matching
rib
entry
found.

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [13]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_NEXTHOP_LOOKUP] 4

2015/09/21 16:52:06 ZEBRA: zread_ipv4_nexthop_lookup: looking up
200.200.200.3

2015/09/21 16:52:06 ZEBRA: zsend_ipv4_nexthop_lookup: No matching
rib
entry
found.

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
16
2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete 0.0.0.0/0 
via
10.8.0.1 ifindex 0

2015/09/21 16:52:06 ZEBRA: route 0.0.0.0/0 via 10.8.0.1 ifindex 0
type 9
doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
18

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
10.150.0.0/16
via 10.8.0.1 ifindex 0
2015/09/21 16:52:06 ZEBRA: route 10.150.0.0/16 via 10.8.0.1 ifindex 
0
type
9 doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
17

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
20.0.0.0/8 via
10.8.0.1 ifindex 0

2015/09/21 16:52:06 ZEBRA: route 20.0.0.0/8 via 10.8.0.1 ifindex 0
type 9
doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
17

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
60.0.0.0/8 via
10.8.0.1 ifindex 0

2015/09/21 16:52:06 ZEBRA: route 60.0.0.0/8 via 10.8.0.1 ifindex 0
type 9
doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
17

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
120.0.0.0/8
via
10.8.0.1 ifindex 0
2015/09/21 16:52:06 ZEBRA: route 120.0.0.0/8 via 10.8.0.1 ifindex 0 
type
9
doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
19

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
120.1.1.0/24
via
10.8.0.1 ifindex 0
2015/09/21 16:52:06 ZEBRA: route 120.1.1.0/24 via 10.8.0.1 ifindex 0 
type 9
doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
19

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
100.100.1.0/24
via 200.100.1.2 ifindex 0

2015/09/21 16:52:06 ZEBRA: route 100.100.1.0/24 via 200.100.1.2
ifindex 0
type 9 doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
19

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
100.100.2.0/24
via 200.100.1.2 ifindex 0

2015/09/21 16:52:06 ZEBRA: route 100.100.2.0/24 via 200.100.1.2
ifindex 0
type 9 doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
19

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
100.100.3.0/24
via 200.100.1.2 ifindex 0

2015/09/21 16:52:06 ZEBRA: route 100.100.3.0/24 via 200.100.1.2
ifindex 0
type 9 doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
19

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
100.100.4.0/24
via 200.100.1.2 ifindex 0

2015/09/21 16:52:06 ZEBRA: route 100.100.4.0/24 via 200.100.1.2
ifindex 0
type 9 doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
20

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
200.200.250.14/32
via 200.200.200.2 ifindex 0
2015/09/21 16:52:06 ZEBRA: route 200.200.250.14/32 via 200.200.200.2 
ifindex 0 type 9 doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
20

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
200.200.250.15/32
via 200.200.200.2 ifindex 0
2015/09/21 16:52:06 ZEBRA: route 200.200.250.15/32 via 200.200.200.2 
ifindex 0 type 9 doesn't exist in rib

2015/09/21 16:52:06 ZEBRA: zebra message comes from socket [12]

2015/09/21 16:52:06 ZEBRA: zebra message received
[ZEBRA_IPV4_ROUTE_DELETE]
20

2015/09/21 16:52:06 ZEBRA: rib_delete_ipv4(): route delete
200.200.250.16/32
via 200.200.200.3 ifindex 0
2015/09/21 16:52:06 ZEBRA: route 200.200.250.16/32 via 200.200.200.3 
ifindex 0 type 9 doesn't exist in rib

On Tue, Sep 22, 2015 at 11:52 AM, J Yu <[email protected]>
wrote:

Hi all,


I am seeing issue where kernel routes are not deleted even though
the
some
of the routes have updated nexthop that's not reachable. I do see
delete
going into Zebra where it has the new nexthop while Zebra still had 
the
routes pointed to the old nexthop. My code base is 0.99.24 with
some
minor
modifications...Anyone had seen similar issue?

Example from below -- This router is C14 and neighbor IP is
200.200.200.1
and the route tables looks fine on C14.
C14# show ip bgp
BGP table version is 0, local router ID is 200.200.250.14
Status codes: s suppressed, d damped, h history, * valid, > best, = 
multipath,
     i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*>i0.0.0.0 200.200.200.1 100 0 200 50 
?
*>i10.150.0.0/16 200.200.200.1 100 0 200 50 
?

C14# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,

- selected route, * - FIB route


B>  0.0.0.0/0 [200/0] via 200.200.200.1 (recursive), 00:00:32
*                     via 200.200.200.1, eth3.21 onlink, 00:00:32
B>  10.150.0.0/16 [200/0] via 200.200.200.1 (recursive), 00:00:32
*                         via 200.200.200.1, eth3.21 onlink,
00:00:32
------------
Now, changing neighbor to no longer do next-hop-self, hence the
next hop
will point to the new nexthop of 10.8.0.1 and I see the following
outputs--
------------
C14# show ip bgp
BGP table version is 0, local router ID is 200.200.250.14
Status codes: s suppressed, d damped, h history, * valid, > best, = 
multipath,
     i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
* i0.0.0.0 10.8.0.1 100 0 200 50 
?
* i10.150.0.0/16 10.8.0.1 100 0 200 50 
?


C14# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel,

- selected route, * - FIB route


B>  0.0.0.0/0 [200/0] via 200.200.200.1 (recursive), 00:07:09
*                     via 200.200.200.1, eth3.21 onlink, 00:07:09
B>  10.150.0.0/16 [200/0] via 200.200.200.1 (recursive), 00:07:09
*                         via 200.200.200.1, eth3.21 onlink,
00:07:09

Appreciate any pointers!

Jacqueline

_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

_______________________________________________

Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev





_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

                                        


_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to