cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
448
Views
0
Helpful
7
Replies

iBGP:Please help fix this minor reachability issue

news2010a
Level 3
Level 3

Hi, can you help me here:

From R1 (AS 100), I can see route to 204.12.19.254 (AS 54) as shown in blue just below.

From R4 I can ping 204.12.19.254 OK.

From R4 I can ping R1 (155.19.146.1) OK.

Question:
What would be the cleanest way to make R1 able to ping 204.12.19.254? I see that 204.12.19.254 does not know how to get to R1, that is probably why ping fails from R1.

Note that I cannot make changes on 204.12.19.254. I see that the router is running RIP.

I see that R4 is learning route to 204.12.19.254 via connected. Do I need to do redistribution of connected into IGP in this case?

Rack19R1#show ip bgp 204.12.19.254
BGP routing table entry for 204.12.19.0/24, version 60
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1          2
  Local, (Received from a RR-client)
    155.19.146.4 from 155.19.146.4 (150.19.4.4)
      Origin IGP, metric 0, localpref 100, valid, internal, best
Rack19R1#show run | s eigrp
router eigrp 100
network 155.19.0.0
no auto-summary
Rack19R1#show run | s bgp
router bgp 100
no synchronization
bgp cluster-id 150.19.1.1
bgp log-neighbor-changes
network 150.19.1.0 mask 255.255.255.0
neighbor 155.19.0.5 remote-as 100
neighbor 155.19.13.3 remote-as 100
neighbor 155.19.146.4 remote-as 100
neighbor 155.19.146.4 route-reflector-client
neighbor 155.19.146.6 remote-as 100
neighbor 155.19.146.6 route-reflector-client
no auto-summary
Rack19R1#

R4
!
router eigrp 100
network 155.19.0.0
no auto-summary
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 150.19.4.0 mask 255.255.255.0
network 204.12.19.0
neighbor 155.19.0.1 remote-as 100
neighbor 155.19.0.2 remote-as 100
neighbor 155.19.0.3 remote-as 100
neighbor 155.19.0.5 remote-as 100
neighbor 155.19.58.8 remote-as 100
neighbor 155.19.67.7 remote-as 100
neighbor 155.19.79.9 remote-as 100
neighbor 155.19.108.10 remote-as 100
neighbor 155.19.146.1 remote-as 100
neighbor 155.19.146.1 next-hop-self
neighbor 155.19.146.6 remote-as 100
neighbor 204.12.19.254 remote-as 54
no auto-summary
!

Rack19R4#ping 155.19.146.1

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


Rack19R4#ping 204.12.19.254

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

1 Accepted Solution

Accepted Solutions

Jerry Ye
Cisco Employee
Cisco Employee

If you source the ping from 150.19.1.x, it should work.

Another way to do it is advertise 155.19.146.x network into BGP via network statement. Like

! R4

router bgp 100

network 155.19.146.0 mask 255.255.255.0

Regards,

jerry

View solution in original post

7 Replies 7

Jerry Ye
Cisco Employee
Cisco Employee

If you source the ping from 150.19.1.x, it should work.

Another way to do it is advertise 155.19.146.x network into BGP via network statement. Like

! R4

router bgp 100

network 155.19.146.0 mask 255.255.255.0

Regards,

jerry

Just after sending this post I tried on R4 'redistributed connected' and obviously that did it. Yes, I wanted to double check the cleanest way to do that though and analyze all options.

This is not an issue related to next-hop-self since that was fixed already before. 


Thanks all.

I didn't suggest 'next-hop-self' again. My suggestion (in this thread) was redistribution of connected in addition to next-hop-self you already had in place. However, right now I stand here unable to understand why redistribution fixed this! Better luck after I get some sleep!

Edit: You probably meant it solved the old issue and not the one on this thread.

marikakis
Level 7
Level 7

If I understand correctly, this conversation is closely related to another one you had opened a day or so ago. I had suggested there either usage of next-hop-self or redistribution of connected into IGP. Redistribution of connected subnets of external connections is preferred over next-hop-self exactly in the case where you want to be able to ping the external subnet or do other network management procedures. You do not need to change the configuration of a router outside the local AS for this to happen. You redistribute connected (subnets) at the border router of the local AS that has the subnet of the external connection directly attached (that is R4 I think).

Edit: I think I missed something, so I will read this thread again.

Please disregard my previous post. I obviously missed something that was highlighted with blue!

Maria,

By looking at his config, I think he is studying his CCIE with INE's workbook. I agree with your solution completely, but sometime you are restricted on what commands you can do and fix it with whatever you are allowed to. Knowing multiple ways to do thing is part of the objective of the study.

Regards,

jerry

Hi Jerry,

My solution would be correct if only R1 didn't already have that subnet via BGP! So the problem must be somewhere else. An issue with the routing of ping source address (as you suggested) through the network is more possible. By the way, I prefer traceroute than ping in routing issue troubleshooting and in general.

Kind Regards,

Maria

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: