BGP Routes

Answered Question
Dec 29th, 2009
User Badges:

Hello Experts


Pls find the attached visio diagram for reference of below theory.


It is a carrier supporting carrier scenario


From my attached diagram i was receiving routes through core-1 and core-2 for the customer-1 and customer -1 was passing traffic through core-1 becz of CORE-1  lower router ID than core -2 , core -2 is in reduntant incase of core-1 failure. Suddenly stopped receiving routes from Core-1 through ISP-1 for customer-1 due to some technical maintenance,but still routes are received by core -2 and customer -1 traffic passes through core-2  with ISP-1 router connected to core -2.


The link between core -1 and core 2 towards ISP is back to back VRF,and the link between dist and core is MPLS enabled and dist and core are peering with RR 1 and RR-2,


Can anybody explain me why core-1 is not receiving routes through core-2 ????? when maintenance is carried out in ISP-1 router connected to Core-1  ???????


Thanks.

Correct Answer by Giuseppe Larosa about 7 years 6 months ago

Hello Andy,

Reza has found the cause of your issue.


each Route Reflector server adds two BGP attributes to the BGP advertisement before reflecting:


cluster-list: BGP Router-id or cluster-id of RRS

Originator-id:  BGP router id of device that originated the advertisement in the iBGP


RR clients check these additional attributes on received advertisements, they prefer the shortest Cluster-list (= less number of reflections) and they discard routes with Originator-ID = local BGP router-id.


And this is what probably happens in your case.


Hope to help

Giuseppe

Correct Answer by Reza Sharifi about 7 years 6 months ago

Hi Andy,


Why the router IDs for both cores (Core-1 and Core-2) is the same?


Core-2# sh ip bgp vpnv4 all summary
BGP router identifier 10.28.250.1, local AS number 65535


Core-1# sh ip bgp vpnv4 all summary
BGP router identifier 10.28.250.1, local AS number 65535


Reza

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Giuseppe Larosa Tue, 12/29/2009 - 12:36
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Andy,

the scenario is quite complex and would need to see the configurations.


What core1 is receving from ISP1 router?  A simple default route that will be used by customer1 VRF sites or a subset of BGP internet table or full internet table.


You say that the link between core1 and core2 is a back to back VRF, have you implemented an eBGP or iBGP session in VRF between the two?


if eBGP in VRF it will be of the same type of the session with ISP1 router there is any form of preference weight, local preference for the routes learned by ISP1 router.


Also the most important aspect are the customer1 VRF sites connected to distribution nodes.

During the failure have you checked which default route or other routes are received on distribution PE nodes.

The fact that core1 doesn't learn routes from core2 can be of reduced impact if core1 stops to advertise the routes learned by ISP1 R1, and remote PE noded install the routes learned by core2.


I would have preferred an MPLS link between core1 and core2 instead of back to back to VRF this change could lead to a better behaviour.


Hope to help

Giuseppe

lambay2000 Wed, 12/30/2009 - 04:20
User Badges:

Hello Andy,


The peering between core-1 and RR are OK ??? chk it.


Thanks

thomasandy32 Wed, 12/30/2009 - 04:50
User Badges:

Hello Giuseppe,


What core1 is receving from ISP1 router?  A simple default route that will be used by customer1 VRF sites or a subset of BGP

internet table or full internet table.


The customer-1 is receiving routes from branch office,


You say that the link between core1 and core2 is a back to back VRF, have you implemented an eBGP or iBGP session in VRF between

the two?


Sorry typing mistake in above line,the link between ISP-1 routers and  core-1 and ISP-1 router and core-2 is back to back VRF,Core

switches are  6500 switch configured as a trunk on gig interface and created a SVI on core 6500 to form BGP peering with ISP

routers sub-interfaces.The link between core-1 and core-2 is IGP mpls ip enabled on the interfaces between them.


Also the most important aspect are the customer1 VRF sites connected to distribution nodes.During the failure have you checked

which default route or other routes are received on distribution PE nodes.


The failure causes no disruption in flow of data,traffic is flowing from core-2 to the branch offices.the customer are connected to

distribution switches (PE).


RR are not peering with each other becz each RR is peering with each and every distribution and core switch.


Core-1 is not receiving routes from core-2 when the ISP-1  router connected too core-1 fails. why??? Is it am missing any configs,

or some different behaviour of BGP in MPLS.





Friends ur replies will be appreciated.


Thanks,

thomasandy32 Wed, 12/30/2009 - 11:52
User Badges:

Hello,


Can anybody share their expierience with me for the above problem.


Thanks

Giuseppe Larosa Wed, 12/30/2009 - 12:52
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Andy,

you have added some more details.


the network scenario is more likely with MPLS / MP BGP between core switches as expected.


However, there are not enough information to provide you more help.

I would suggest you to send a filtered version of your configuration, remove user/pwds and mask public ip addresses


Only question: do your use different route distinguisher in the VRFs defined on core1 and core2, or it is the same?


Hope to help

Giuseppe

thomasandy32 Thu, 12/31/2009 - 11:10
User Badges:

Hello Giuseppe,


Thanks for ur reply,


the network scenario is more likely with MPLS / MP BGP between core switches as expected.

YES


The route distinguisher on both core is same.There are no public IP addresses in config, RR are peering with each distribution and core properly.Also distribution switches are recieving prefix from RR but core-1 is not receiving ??? just have a look on output.



Distribution-2 #sh ip bgp vpnv4 all summ

BGP router identifier 10.28.250.11, local AS number 65535
BGP table version is 49013, main routing table version 49013
82 network entries using 11234 bytes of memory
158 path entries using 10744 bytes of memory
10/9 BGP path/bestpath attribute entries using 1400 bytes of memory
10 BGP rrinfo entries using 240 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
4 BGP extended community entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 23738 total bytes of memory
BGP activity 8625/8543 prefixes, 17890/17732 paths, scan interval 15 secs


Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.28.250.3     4 65535    1885    1873    49013    0    0 1d07h          76
10.28.250.4     4 65535    1885    1873    49013    0    0 1d07h          76


RR are 10.28.250.3 and 10.29.250.4


Core-2


Core-2# sh ip bgp vpnv4 all summary
BGP router identifier 10.28.250.1, local AS number 65535
BGP table version is 2873, main routing table version 2873
83 network entries using 11371 bytes of memory
94 path entries using 6392 bytes of memory
12/9 BGP path/bestpath attribute entries using 1680 bytes of memory
10 BGP rrinfo entries using 240 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
4 BGP extended community entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 19803 total bytes of memory
BGP activity 1260/1177 prefixes, 1578/1484 paths, scan interval 15 secs


Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.28.40.67     4 28885   15000   14898     2873    0    0 1w1d           10
10.28.40.71     4 28885   16236   16103     2873    0    0 1w1d           56
10.28.250.3     4 65535    1881    1873     2873    0    0 1d07h          11
10.28.250.4     4 65535    1881    1873     2873    0    0 1d07h          11


10.28.40.67  ---------- BGP neighbor on ISP end for VRF-B
10.28.40.71------------  BGP neighbor on ISP end for VRF-A


Core-2

Core-2#sh run int vlan 333
Building configuration...


interface Vlan333

description heading towards ISP-1 Router-2
ip vrf forwarding B
ip address 10.28.40.66 255.255.255.254


Core-2#sh run int vlan 222
Building configuration...


Current configuration : 96 bytes

!

interface Vlan222

description heading towards ISP-1 Router-2

ip vrf forwarding A

ip address 10.28.40.70 255.255.255.254

end


Core-1


Core-1# sh ip bgp vpnv4 all summary
BGP router identifier 10.28.250.1, local AS number 65535
BGP table version is 19966, main routing table version 19966
16 network entries using 2192 bytes of memory
27 path entries using 1836 bytes of memory
9/7 BGP path/bestpath attribute entries using 1260 bytes of memory
10 BGP rrinfo entries using 240 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
4 BGP extended community entries using 96 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 5648 total bytes of memory
BGP activity 6335/6319 prefixes, 9176/9149 paths, scan interval 15 secs


Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.28.40.65     4 28885    2235    2225    19966    0    0 1d13h           1
10.28.40.69     4 28885   16189   16106    19966    0    0 1w1d            1
10.28.250.3     4 65535    2193    2170    19966    0    0 1d12h          11
10.28.250.4     4 65535    2193    2170    19966    0    0 1d12h          11


10.28.40.65 ---------BGP neighbor on ISP end for VRF-B
10.28.40.69----------BGP neighbor on ISP end for VRF-A       


As u can have a look on sh ip bgp vpnv4 all summary on above lines of Core-1 and Distribution-2 the prefix received are very less on core-1 than Distribution switch.Is it asusual or it shld received or some configs mistake.


Core-1

ip vrf A
rd 65535:52
route-target export 65535:52
route-target import 65535:52
!
ip vrf B
rd 65535:53
route-target export 65535:53
route-target import 65535:53



Core-1:

Interface connected to RR-1


description connected to Route Reflector (RR-01)
dampening
mtu 1524
bandwidth 1000000
ip address 10.28.40.62 255.255.255.254
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 7 060506324F41
ip ospf network point-to-point
carrier-delay msec 0
mpls ip



If u need any more configs pls mail me,


Thanks

Correct Answer
Reza Sharifi Thu, 12/31/2009 - 13:32
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 LAN

Hi Andy,


Why the router IDs for both cores (Core-1 and Core-2) is the same?


Core-2# sh ip bgp vpnv4 all summary
BGP router identifier 10.28.250.1, local AS number 65535


Core-1# sh ip bgp vpnv4 all summary
BGP router identifier 10.28.250.1, local AS number 65535


Reza

Correct Answer
Giuseppe Larosa Thu, 12/31/2009 - 14:57
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Andy,

Reza has found the cause of your issue.


each Route Reflector server adds two BGP attributes to the BGP advertisement before reflecting:


cluster-list: BGP Router-id or cluster-id of RRS

Originator-id:  BGP router id of device that originated the advertisement in the iBGP


RR clients check these additional attributes on received advertisements, they prefer the shortest Cluster-list (= less number of reflections) and they discard routes with Originator-ID = local BGP router-id.


And this is what probably happens in your case.


Hope to help

Giuseppe

Marwan ALshawi Thu, 12/31/2009 - 18:09
User Badges:
  • Purple, 4500 points or more
  • Community Spotlight Award,

    Best Publication, December 2015

also if the RR receive a route from another RR has same cluster ID it will drop it and this will will remove the redundancy if you have multiple RRs

Actions

This Discussion