MP-BGP is not coming UP

Answered Question
Dec 1st, 2009

Hi all,

My MP-BGP is not coming up between two routers. attaching the config from both end and also debug mesage along with status of bgp and ping response

Please help

-------------------------------------------------------------------------------

-----------A-End------------------

router bgp 9730
bgp router-id 10.7.104.181
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.7.104.183 remote-as 9730
neighbor 10.7.104.183 update-source Loopback0
!
address-family vpnv4
neighbor 10.7.104.183 activate
neighbor 10.7.104.183 send-community extended
bgp dampening
exit-address-family

debug message:

3w0d: BGP: 10.7.104.183 open failed: Connection timed out; remote host not responding, open active delayed 34814ms (35000ms max, 28% jitter)

NDL-ADR-ACC-RTR-181#ping 10.7.104.183

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.7.104.183, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

NDL-ADR-ACC-RTR-181#sh ip bgp vpnv4 all summary | inc 10.7.104.183
10.7.104.183    4  9730       0       0        0    0    0 never    Active

------------B-End------------------

router bgp 9730
bgp router-id 10.7.104.183
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.7.104.181 remote-as 9730
neighbor 10.7.104.181 update-source Loopback0
!
address-family vpnv4
neighbor 10.7.104.181 activate
neighbor 10.7.104.181 send-community extended
bgp dampening
exit-address-family


*Dec  1 19:48:06.884: BGP: 10.7.104.181 open failed: Connection timed out; remote host not responding, open active delayed 31324ms (35000ms max, 28% jitter)

GGN-ADR-COR-ACC-RTR-183#ping 10.7.104.181

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.7.104.181, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

GGN-ADR-COR-ACC-RTR-183#sh ip bgp vpnv4 all summary | inc 10.7.104.181
10.7.104.181    4  9730       0       0        0    0    0 never    Active

I have this problem too.
0 votes
Correct Answer by jcozzupoli about 7 years 1 week ago

Hi,

Well looking at your output....look at the route to the Loopbacks:

GGN-ADR-COR-ACC-RTR-183#sh ip route 10.7.104.181
Routing entry for 10.7.104.181/32
  Known via "isis", distance 115, metric 30, type level-2
Redistributing via isis, bgp 9730
  Advertised by bgp 9730 level-2
  Last update from 10.7.104.133 on FastEthernet3/0, 00:08:51 ago
  Routing Descriptor Blocks:
  * 10.7.104.133, from 10.7.104.181, via FastEthernet3/0
      Route metric is 30, traffic share count is 1

GGN-ADR-COR-ACC-RTR-183

NDL-ADR-ACC-RTR-181#sh ip route 10.7.104.183
Routing entry for 10.7.104.183/32
  Known via "isis", distance 115, metric 40, type level-2
  Redistributing via isis
  Last update from 10.7.104.161 on GigabitEthernet0/3.155, 00:11:29 ago
  Routing Descriptor Blocks:
  * 10.7.104.161, from 10.7.104.183, via GigabitEthernet0/3.155
      Route metric is 40, traffic share count is 1

NDL-ADR-ACC-RTR-181#

On B-End router can you please do the following:

traceroute 10.7.104.181 using source lo0

sh ip cef exact-route 10.7.104.183 10.7.104.181

Please make sure all your configs are consistant and cleaned up, they look very dirty and non-standard. Maybe you can try using the connecting interfaces as your BGP peering source interfaces, instead of Lo0.

Regards,

Joe.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Nagendra Kumar ... Tue, 12/01/2009 - 21:46

Hi,

Can you confirm if the below is correct,

Loopback0 address in A --> 10.7.104.181

Loopback0 address in B --> 10.7.104.183

Also check if you have any ACL cofigured on your outgoing interface?.

It would be better if you can copy the full config of both routers.

Regards,

Nagendra

jcozzupoli Wed, 12/02/2009 - 05:27

Hi,

What is the status of your IS-IS Adjacencies? Are they formed between the 2 loopbacks? Please do the following:

show ip route

show isis neighbor detail

show clns neighbor detail

show isis database

show isis topology

show ip interface

Also, I see in A-End router under the ISIS process configuration there are a few differences to the B-End:

A-END:

router isis
net 49.0001.0100.0710.4181.00
metric-style wide
no hello padding
log-adjacency-changes
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-2

B-END:

router isis
net 49.0001.0100.0710.4183.00
is-type level-2-only
metric-style wide
no hello padding point-to-point
log-adjacency-changes
redistribute static ip
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-2

These configs are very messy! Looks like Fa2/0 on B router and Gi3/0 on A router are the connecting inerfaces. However, on B router you have "ip ospf message-digest-key 1 md5 koko" configured on Fa2/0 and "clns mtu 1400" but on A router you have interface mtu set to 9612. Please make sure they match and remove the ip ospf md5 commands off Fa2/0 on B router.

Are there any devices in between that you manage and have access to?

Do you have a network diagram you can share?

Once you answer/rectify above, please advise and post accordingly

Regards,

Joe.

Laurent Aubert Wed, 12/02/2009 - 09:42

Hi,

What's the result of ping 10.7.104.183 source loopback0 on router A ?

Thanks

Laurent.

jcozzupoli Wed, 12/02/2009 - 14:28

Hi,


Yeah do a ping with Lo0 source as well, like Laurent said!


Also, are any other of the Peers up at all?


Cheers,

Joe.

mahesh-gohil Thu, 12/03/2009 - 03:42

well guys

regret for late reply

i am able to ping both end with source, attaching some output as required, moreover having one more router in between(cojfig attached for reference)

GGN-ADR-COR-ACC-RTR-183#ping 10.7.104.181 source 10.7.104.183

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.7.104.181, timeout is 2 seconds:
Packet sent with a source address of 10.7.104.183
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

NDL-ADR-ACC-RTR-181#ping 10.7.104.183 source 10.7.104.181

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.7.104.183, timeout is 2 seconds:
Packet sent with a source address of 10.7.104.181
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/32 ms

Correct Answer
jcozzupoli Thu, 12/03/2009 - 05:09

Hi,

Well looking at your output....look at the route to the Loopbacks:

GGN-ADR-COR-ACC-RTR-183#sh ip route 10.7.104.181
Routing entry for 10.7.104.181/32
  Known via "isis", distance 115, metric 30, type level-2
Redistributing via isis, bgp 9730
  Advertised by bgp 9730 level-2
  Last update from 10.7.104.133 on FastEthernet3/0, 00:08:51 ago
  Routing Descriptor Blocks:
  * 10.7.104.133, from 10.7.104.181, via FastEthernet3/0
      Route metric is 30, traffic share count is 1

GGN-ADR-COR-ACC-RTR-183

NDL-ADR-ACC-RTR-181#sh ip route 10.7.104.183
Routing entry for 10.7.104.183/32
  Known via "isis", distance 115, metric 40, type level-2
  Redistributing via isis
  Last update from 10.7.104.161 on GigabitEthernet0/3.155, 00:11:29 ago
  Routing Descriptor Blocks:
  * 10.7.104.161, from 10.7.104.183, via GigabitEthernet0/3.155
      Route metric is 40, traffic share count is 1

NDL-ADR-ACC-RTR-181#

On B-End router can you please do the following:

traceroute 10.7.104.181 using source lo0

sh ip cef exact-route 10.7.104.183 10.7.104.181

Please make sure all your configs are consistant and cleaned up, they look very dirty and non-standard. Maybe you can try using the connecting interfaces as your BGP peering source interfaces, instead of Lo0.

Regards,

Joe.

Laurent Aubert Thu, 12/03/2009 - 06:41

Hi,

I agree with Joe, going back to a minimum configuration is helpful to narrow down the issue.

Also what you can try is to run the following debug on both routers to see how the BGP messages are exchanged:

debup ip bgp

Thanks

Laurent.

mahesh-gohil Thu, 12/03/2009 - 22:48

Hi all,

Now bgp is up after removing below command

ip tcp path-mtu-discovery

181#sh ip bgp vpnv4 all summary | inc 10.7.104.183
10.7.104.183    4  9730      57      74       31    0    0 00:15:28        4

thank you all for your valuable inputs

regards

mahesh

jcozzupoli Fri, 12/04/2009 - 16:58

Hi,

Yes that makes alot of sense, seeing as there were mixed MTU values on the devices in question. This should be a lesson in keeping configs clean and having a structured approach to troubleshooting.

Cheers,

Joe.

P.S. Thanks for the vote.

Actions

This Discussion