From: Niche (jackyliu419@gmail.com)
Date: Fri Nov 25 2005 - 04:15:22 GMT-3
Hi Guys,
Just want to ask some additional information about tunnel in this scenario.
I have been told by a friend about a year ago that using tunnel for this
kind of implementation usually result in unstable tunnel flapping due to
large bandwidth passing through. It's more common when the bandwidth that is
required to be tunnelled over a certain amount (let's say 10Mb+). I haven't
get a chance to see this in production environment (we don't do transit).
Would anyone can share any insight in this issue?
Best Regards,
Jacky
On 11/25/05, Chris Lewis <chrlewiscsco@yahoo.com> wrote:
>
> So using the setup I sent you, I have now changed the loopback for my R1
> to 4.4.1.1 and my R3 (which is performing the same role in the network to
> your R4). Once I do this, the auto-summary that I am using to give the
> longest path match to the loopback of R1 disappears from the scene and R3
> now does not see the tunnel as the best route to the loopback of R1, it
sees
> R2, so my ping to the 172.16.4.4 nework no longer works, as R3 will route
> directly to R2 to ping the 172.16.4.4 address and R2 does not have that
> address.
>
> If I look at the eigrp topolgy table, I see the following
>
> P 4.4.1.0/24, 1 successors, FD is 2300416
> via 4.4.12.2 (2300416/2297856), FastEthernet0/0
> via 4.4.1.1 (297372416/128256), Tunnel0
>
> I now have several options, I can fix things by eliminating the route to
> 4.4.1.0 via Fa0/0, using distance, filtering or giving it an infinite
> metric, or I can keep the both paths in the topology (maybe a requirement
of
> a question would mandate this) andmake the tunnel 0 interface more
> attractive to EIGRP and therefore decide to route to 4.4.1.0 by the tunnel
> interface. THe simplest way to do this is via the offset-list
>
> R3(config-router)#offset-list 1 in 300000000 f0/0
> R3(config-router)#do clear ip eigrp nei
>
> I now see the following in the routing table of R3 and am able to ping
> the external 172.16.4.4 network.
>
>
> D 2.0.0.0/8 [90/156160] via 4.4.12.2, 00:00:03, FastEthernet0/0
> 4.0.0.0/24 is subnetted, 6 subnets
> D 4.4.1.0 [90/297372416] via 4.4.1.1, 00:00:03, Tunnel0
> C 4.4.3.0 is directly connected, Loopback0
>
> So the only changes I made from the configs I posted last time were to
> change the loopbacks of the two iBGP speakers to the ones you are using,
> then change the metrics so that the route to the new loopback address of R1
> is via the tinnel.
>
> Chris
> Anthony Sequeira <terry.francona@gmail.com> wrote:
> 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 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 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 * 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.com/broadband/+%0D%0A>Something to write home about. Just $16.99/mo.
> or less
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________________________________
> 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