Re: NLSP/IPXWAN and IP---Big time issue for Pre-November folks-

From: Chris Hugo (chrishugo@yahoo.com)
Date: Sun Oct 13 2002 - 17:06:40 GMT-3


Hi Folks
One thing is different. The neighbor of the config shown previously running IGRP is passive on all interfaces except the ethernet interface which emits one /25. My other concern is that when binding the tunnel to a loopback interface it seems that the tunnel is a lot more reliable and consistent in most aspects. OK I am not talking about redundant paths (reachability issues) through the same router in general. But since a good friend of mine suggested the use of terminating tunnels at the interface level I have been running into instabilities with the GRE tunnel. So I resorted back to using loopbacks and the tunnel encapsulates traffic without a hitch. Could it be that I am missing a KEY here. Bug.
any info needed.
chris hugo
  
 Chris Hugo <chrishugo@yahoo.com> wrote: Hi Mr. Nick,
No just the one tunnel is NLSP with ipxwan. The physical interface is Ethernet and running ip only.
thanks bud,
chris hugo
This config is working by the way.
Here is the config. Other router is mirror. I did a snip-snip so you can see the big picture. I also discovered another caveat. But one thing at a time :)
ipx routing 0003.0003.0003
ipx internal-network AAAAAAAA
interface Loopback0
ip address 10.3.3.3 255.255.255.0
ip ospf network point-to-point
ipx network 3A
!
interface Loopback1
ip address 172.16.30.3 255.255.252.0
ip ospf network point-to-point
interface Tunnel0
ip address 172.16.132.3 255.255.252.0
tunnel source 10.3.3.3
tunnel destination 172.16.40.1
!
interface Tunnel1
ip address 172.16.200.3 255.255.255.0
tunnel source Ethernet0
tunnel destination 172.16.34.4
!
interface Tunnel2
no ip address
ipx ipxwan 0 unnumbered ee
ipx nlsp enable
ipx nlsp rip off
ipx nlsp sap off
tunnel source 172.16.30.3
tunnel destination 172.16.40.1
!
interface Ethernet0
ip address 172.16.34.3 255.255.255.128
ip ospf network broadcast
ip ospf priority 0
no ip mroute-cache
standby 1 priority 101 preempt
standby 1 ip 172.16.34.1
standby 1 track Se0
bridge-group 1
!
ipx router nlsp
area-address 0 0
redistribute eigrp 100
!
router igrp 1
redistribute ospf 100 metric 10000 100 255 1 1500
passive-interface default
no passive-interface Ethernet0
no passive-interface Tunnel0
no passive-interface Tunnel1
network 172.16.0.0
If you need more script let me know....
Thanx Again
Nick Shah wrote: Are the physical interfaces (from which tunnel is sourced ) running NLSP as
well ?

rgds
Nick
----- Original Message -----
From: Chris Hugo
To: Chris Hugo ;
Sent: Sunday, October 13, 2002 12:34 PM
Subject: Re: NLSP/IPXWAN and IP---Big time issue for Pre-November folks

> Note.
> If I termite the tunnels on loopback everthing runs fine. The problem
occurs when I terminate the tunnels on the physical interface.
> chris hugo
> Chris Hugo wrote:Hi folks,
>
> I'm experimenting with tunnels that take care of the IGRP VLSM problem. I
am also running NLSP with IPXWAN UNNUMBERED over the same tunnel.
>
> All IP traffic was running fine until I decided to run NLSP with IPXWAN
UNNUMBERED over the same tunnel. My tunnel would stay up, IP traffic and
routing ran fine. Problem was NLSP never came up.
>
> So now I made a separate tunnel and NLSP runs fine and all ip traffic
stops from propogating though the GRE tunnel.
>
> *In all scenarios IP on the interface runs fine.
>
> Has anyone saw this?? And if not pleeeeeease lab up and see if you get
this too.
>
> thanks all,
>
> chris hugo
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos, & more
> faith.yahoo.com
>
>
> ---------------------------------
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos, & more
> faith.yahoo.com

---------------------------------
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos, & more
faith.yahoo.com

---------------------------------
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos, & more
faith.yahoo.com



This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:46 GMT-3