From: Venkataramanaiah.R (vramanaiah@gmail.com)
Date: Thu Nov 24 2005 - 15:08:18 GMT-3
The other two options that i can think of for stable tunnels are (I
have not tested them though)
1) Use static route on either side pointing to the tunnel i/f for the
IP unnumbered addresses on the opposite side.
2) Do not include the ipunnumbered i/fs in your native routing
protocol. Just run another routing protocol just for the ipunnumbered
i/fs. (Good choice, If static is prohibited)
Regards
-Venkat
PS - Anthony, for ur requirement, i suggest you to try the second
option with simple RIP on unnumbered. If you choose to retain the
loopback on native protocol as well, just reduce the distance on the
new routing protocol to a lesser value..this will force you to route
to the other RP via the tunnel..
On 11/24/05, Chris Lewis <chrlewiscsco@yahoo.com> wrote:
> 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.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
> ---------------------------------
> Yahoo! DSL Something to write home about. Just $16.99/mo. or less
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:07 GMT-3