From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Thu Nov 24 2005 - 13:51:54 GMT-3
Anthony, I've pasted in a working config at the end of this mail for what I understand you want to achieve.
In fact what you describe is the way internetworks were originally intended to be run with BGP only at the edges. Network designers thougt to tunnel between edge devices. However back then the processing cost of tunneling was too great for software based routers and BGP ended up being needed on all transit devices to stop black-holing. Now the processing cost of tunneling has gone away with hardware implementations of MPLS and L2TPv3 tunneling, BGP free cores are gaining popularity with designers. Anyway, I digress.
I have the following setup
R4------R1----R2-----R3
R4 is eBGP to R1 and R1 is iBGP to R3. R2 has no BGP.
R4 injects the prefix 172.16.4.0 in to BGP and has the loopback 172.16.4.4
R2 has no knowledge of this route and R3 is able to ping it via a tunnel.
I think the key issues to consider are the following
With next-hop-self on R1, R3 will see the next hop for 172.16.4.0 as R1, we want R3 then to route towards R1 via the tunnel created between R1 and R3. However we do not want R3 to see other destinations via the tunnel, as you could then run in to route recursion issues and the tunnel would come down. In this example, I have auto-summary on for eigrp, so the 1.1.1.0 learned via the tunnel; is the longest path match for 1.1.1.1, but if auto-summary was off, you would have to mess with metrics or filtering to get the route to 1.1.1.1 preferred via the tunnel.
The following are good guidelines (pased to my by Tinjin Chang) for creating stable tunnels that have never let me down.
[TC begins]
You need to worry about "ip unnumbered" only if you are told that you couldn't add another address/subnet. The highlights assume that we are tunnelling OSPF across an IS-IS only part of the network. But these concepts apply even if you are tunnelling OSPF across OSPF.
1) The interface that you are going to reference in "ip unnumbered"
a) these interfaces must belong to the SAME OSPF area on both routers
If you're going to use the loopback0s, for example, then these two routers'
loopback0s must be in the same area or OSPF won't work correctly.
2) The tunnel source
a) must be reachable prior to the tunnel going up
b) the far end must NOT learn this route via OSPF inside the tunnel
i) use distance or distribute-list, depending on the requirements
3) The tunnel destination
a) must be reachable prior to the tunnel going up
b) the local router must NOT learn this route via OSPF inside the tunnel
i) use distance or distribute-list, depending on the requirements
4) The tunnel mode
a) Your choices are gre, ipip, and nos
[TC ends]
Once you have a stable tunnel, the routing table on R3 should look like this
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 1.1.1.0/24 [90/297372416] via 1.1.1.1, 00:18:41, Tunnel0
D 1.0.0.0/8 [90/2300416] via 4.4.12.2, 00:21:26, FastEthernet0/0
D 2.0.0.0/8 [90/156160] via 4.4.12.2, 00:18:41, FastEthernet0/0
3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 3.3.3.0/24 is directly connected, Loopback0
D 3.0.0.0/8 is a summary, 00:18:41, Null0
4.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 4.4.4.0/24 [200/0] via 1.1.1.1, 00:15:36
D 4.0.0.0/8 is a summary, 00:22:05, Null0
D 4.4.8.0/24 [90/2172416] via 4.4.12.2, 00:18:43, FastEthernet0/0
C 4.4.12.0/24 is directly connected, FastEthernet0/0
D 4.4.14.0/24 [90/2174976] via 4.4.12.2, 00:18:43, FastEthernet0/0
172.16.0.0/24 is subnetted, 1 subnets
B 172.16.4.0 [200/0] via 1.1.1.1, 00:15:37
The routing table on R2 has no 172.16.0.0
R2#sho ip rout 172.16.0.0
% Network not in table
R2#
R3 can ping 172.16.4.4 via the tunnel to R1
R3(config-router)#do ping 172.16.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/69/72 ms
R3#trace 172.16.4.4
Type escape sequence to abort.
Tracing the route to 172.16.4.4
1 1.1.1.1 40 msec 40 msec 44 msec
2 4.4.14.4 40 msec * 44 msec
These are all configs for router 1 through 4
R1
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface Tunnel0
ip unnumbered Loopback0
tunnel source 4.4.8.1
tunnel destination 4.4.12.3
!
interface Serial0/0
ip address 4.4.8.1 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
frame-relay map ip 4.4.8.2 122 broadcast
no frame-relay inverse-arp
!
interface FastEthernet0/1
ip address 4.4.14.1 255.255.255.0
!
router eigrp 1
network 1.0.0.0
network 4.0.0.0
auto-summary
!
router bgp 13
no synchronization
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 13
neighbor 3.3.3.3 update-source Loopback0
neighbor 3.3.3.3 next-hop-self
neighbor 4.4.14.4 remote-as 4
no auto-summary
R2
interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
ip address 4.4.12.2 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
ip address 4.4.8.2 255.255.255.0
encapsulation frame-relay
ip ospf network broadcast
ip ospf priority 0
frame-relay map ip 4.4.8.1 221 broadcast
no frame-relay inverse-arp
!
router eigrp 1
network 2.0.0.0
network 4.0.0.0
auto-summary
R3
interface Loopback0
ip address 3.3.3.3 255.255.255.0
!
interface Tunnel0
ip unnumbered Loopback0
tunnel source 4.4.12.3
tunnel destination 4.4.8.1
!
interface FastEthernet0/0
ip address 4.4.12.3 255.255.255.0
!
router eigrp 1
network 3.0.0.0
network 4.0.0.0
auto-summary
!
router bgp 13
no synchronization
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 1.1.1.1 remote-as 13
neighbor 1.1.1.1 update-source Loopback0
no auto-summary
R4
interface Loopback0
ip address 4.4.4.4 255.255.255.0
!
interface Loopback1
ip address 172.16.4.4 255.255.255.0
!
router bgp 4
no synchronization
bgp log-neighbor-changes
network 4.4.4.0 mask 255.255.255.0
network 172.16.4.0 mask 255.255.255.0
neighbor 4.4.14.1 remote-as 13
no auto-summary
Anthony Sequeira <terry.francona@gmail.com> wrote:
I want to tunnel my iBGP peering from R1 to R4 because R2 is not running
BGP. I want to use the loopback 0 interfaces for the peerings. The IGP in
use is EIGRP and all of the interfaces shown below are running EIGRP.
R1-----4.4.8.0/24-----R2-----4.4.12.0/24-----R4
R1 lo0 4.4.1.1/24
R4 lo0 4.4.4.4/24
I have this sample scenario labbed up and I am having a heck of a time. I
have tried the following with no luck:
Attempt 1
R1:
int tunnel 0
ip unnumbered lo0
tunnel source 4.4.8.1
tunnel destination 4.4.12.4
R2:
int tunnel 0
ip unnumbered lo0
tunnel source 4.4.12.4
tunnel destination 4.4.8.1
Attempt 2
R1:
int tunnel 0
ip unnumbered lo0
tunnel source lo0
tunnel destination 4.4.4.4
R2:
int tunnel 0
ip unnumbered lo0
tunnel source lo0
tunnel destination 4.4.1.1
You see this is easy and works great if I create a new subnet for the
tunnel and use that in my BGP peerings the issue that I am having is
trying to use the loopback addresses for the peerings and still use my
tunnel.
I notice that my tunnel interface does not show up in the routing table when
I am pulling the address from the loopback..I guess this must be why my BGP
is not using it????
Anyone feel like labbing this one up and trying this one? Or is it something
really simple that I am missing about tunnels?
Thanks in advance for you consideration of this e-mail.
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:07 GMT-3