iBGP:Please help fix this minor reachability issue

[news2010a]

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

[Jerry Ye · Accepted solution]

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

[news2010a]

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.

[marikakis]

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]

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.

[marikakis]

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

[Jerry Ye]

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

[marikakis]

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