BGP and the NETWORK statement

[riedmueller]

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 20.0.0.1 remote-as 65000

network 172.16.1.0 mask 255.255.255.0

no auto-summary

Core config:

router bgp 65000

nei 20.0.0.2 remote-as 65012

nei 20.0.0.9 remote-as 65034

netw 172.16.0.0 mask 255.255.255.0

no auto-summ

Router 3:

router bgp 65034

nei 20.0.0.10 remote-as 65000

netw 172.16.3.0 mask 255.255.255.0

no auto-summ

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

[Giuseppe Larosa · Accepted solution]

Hello James,

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

R1# 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

Giuseppe

[riedmueller]

Giuseppe,

Of Course! B/C the 20.0.0.x network isn't in anyone's *routing* table, the router can't route to it.

All this would have been invisible if'd i'd been using host workstations. Then again, if I had I wouldn't have had this fundamental thing reinforced.

Thanks!