[c-nsp] bgp vpnv4 routes not arriving in one direction
Aaron
aaron1 at gvtc.com
Tue Feb 17 13:11:37 EST 2015
Thanks for all of your responses…. So here are 2 different xr 9k’s….why are these 2 different routers not seeming to drop updates from each other, even though they also have the same cluster id ? I thought some of you all mentioned that if they have same cluster id, routes will be dropped. They seem to be learning routes from each other and I believe they are both config’d in a rr cluster together.
--------------- 9k1
RP/0/RSP0/CPU0:9k1#sh run int l 1 | in "ipv4 addr"
Tue Feb 17 12:01:46.707 CST
ipv4 address 10.101.0.1 255.255.255.255
RP/0/RSP0/CPU0:9k1#sh run router bgp | in luster
Tue Feb 17 12:01:52.121 CST
bgp cluster-id 1
RP/0/RSP0/CPU0:9k1#sh bgp vpnv4 unicast summary | in "Neigh|10.101.0.2 "
Tue Feb 17 12:01:56.561 CST
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.101.0.2 0 64512 1856323 1802364 155321760 0 0 46w0d 295
--------------- 9k2
RP/0/RSP0/CPU0:9k2#sh run int l 0 | in "ipv4 addr"
Tue Feb 17 12:02:10.733 CST
ipv4 address 10.101.0.2 255.255.255.255
RP/0/RSP0/CPU0:9k2#sh run router bgp | in luster
Tue Feb 17 12:02:15.866 CST
bgp cluster-id 1
RP/0/RSP0/CPU0:9k2#sh bgp vpnv4 unicast summary | in "Neigh|10.101.0.1 "
Tue Feb 17 12:02:18.628 CST
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.101.0.1 0 64512 1792237 1846053 149527800 0 0 46w0d 182
From: Adam Vitkovsky [mailto:Adam.Vitkovsky at gamma.co.uk]
Sent: Tuesday, February 17, 2015 11:29 AM
To: Aaron; cisco-nsp at puck.nether.net
Cc: 'Harold Ritter (hritter)'
Subject: RE: [c-nsp] bgp vpnv4 routes not arriving in one direction
Hi Aron,
Cluster-ID is sort of a loop prevention mechanism and is also used for best path selection and troubleshooting (CLUSTER_LIST).
It is filled into the cluster list each time the route is reflected (although I'm not sure about this particular detail it might be that if the route came from a client and is sent to a non-client it has the cluster-id -unfortunately I don't remember the results anymore).
By default router when configured with RR clients will use the BGP ID as the Cluster-ID (i.e. one RR per cluster).
Setting the Cluster-ID manually (usually to set the common Cluster-ID on multiple RR forming a common cluster /or per neighbour cluster ids) makes sense when you are building some more complex RR topologies involving multiple clusters or even hierarchies (which I would not recommend) or to prevent from unnecessary memory waste.
As you can see if a node finds its own cluster id in the cluster list it will drop the advertisement -because the route has obviously passed through the cluster already (meaning the RRs already know the route first hand directly from the client) and at some point the route has been reflected back to that same cluster so the advertisement can be safely ignored.
adam
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Aaron
> Sent: 17 February 2015 13:37
> To: cisco-nsp at puck.nether.net
> Cc: 'Harold Ritter (hritter)'
> Subject: [c-nsp] bgp vpnv4 routes not arriving in one direction
>
>
>
> I have 2 routers here that seem to have good mp-bgp neighboring, one IOS,
> and the other IOS XRv. I config'd both to be a route reflector cluster.
> They are both advertising routes to each other but for some reason, R5 isn't
> rcv'ing the routes from R2-xr
>
>
>
> Shown below you will see the R2-xr is sending the routes, but I don't see
> them come into R5. I show some debugs from R5 to help determine why.
>
>
>
> RP/0/0/CPU0:R2-xr#sh run router bgp
>
> router bgp 65535
>
> bgp router-id 10.0.0.2
>
> bgp cluster-id 1
>
> .
>
>
>
> R5#sh run | sec router bgp
>
> router bgp 65535
>
> bgp router-id 10.0.0.5
>
> no bgp default ipv4-unicast
>
> bgp cluster-id 1
>
> ..
>
>
>
>
>
> RP/0/0/CPU0:R2-xr#sh bgp vpnv4 unicast neighbors 10.0.0.5 | in ntern
>
> Tue Feb 17 07:28:54.746 UTC
>
> Remote AS 65535, local AS 65535, internal link
>
> Precedence: internet
>
>
>
> R5#sh bgp vpnv4 unicast all neighbors 10.0.0.2 | in ntern
>
> BGP neighbor is 10.0.0.2, remote AS 65535, internal link
>
>
>
>
>
> RP/0/0/CPU0:R2-xr#sh bgp vpnv4 unicast advertised neighbor 10.0.0.5
> summary
>
> Tue Feb 17 07:20:59.318 UTC
>
> Network Next Hop From AS Path
>
> Route Distinguisher: 10.0.0.1:1
>
> 192.168.1.0/24 10.0.0.1 10.0.0.1 ?
>
> 192.168.4.0/30 10.0.0.1 10.0.0.1 ?
>
> Route Distinguisher: 10.0.0.3:1
>
> 192.168.7.0/30 10.0.0.3 10.0.0.3 ?
>
> Route Distinguisher: 10.0.0.4:1
>
> 192.168.2.0/24 10.0.0.4 10.0.0.4 ?
>
> Route Distinguisher: 10.0.0.6:1
>
> 192.168.6.0/30 10.0.0.6 10.0.0.6 i
>
> Route Distinguisher: 10.0.0.7:1
>
> 192.168.3.0/24 10.0.0.7 10.0.0.7 ?
>
> Route Distinguisher: 10.0.0.8:1
>
> 0.0.0.0/0 10.0.0.8 10.0.0.8 174i
>
> 38.128.1.0/24 10.0.0.8 10.0.0.8 ?
>
> 192.168.0.0/16 10.0.0.8 10.0.0.8 i
>
> 192.168.5.0/30 10.0.0.8 10.0.0.8 ?
>
>
>
> Processed 10 prefixes, 10 paths
>
>
>
> RP/0/0/CPU0:R2-xr#sh bgp vpnv4 unicast summary | in "Neighbor|10.0.0.5"
>
> Tue Feb 17 07:20:27.380 UTC
>
> Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> St/PfxRcd
>
> 10.0.0.5 0 65535 53 46 16 0 0 00:35:47
> 3
>
>
>
>
>
> R5#sh bgp vpnv4 unicast al summary | in Neigh|10.0.0.2
>
> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
>
> 10.0.0.2 4 65535 46 54 35 0 0 00:36:13 0
>
>
>
> R5#sh bgp vpnv4 unicast rd 10.0.0.2:1
>
> (nothing here)
>
>
>
>
>
>
>
> R5#show debugging
>
> IP routing:
>
> BGP updates debugging is on for address family: VPNv4 Unicast
>
> Tag VPN:
>
> Tag VPN debugging is on
>
>
>
>
>
> *Feb 17 07:33:15.991: %BGP-3-NOTIFICATION: received from neighbor
> 10.0.0.2
> 6/2 (cease) 0 bytes
>
> *Feb 17 07:33:15.995: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Down BGP
> Notification received
>
> R5#
>
> R5#
>
> R5#sh bgp vpnv4 unicast rd 10.0.0.2:1
>
>
>
> R5#sh bgp vpnv4 unicast all neighbors 10.0.0.2 | in ntern
>
> R5#sh bgp vpnv4 unicast al summary | in Neigh|10.0.0.2
>
> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
>
> 10.0.0.2 4 65535 60 66 0 0 0 00:00:19 Active
>
> R5#
>
> *Feb 17 07:33:45.783: %BGP-5-ADJCHANGE: neighbor 10.0.0.2 Up
>
> *Feb 17 07:33:45.787: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.8:1:192.168.0.0/16, next 10.0.0.8, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.791: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.6:1:192.168.6.0/30, next 10.0.0.6, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.795: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.5:1:192.168.0.0/16, next 10.0.0.5, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.799: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.7:1:192.168.3.0/24, next 10.0.0.7, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.803: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.4:1:192.168.2.0/24, next 10.0.0.4, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.807: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.8:1:38.128.1.0/24, next 10.0.0.8, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.811: BGP(2):
>
> R5# 10.0.0.2 send UPDATE (prepend, chgflags: 0x0) 10.0.0.8:1:192.168.5.0/30,
> next 10.0.0.8, metric 0, path Local, extended community RT:1:1
>
> *Feb 17 07:33:45.815: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.1:1:192.168.1.0/24, next 10.0.0.1, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.819: BGP(2): 10.0.0.2 send UPDATE (prepend, chgflags: 0x0)
> 10.0.0.1:1:192.168.4.0/30, next 10.0.0.1, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.823: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.5:1:12.128.1.0/24, next 10.0.0.5, metric 0, path Local, extended
> community RT:1:1
>
> *Feb 17 07:33:45.827: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.8:1:0.0.0.0/0, next 10.0.0.8, metric 0, path 174, extended community
> RT:1:1
>
> *Feb 17 07:33:45.831: BGP(2): 10.0.0.2 send UPDATE (format)
> 10.0.0.5:1:0.0.0.0/0, next 10.0.0.5, metric 0, path 7018, extended community
> RT:1:1
>
> R5#
>
> *Feb 17 07:33:50.803: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.803: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.6,
> origin i, localpref 100, originator 10.0.0.6, clusterlist 0.0.0.1, path ,
> community , extended community RT:1:1
>
> *Feb 17 07:33:50.807: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.6:1:192.168.6.0/30 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.811: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.811: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.3,
> origin ?, localpref 100, metric 0, originator 10.0.0.3, clusterlist 0.0.0.1,
> path , community , extended community RT:1:1
>
> *Feb 17 07:33:50.815: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.3:1:192.168.7.0/30 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.819: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.819: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.7,
> origin ?, localp
>
> R5#ref 100, metric 0, originator 10.0.0.7, clusterlist 0.0.0.1, path ,
> community , extended community RT:1:1
>
> *Feb 17 07:33:50.823: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.7:1:192.168.3.0/24 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.823: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.827: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.4,
> origin ?, localpref 100, metric 0, originator 10.0.0.4, clusterlist 0.0.0.1,
> path , community , extended community RT:1:1
>
> *Feb 17 07:33:50.831: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.4:1:192.168.2.0/24 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.831: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.835: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.8,
> origin ?, localpref 100, metric 0, originator 10.0.0.8, clusterlist 0.0.0.1,
> path , community , extended community RT:1:1
>
> *Feb 17 07:33:50.839: BGP(2): 10.0.0.2 rcv UPDATE about 10.0
>
> R5#.0.8:1:192.168.5.0/30 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.839: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.8:1:38.128.1.0/24 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.847: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.851: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.1,
> origin ?, localpref 100, metric 0, originator 10.0.0.1, clusterlist 0.0.0.1,
> path , community , extended community RT:1:1
>
> *Feb 17 07:33:50.855: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.1:1:192.168.4.0/30 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.855: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.1:1:192.168.1.0/24 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.855: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.859: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.8,
> origin i, localpref 100, atomic-aggregate, aggregated by 65535 10.0.0.8,
> originator
>
> R5# 10.0.0.8, clusterlist 0.0.0.1, path , community , extended community
> RT:1:1
>
> *Feb 17 07:33:50.863: BGP(2): 10.0.0.2 rcv UPDATE about
> 10.0.0.8:1:192.168.0.0/16 -- DENIED due to: reflected from the same cluster;
>
> *Feb 17 07:33:50.863: BGP: 10.0.0.2 RR in same cluster. Reflected update
> dropped
>
> *Feb 17 07:33:50.863: BGP(2): 10.0.0.2 rcv UPDATE w/ attr: nexthop 10.0.0.8,
> origin i, localpref 100, metric 0, originator 10.0.0.8, clusterlist 0.0.0.1,
> path 174, community , extended community RT:1:1
>
> *Feb 17 07:33:50.863: BGP(2): 10.0.0.2 rcv UPDATE about 10.0.0.8:1:0.0.0.0/0
> -- DENIED due to: reflected from the same cluster;
>
>
>
> R5#sh bgp vpnv4 unicast all neighbors 10.0.0.2 | in ntern
>
> BGP neighbor is 10.0.0.2, remote AS 65535, internal link
>
> R5#
>
> R5#sh bgp vpnv4 unicast al summary | in Neigh|10.0.0.2
>
> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
>
> 10.0.0.2 4 65535 71 80 35 0 0 00:00:27 0
>
> R5#u all
>
> All possible debugging has been turned off
>
> R5#
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_____
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com
_____
More information about the cisco-nsp
mailing list