From: Anthony Sequeira (terry.francona@gmail.com)
Date: Thu Nov 24 2005 - 14:39:13 GMT-3
Damn - now I am running int recursive issues when I try filtering the
loopbacks in EIGRP.....Chris - care to try it again using MY EXACT
addressing????
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
On 11/24/05, Anthony Sequeira <terry.francona@gmail.com> wrote:
>
> Hi Chris - yeah - I think for my example I am going to need to mess with
> metric or filtering to get the tunnel to be used.
>
> I am using loopbacks that are all in the same major network. You "cheated"
> a bit and used 1.1.1.1 and 3.3.3.3 on these routers....but you have me
> thinking in the right direction now for sure - I need to figure out how to
> get the tunnel to be used without breaking anything else. I think metric
> manipulation or filtering must be the key!
>
>
> 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.0learned 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<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=37474/*http://promo.yahoo
.com/broadband/+%0D%0A>Something to write home about. Just $16.99/mo. or less
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:07 GMT-3