Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

iBGP neighborship issue

Hello friends,

Need your help,

I have 6 routers configured with BGP, r1 directly connected to r2 and r3, r4 is directly connected to r2 and r3, and all are running iBGP AS 100,

where as r5 is directly connected to r3 and running eBGP(AS 200) and r6 is directly connected to r4 and running eBGP(AS 300) as well.

THE PROBLEM THAT I AM FACING IS WHEN R1 ESTABLISHES iBGP NEIGHBORSHIP WITH R4 WHICH ARE NOT DIRECTLY CONNECTED AND EVERY FEW SECONDS THE HOLD TME EXPIRES NEIGHBORSHIP IS BROUGHT DOWN, AND AGAIN IT COMES UP AND IT CONTUNES FOR EVER.

Please explain this behavoir and what extra configuration to be done to keep the iBGP neighborship between r1 and r4 permanant up.

find the attached config files and topology for ref.

Regards

  • WAN Routing and Switching
Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Purple

iBGP neighborship issue

Hi,

yes you're right you'll have to use static route.

don't forget that by default eBGP has a TTL of 1 so you'll have to use the neighbor x.x.x.x ebgp-multihop command if you're peering on the loopacks.

Don't forget to rate helpful posts.

Regards.

Alain.

Don't forget to rate helpful posts.
11 REPLIES
Hall of Fame Super Silver

iBGP neighborship issue

Hello Syed,

an IGP protocol or static routes are needed in order to be able to setup iBGP sessions between non adjacent routers.

try by adding on each router

router ospf 100

network 192.168.0.0 0.0.255.255 area 0

on all routers

this will provide the necessary IP connectivity to build the sessions

be also aware that best practice for iBGP is the use of loopback address as source and destination of the iBGP sessions

Hope to help

Giuseppe

iBGP neighborship issue

hi Giuseppe Larosa,

Thanks a lot for replying.

I was thinking when r1 knows routes to r2 and r2 knows routes to r4, and since bgp is established between them, then why the holddown timer is expiring every now and then.

so this BGP's property, if it is not learning about this network from an igp o static it will not send it to its peers. am i right.??

Hall of Fame Super Silver

Re: iBGP neighborship issue

Hello Syed,

the problem is that you would like to use iBGP sessions to also provide information about the iBGP destination addresses.

This is probably causing a consistency failure:

when iBGP session between R1-r4 is down R1 and R4 know about the iBGP endpoint of their session from the session they have with R2. So the session R1-R4 can come up.

As soon as the session between R1,R4 comes up R1 can see R4 IP address via the SAME iBGP session and this is not considered valid ( consistency check) and the session falls down.

And the cycle repeats for ever.

These are the kind of problems you face without an IGP or static routes in place :

Think of BGP sessions between not adjacent routers as user traffic as a telnet session or an ftp session: routing has to be stable and learned by an indipendent source ( static routes or IGP) in order to achieve stable sessions.

You could fix using network commands instead of redistribute connected and avoiding to have R4 to advertise R4-R2 IP subnet and R1 to advertise R1-R2 Ip subnet. However, this would not be real world just an exercise and there are only 4-6 routers involved what for an ISP with hundreds of routers?

Edit:

you have even two iBGP sessions with R4

from R4 cfg:

interface GigabitEthernet1/0

>>>>ip address 192.168.1.14 255.255.255.252

negotiation auto

!

interface GigabitEthernet2/0

ip address 10.1.1.1 255.255.255.252

negotiation auto

!

interface GigabitEthernet3/0

>>>>ip address 192.168.1.10 255.255.255.252

negotiation auto

!

and on R1 configuration:

outer bgp 100

no synchronization

bgp log-neighbor-changes

network 192.168.1.1

network 192.168.1.5

redistribute connected

neighbor 192.168.1.2 remote-as 100

neighbor 192.168.1.6 remote-as 100

>>>> neighbor 192.168.1.10 remote-as 100

>>>> neighbor 192.168.1.14 remote-as 100

no auto-summary

!

This is not the way to use iBGP.

Use loopbacks and an  IGP and you will see  a stable network scenario

you need neigh x.x.x.x update-source loop0 to use loop0 as source

only one session between each pair of nodes and so on

Hope to help

Giuseppe

iBGP neighborship issue

Hi Giuseppe,

I changed the config as adviced, i used loopbacks and an IGP(OSPF) and only one session per each pair of nodes.

lo0 as update source.

But after that all BGP neighborships went down and are in active state, can u help me here.

Purple

iBGP neighborship issue

Hi,

can you post your new configs.

Regards.

Alain

Don't forget to rate helpful posts.

iBGP neighborship issue

hi cadet,

Below are the configs, please help me with this issue.

configs for R1

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface GigabitEthernet1/0

ip address 192.168.1.5 255.255.255.252

negotiation auto

!

interface GigabitEthernet2/0

ip address 192.168.1.1 255.255.255.252

negotiation auto

!

interface GigabitEthernet3/0

no ip address

shutdown

negotiation auto

!

router ospf 1

log-adjacency-changes

network 192.168.0.0 0.0.255.255 area 0

!

router bgp 100

no synchronization

bgp log-neighbor-changes

network 192.168.1.1

network 192.168.1.5

redistribute connected

neighbor 192.168.1.2 remote-as 100

neighbor 192.168.1.2 update-source Loopback0

neighbor 192.168.1.6 remote-as 100

neighbor 192.168.1.6 update-source Loopback0

no auto-summary

!

!

====================================================================!

For R2

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface GigabitEthernet1/0

ip address 192.168.1.13 255.255.255.252

negotiation auto

!

interface GigabitEthernet2/0

ip address 192.168.1.2 255.255.255.252

negotiation auto

!

interface GigabitEthernet3/0

no ip address

shutdown

negotiation auto

!

router ospf 1

log-adjacency-changes

network 192.168.0.0 0.0.255.255 area 0

!

router bgp 100

no synchronization

bgp log-neighbor-changes

network 192.168.1.2

network 192.168.1.13

redistribute connected

neighbor 192.168.1.1 remote-as 100

neighbor 192.168.1.1 update-source Loopback0

neighbor 192.168.1.14 remote-as 100

neighbor 192.168.1.14 update-source Loopback0

no auto-summary

!

===============================================================================

For R3

!

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface GigabitEthernet1/0

ip address 192.168.1.6 255.255.255.252

negotiation auto

!

interface GigabitEthernet2/0

ip address 20.1.1.1 255.255.255.252

negotiation auto

!

interface GigabitEthernet3/0

ip address 192.168.1.9 255.255.255.252

negotiation auto

!

interface GigabitEthernet4/0

no ip address

shutdown

negotiation auto

!

router ospf 1

log-adjacency-changes

network 192.168.0.0 0.0.255.255 area 0

!

router bgp 100

no synchronization

bgp log-neighbor-changes

network 20.1.1.1

network 192.168.1.6

network 192.168.1.9

redistribute connected

neighbor 20.1.1.2 remote-as 200

neighbor 20.1.1.2 update-source Loopback0

neighbor 192.168.1.5 remote-as 100

neighbor 192.168.1.5 update-source Loopback0

neighbor 192.168.1.10 remote-as 100

neighbor 192.168.1.10 update-source Loopback0

no auto-summary

!

==================================================================

For R4

!

interface Loopback0

ip address 4.4.4.4 255.255.255.255

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface GigabitEthernet1/0

ip address 192.168.1.14 255.255.255.252

negotiation auto

!

interface GigabitEthernet2/0

ip address 10.1.1.1 255.255.255.252

negotiation auto

!

interface GigabitEthernet3/0

ip address 192.168.1.10 255.255.255.252

negotiation auto

!

interface GigabitEthernet4/0

no ip address

shutdown

negotiation auto

!

router ospf 1

log-adjacency-changes

network 192.168.0.0 0.0.255.255 area 0

!

router bgp 100

no synchronization

bgp log-neighbor-changes

network 10.1.1.1

network 192.168.1.14

network 192.168.1.19

redistribute connected

neighbor 10.1.1.2 remote-as 300

neighbor 10.1.1.2 update-source Loopback0

neighbor 192.168.1.9 remote-as 100

neighbor 192.168.1.9 update-source Loopback0

neighbor 192.168.1.13 remote-as 100

neighbor 192.168.1.13 update-source Loopback0

no auto-summary

Purple

iBGP neighborship issue

Hi,

1) your loopack interfaces must be reachable via OSPF if you want to use them for peering:

    eg on r1:

router ospf 1

network 1.1.1.1 0.0.0.0 area 0

same thing on other AS 100 routers

2) peering with r2:

  neighbor 2.2.2.2 remote-as 100

same thing for other iBGP peers

Regards.

Alain

Don't forget to rate helpful posts.

iBGP neighborship issue

Hi cadet,

Thank you for your help, successfully created iBGP full mesh.

For eBGP from R3 to R5, when i mention loopback as update source and not running any IGP, i will not have reachability for loopbacks eitherways so i think i should use static routes or is there any other alternative for this.

Please advice.

Purple

iBGP neighborship issue

Hi,

yes you're right you'll have to use static route.

don't forget that by default eBGP has a TTL of 1 so you'll have to use the neighbor x.x.x.x ebgp-multihop command if you're peering on the loopacks.

Don't forget to rate helpful posts.

Regards.

Alain.

Don't forget to rate helpful posts.
858
Views
10
Helpful
11
Replies
This widget could not be displayed.