BGP Source address

Hi guys,

I'm having a moment of confusion.

I'm currently working through the ROUTE Lab Manual and I've just finished Lab 6-2. The lab uses BGP between 3 routers and is almost identical to the lab in the BSCI version of this book.

Basically, there is a part of the lab that asks you to ping the loopback interface on R3 from R1. The ping doesn't work. However, when you change the source address of the ping it does work.

The loopback on R3 is 10.3.3.1.

Output from R1:

SanJose#show ip bgp
BGP table version is 8, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
*> 10.2.2.0/24      192.168.1.6              0             0 300 i
*> 10.3.3.0/24      192.168.1.6                            0 300 i

     10.0.0.0/24 is subnetted, 3 subnets
B       10.3.3.0 [20/0] via 192.168.1.6, 00:22:51
B       10.2.2.0 [20/0] via 192.168.1.6, 00:22:13
C       10.1.1.0 is directly connected, Loopback0
     192.168.1.0/30 is subnetted, 1 subnets
C       192.168.1.4 is directly connected, Serial0/0

SanJose#show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES unset  administratively down down    
Serial0/0                  192.168.1.5     YES manual up                    up      
FastEthernet0/1            unassigned      YES unset  administratively down down    
Serial0/1                  unassigned      YES unset  administratively down down    
Loopback0                  10.1.1.1        YES manual up                    up

I realise this is normal behaviour, but I need to understand why it is.

Thanks.

Find more posts tagged with

Comments

jason_lunde

sorry, whats the other router look like? I would assume its working when you source with your loopback correct?

I you really want to see whats happening go to R3 and give it a debug ip icmp...that will tell you 1)if the packets even get there, and 2) what the source and destination ip's look like.

mattrgee

Router 3 (CustRtr) output:

CustRtr#show ip bgp                                                    
BGP table version is 8, local router ID is 10.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      172.24.1.17                            0 300 100 i
*> 10.2.2.0/24      172.24.1.17              0             0 300 i
*> 10.3.3.0/24      0.0.0.0                  0         32768 i

     172.24.0.0/30 is subnetted, 1 subnets
C       172.24.1.16 is directly connected, Serial0/1
     10.0.0.0/24 is subnetted, 3 subnets
C       10.3.3.0 is directly connected, Loopback0
B       10.2.2.0 [20/0] via 172.24.1.17, 00:04:27
B       10.1.1.0 [20/0] via 172.24.1.17, 00:04:57

CustRtr#show ip int brief 
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  administratively down down    
Serial0/0                  unassigned      YES NVRAM  administratively down down    
FastEthernet0/1            unassigned      YES NVRAM  administratively down down    
Serial0/1                  172.24.1.18     YES NVRAM  up                    up      
Loopback0                  10.3.3.1        YES NVRAM  up                    up

And Router 2's output which connects R1 and R3:

ISP#show ip bgp
BGP table version is 4, local router ID is 10.2.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      192.168.1.5              0             0 100 i
*> 10.2.2.0/24      0.0.0.0                  0         32768 i
*> 10.3.3.0/24      172.24.1.18              0             0 65000 i

     172.24.0.0/30 is subnetted, 1 subnets
C       172.24.1.16 is directly connected, Serial0/1
     10.0.0.0/24 is subnetted, 3 subnets
B       10.3.3.0 [20/0] via 172.24.1.18, 00:10:08
C       10.2.2.0 is directly connected, Loopback0
B       10.1.1.0 [20/0] via 192.168.1.5, 00:10:08
     192.168.1.0/30 is subnetted, 1 subnets
C       192.168.1.4 is directly connected, Serial0/0

ISP#show ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            unassigned      YES NVRAM  administratively down down    
Serial0/0                  192.168.1.6     YES NVRAM  up                    up      
FastEthernet0/1            unassigned      YES NVRAM  administratively down down    
Serial0/1                  172.24.1.17     YES NVRAM  up                    up      
Loopback0                  10.2.2.1        YES NVRAM  up                    up

Ryan82

It won't work when you run a ping from San Jose to Cust RTR because Cust RTR has no route to 192.168.1.5. Check out this output:

San_Jose#ping 10.3.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.1, timeout is 2 seconds:
*Dec 10 18:13:24.531: IP: tableid=0, s=192.168.1.5 (local), d=192.168.1.6 (Serial1/0), routed via FIB
*Dec 10 18:13:24.535: IP: s=192.168.1.5 (local), d=192.168.1.6 (Serial1/0), len 59, sending
*Dec 10 18:13:24.583: IP: s=192.168.1.6 (Serial1/0), d=192.168.1.5, len 59, rcvd 0
*Dec 10 18:13:24.783: IP: tableid=0, s=192.168.1.5 (local), d=192.168.1.6 (Serial1/0), routed via FIB
*Dec 10 18:13:24.783: IP: s=192.168.1.5 (local), d=192.168.1.6 (Serial1/0), len 40, sending
*Dec 10 18:13:25.215: IP: tableid=0, s=192.168.1.5 (local), d=10.3.3.1 (Serial1/0), routed via FIB

San Jose knows how to get there and routes it.

But if we go over to Cust Rtr:

Dec 10 18:17:53.331: IP: s=10.3.3.1 (local), d=192.168.1.5, len 100, unroutable
Cust_RTR#
*Dec 10 18:17:55.255: IP: tableid=0, s=192.168.1.5 (Serial1/0), d=10.3.3.1 (Loopback0), routed via RIB
*Dec 10 18:17:55.255: IP: s=192.168.1.5 (Serial1/0), d=10.3.3.1, len 100, rcvd 4
*Dec 10 18:17:55.259: IP: s=10.3.3.1 (local), d=192.168.1.5, len 100, unroutable
Cust_RTR#
*Dec 10 18:17:57.287: IP: tableid=0, s=192.168.1.5 (Serial1/0), d=10.3.3.1 (Loopback0), routed via RIB
*Dec 10 18:17:57.287: IP: s=192.168.1.5 (Serial1/0), d=10.3.3.1, len 100, rcvd 4
*Dec 10 18:17:57.291: IP: s=10.3.3.1 (local), d=192.168.1.5, len 100, unroutable
Cust_RTR#

But if we source it from Loopback 0 on San Jose (10.1.1.1)

As we can see from the sh ip BGP on Cust Rtr, he knows about the 10.1.1.0 network:

Cust_RTR#sh ip bgp
BGP table version is 3, local router ID is 10.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 172.24.1.17 0 300 100 i
*> 10.3.3.0/24 0.0.0.0 0 32768 i

And the ping works:

Cust_RTR#
*Dec 10 18:19:40.539: IP: tableid=0, s=172.24.1.18 (local), d=172.24.1.17 (Serial1/0), routed via FIB
*Dec 10 18:19:40.543: IP: s=172.24.1.18 (local), d=172.24.1.17 (Serial1/0), len 59, sending
*Dec 10 18:19:40.579: IP: s=172.24.1.17 (Serial1/0), d=172.24.1.18, len 59, rcvd 0
*Dec 10 18:19:40.779: IP: tableid=0, s=172.24.1.18 (local), d=172.24.1.17 (Serial1/0), routed via FIB
*Dec 10 18:19:40.779: IP: s=172.24.1.18 (local), d=172.24.1.17 (Serial1/0), len 40, sending

mattrgee

jason_lunde wrote: »

sorry, whats the other router look like? I would assume its working when you source with your loopback correct?

I you really want to see whats happening go to R3 and give it a debug ip icmp...that will tell you 1)if the packets even get there, and 2) what the source and destination ip's look like.

Yes that's right.

When I ping from SanJose using the 192.168.1.5 as the source it fails, use the loopback 10.1.1.1 and it works.

I made a mistake when posting the configs for router 3 (CustRtr) the version I posted was later in the lab when filtering was configured. I've edited the post to include the right configs now. Router 3 (CustRtr) now has a route back to 10.1.1.1, however the same behaviour occurs.

mattrgee

Ryan82 wrote: »

It won't work when you run a ping from San Jose to Cust RTR because Cust RTR has no route to 192.168.1.5.

Thanks Ryan. The metaphorical penny has just dropped. I was concentrating on whether the source had a route to the destination and forgetting about the return traffic. Silly me.

Ryan82

No worries. Good luck on that test, its a beast!