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:
I realise this is normal behaviour, but I need to understand why it is.
Thanks.
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.
Comments
-
jason_lunde
Member Posts: 567
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
Member Posts: 201
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 i172.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:57CustRtr#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 i172.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/0ISP#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
Member Posts: 428
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
Member Posts: 201
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
Member Posts: 201
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.
