Re: iBGP configuration between three nodes - Page 2

Dipesh Patel · ‎10-09-2012

Dear experts,

Kindly suggest for the iBGP configuration between two routers and One CORE switch as shown in diagram :

1. iBGP between CE Router A to L3 switch

2. iBGP between CE Router B to L3 switch

3. iBGP between CE Router A to CE Router B

Is ok or I should not configure iBGP between Router to Route and break a loop?

In both the case on router should I configure : neighbor X.X.X.X next-hop-self?

is it required to configure : neighbor X.X.X.X next-hop-self on CORE switch?

Regards

Giuseppe Larosa · ‎10-15-2012

Hello Dipesh,

>> Different Prefixes we are learing from both the links. Some of the prefixes are common on both the links which comming from the location where the same two links are there.

>> At present we have done iBGP between ISP1 MPLS CE router 1 to Both CORE switches as well as ISP2 MPLS CE router 2. But not yet between CORE1 to CORE 2 switches.

The iBGP session between CORE1 and CORE2 would be useful only if CORE1 and CORE2 are made route reflector servers and the two CE border routers are made route reflector clients.

This is because the iBGP split horizon applies: an iBGP Router RB cannot advertise to another iBGP Router RC the prefixes learned by an iBGP peer like RA.

This rule applies to your scenario so the two CORE routers unless configured as BGP route reflector servers will not exchange any route.

I would suggest to add an iBGP session between the two CE routers, because you have told us that not all VPN sites are multihomed to both ISP1 and ISP2 so you need to exchange routes in some HUB location as the one discussed in this thread.

You should also provide a direct link between CE1 (ISP1) to CORE2 and a direct link between CE2 (ISP2) and CORE1. In this way if one CORE multilayer switch fails the surviving CORE router can still make choices between ISP1 and ISP2.

This is a needed step because not all VPN sites are multihomed to ISP1 and ISP2 but some of them are connected to only one MPLS SP.

Hope to help

Giuseppe

Dipesh Patel · ‎10-15-2012

Thanks Giuseppe

So from the whole coversation i summarised following Points :

I need to configure:

1. iBGP configuration between RouterA to COREA. with neighbour X.X.X.X next-hop-self -- Done

2 .iBGP configuration between Router A to COREB.with neighbour X.X.X.X next-hop-self -- Done

3. iBGP configuration between RouterB to COREA.with neighbour X.X.X.X next-hop-self -- Done

4 .iBGP configuration between Router B to COREB.with neighbour X.X.X.X next-hop-self -- Done

5. COREA is advertising all the segments uing LP = 100 (Route-Map configured)

6. COREB s advertising all the segments using LP=50(Route-Map configured)

7. iBGP configuration between Router A to Router B --- Yet not done

8. No need to configure iBGP between COREA and COREB. --- Yet not done.

If require I can share the configuration done till now.

In adition to this After this configuration I have found in "sh ip bgp" on Router A :

*>i172.0.208.0/24 172.20.23.1 0 100 0 i

where 172.0.208.0/24 segment is advertised by both the CORE switches with LP = 100 and LP = 50 respectively.

I think here I should see two routes like :

*>i172.0.208.0/24 172.20.23.1 0 100 0 i

*i172.0.208.0/24 172.20.23.3 0 50 0 i

Please suggest.

Regards

Giuseppe Larosa · ‎10-16-2012

Hello Dipesh,

check if all the BGP sessions are up and running with

RA:

show ip bgp summary

on COREA, COREB check if the route is generated using

show ip bgp 172.0.208.0

check BGP sessions with

show ip bgp summary

I agree with you, you should see two different advertisements for the same IPv4 network one from COREA and one from COREB.

possible causes include:

an IBGP session is up and running between COREA and COREB and COREB installed COREA's prefix.

iBGP session between RA and COREB is not operational

COREB is not advertising the prefix for some reasons

Note: what about the direct links RA-COREB and RB-COREA have you implemented them?

Hope to help

Giuseppe

Dipesh Patel · ‎10-16-2012

Dear Giuseppe,

Please find the output:

RA> sh ip bgp summary
BGP router identifier 10.72.137.204, local AS number 65406
BGP table version is 1904, main routing table version 1904
482 network entries using 57840 bytes of memory
482 path entries using 25064 bytes of memory
12/12 BGP path/bestpath attribute entries using 1488 bytes of memory
8 BGP AS-PATH entries using 208 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
3 BGP filter-list cache entries using 36 bytes of memory
BGP using 84636 total bytes of memory
BGP activity 2178/1696 prefixes, 3878/3396 paths, scan interval 60 secs

Neighbor        V           AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd
10.1.25.229     4         4755   15745   15432     1904    0    0 1w2d          417
172.20.23.1     4        65406    3621    4078     1904    0    0 2d12h          64
172.20.23.3     4        65406    3845    4379     1904    0    0 2d16h           0

CORE A (172.20.23.1)

CORE-A>sh ip bgp 172.0.208.0
BGP routing table entry for 172.0.208.0/24, version 272
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
     1
Local
    0.0.0.0 from 0.0.0.0 (172.24.95.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best

CORE-A>sh ip bgp summary
BGP router identifier 172.24.95.1, local AS number 65406
BGP table version is 1645, main routing table version 1645
615 network entries using 71955 bytes of memory
1256 path entries using 65312 bytes of memory
30/17 BGP path/bestpath attribute entries using 4200 bytes of memory
16 BGP AS-PATH entries using 384 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 141851 total bytes of memory
BGP activity 809/194 prefixes, 1710/454 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd
172.20.23.248   4 65406    4167    3625     1645    0    0 2d12h         454
172.20.23.249   4 65406    3785    3625     1645    0    0 2d12h         320
172.20.23.250   4 65406    4082    3625     1645    0    0 2d12h         418
INMUMKURCS-BBLD-BDC-CORE-A>

CORE B

CORE-B>sh ip bgp 172.0.208.0
BGP routing table entry for 172.0.208.0/24, version 983
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
Local
0.0.0.0 from 0.0.0.0 (172.24.95.3)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best

CORE-B>sh ip bgp summary
BGP router identifier 172.24.95.3, local AS number 65406
BGP table version is 2236, main routing table version 2236
615 network entries using 71955 bytes of memory
1255 path entries using 65260 bytes of memory
30/17 BGP path/bestpath attribute entries using 4200 bytes of memory
16 BGP AS-PATH entries using 384 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 141799 total bytes of memory
BGP activity 879/264 prefixes, 2537/1282 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd
172.20.23.248   4 65406    4505    3842     2236    0    0 2d15h         453
172.20.23.249   4 65406    4036    3850     2236    0    0 2d16h         320
172.20.23.250   4 65406    4386    3851     2236    0    0 2d16h         417

There are no direct link between RA and COREB as well as RB an COREA.

Giuseppe Larosa · ‎10-16-2012

Hello Dipesh,

we can see that COREB is NOT advertising the prefix to any peer.

>> CORE-B>sh ip bgp 172.0.208.0

BGP routing table entry for 172.0.208.0/24, version 983

Paths: (1 available, best #1, table Default-IP-Routing-Table)

>>>>>> Not advertised to any peer <<<<

Local

0.0.0.0 from 0.0.0.0 (172.24.95.3)

This is the reason why you don't see the second advertisement on RA coming from COREB.

To understand why this happens you should show the router BGP configuration of COREB including the route-maps.

You likely need to update those route-maps to each neighbor

I see three different iBGP neighbors, the same three ones on both COREA ans COREB there is a third CE edge router?

>> There are no direct link between RA and COREB as well as RB an COREA.

It would be wise to add them because not all VPN sites are multihomed to both ISP1 and ISP2.

Hope to help

Giuseppe

Dipesh Patel · ‎10-16-2012

Dear Giuseppe,

Please find the output : wrong route-ap is applied.

router bgp 65406
no synchronization
bgp log-neighbor-changes
network 172.0.208.0 mask 255.255.255.0
neighbor 172.20.23.248 remote-as 65406
neighbor 172.20.23.248 route-map RM-LOCAL-OUT-COREA-SEC out
neighbor 172.20.23.249 remote-as 65406
neighbor 172.20.23.249 route-map RM-LOCAL-OUT-COREA-SEC out
neighbor 172.20.23.250 remote-as 65406
neighbor 172.20.23.250 route-map RM-LOCAL-OUT-COREA-SEC out
no auto-summary
!

ip prefix-list PL-LOCAL-OUT-COREA-SEC seq 10 permit 0.0.0.0/0 le 32

route-map RM-LOCAL-OUT-COREA-PRI permit 10
match ip address prefix-list PL-LOCAL-OUT-COREA-SEC
set local-preference 50

I see three different iBGP neighbors, the same three ones on both COREA ans COREB there is a third CE edge router?

ANS : Yes, All three are Edge CE routers (172.20.23.248,172.20.23.249,172.20.23.250).

As you suggested, there should be direct link between RA and COREB as well as RB and COREA. But by CORE A is receiving routes from All the Three CEs. Hence It will server the purpose I think. Hence If the Prefixes coming from location with dual Links, I can see two path in COREs. If prefix from location with either ISP - 1 or ISP - 2 than it will be seen with ony one path. Hence COREs will be the decesion maker to choose the best path.

Please find the output of sh ip bgp ( Kept output for onyl 3 segments)

*>i172.0.8.0/22 172.20.23.249 0 100 0 9730 65470 i

*>i172.12.144.0/24 172.20.23.250 0 100 0 4755 65270 i

* i172.12.90.0/24 172.20.23.248 50 100 0 4755 65400 i

* i 172.20.23.249 0 100 0 9730 65400 65400 65400 i
*>i 172.20.23.250 0 100 0 4755 65400 i

Regards

Giuseppe Larosa · ‎10-16-2012

Hello Dipesh,

a non existing route-map was applied change accordingly, I would call the route-map RM-LOCAL-OUT-COREB

route-map RM-LOCAL-OUT-COREAB permit 10

match ip address prefix-list PL-LOCAL-OUT-COREA-SEC

set local-preference 50

router bgp 65406

neigh 172.20.23.248 route-map RM-LOCAL-OUT-COREB out

neigh 172.20.23.249 route-map RM-LOCAL-OUT-COREB out

neigh 172.20.23.250 route-map RM-LOCAL-OUT-COREB out

About fault tolerance: without direct physical paths COREA iBGP session to RB goes through COREB, if COREB fails COREA BGP session to RB fails too, so IP prefixes learned only on RB iBGP session would be lost.

However, the same would happen if RB fails.

So fault tolerance at node level cannot be achieved in this design.

The third CE router is provided by ISP1, ISP2 or another ISP?

Hope to help

Giuseppe

Dipesh Patel · ‎10-16-2012

Hi,

It's Seconary Last mile. So not an issue for that.

And for more clarity, All the Nodes i.e. All there Routers and two CORE switches are connected via Access switches. Hence if COREB will be down than also iBGP session will be continue via Access switch which is connected to both the core switches.

If it's no access switch than, I think iBGP between two routers can solve the problem.

Is it OK if I will make comlete iBGP mesh (No Physical connectivity) i.e. all the devices have iBGP sessions to all the devices?

Is there any impact of it?

Any sugation for that?

Regards

Giuseppe Larosa · ‎10-16-2012

Hello Dipesh,

>> All there Routers and two CORE switches are connected via Access switches. Hence if COREB will be down than also iBGP session will be continue via Access switch which is connected to both the core switches.

I would build two different backbone Vlans one in Access layer switch 1 and one in access layer switch 2 and I would connect RA, RB, COREA, COREB to BOTH access layer switches.

At this point I would move to iBGP sessions using loopback addresses advertised in an IGP like OSPF or EIGRP executed on the two backbone VLANs.

Change in BGP

neigh x.x.x.x update-source loopM

Changes for using an IGP to publish loopback addresses

int loopM

ip address x.x.x.x 255.255.255.255

router ospf 10

router-id x.x.x.x

network x.x.x.x 0.0.0.0 area 0

network area 0

netwrok area 0

using a different IP address for each device in (RA,RB, COREA, COREB) group.

where vlan-BBi is the IP subnet associated to each backbone vlan.

Each vlan-BBi is confined in a single access switch.

In this way you can achieve a good level of fault tolerance (except RA and RB edge routers)

Hope to help

Giuseppe

Dipesh Patel · ‎10-17-2012

Dear Giuseppe,

As present it's not possible to change that much in physical topology architecture. I need to go ahead with this only.

I need suggation for two points in my scenario which I have Mentioned:

1. Is it really require to configure iBGP between two CE routers?

2. Is it really required to configure iBGP between two CORE switches?

3. In my case all the devices with iBGP sessions are connected directed as they are in same backbone Vlan. So in that case there is no need to use OSPF. Is it OK?

Regards

Giuseppe Larosa · ‎10-18-2012

Hello Dipesh,

I understand you cannot make changes to physical topology. You should document what are the possible fault scenarios with the implemented solution.

I provide answers to your specific questions

1) Yes, if this is a central location because as you have noted that not all VPN sites are multihomed to both ISP1 and ISP2

2) No, the iBGP session between core switches does not provide any benefit unless other features are used ( BGP Route reflection). So this is No for sure.

3) If you have a single backbone vlan your iBGP peers can peer on physical IP addresses so OSPF would not be needed.

However, using loopbacks for iBGP sessions and OSPF to publish them would make your network ready to be improved in the future with the addition of a second backbone vlan.

This would be also a way to remark the lack of the second backbone vlan.

All you need for building a second Vlan is a free interface in each CE and CORE devices and a dedicate L2 LAN switch.

I would go in this way, with a design ready to be improved at the price of some more complexity.

Hope to help

Giuseppe