I'm trying to implement a transit AS in a lab and I had to use the NETWORK command more than I thought I needed to...
R1 - Core - R3 , directly connected via serial. Each router has a loopback address to use as a ping target...
R1 config is
router bgp 65012
neighbor 188.8.131.52 remote-as 65000
network 172.16.1.0 mask 255.255.255.0
router bgp 65000
nei 184.108.40.206 remote-as 65012
nei 220.127.116.11 remote-as 65034
netw 172.16.0.0 mask 255.255.255.0
router bgp 65034
nei 18.104.22.168 remote-as 65000
netw 172.16.3.0 mask 255.255.255.0
This seems to work just dandy -- all the 172.16's show up in the BGP and IP Routing tables with the proper weights, origin codes, metrics, next-hops, and AS Paths.
BUT -- when I try to PING from R1 to R3, it fails!! R1 to Core, R3 to Core (and obviously Core to R1 or R3) works fine, but across the core it will not work..just get timeouts.
I added a NETWORK statement at the Core router for each of the serial interfaces, and it suddenly works. No changes at all (that I could see) to the BGP or Routing tables. I swapped it around and put the NETWORK statement for the serial circuits at R1 and R3 and took them off of the CORE, cleared BGP everywhere, and after convergence, it works again.
So -- why do I have to put that NETWORK statement in?
From R1 to R3, the identified next hop is the Serial IF on CORE. I thought that once CORE received the packet, it would do a lookup and find the appropriate exit interface and send the ping on it's way. Or am I missing a disconnect between the BGP and routing tables and the lookup process?
thanks in advance for any ideas/assistance
the ICMP request from R1 to R3 has an ip source=ip address of interface to destination.
So the ping fails if your network statements are for R1:lan and for R3:lan
Core router knows how to answer because both serial interfaces are connected to it
you can see this using an extended ping
then choice as a source ip address in net 172.16.1.0/24 it will work even without the network commands for the two serial lines.
We can say that this is not a BGP issue, icmp is successful if both icmp request and icmp reply can be routed successfully
Hope to help