From: Blaine Williams (williams.blaine@gmail.com)
Date: Sat Jun 16 2007 - 17:02:22 ART
Mark,
Try creating two separate Virtual-Template interfaces with the same IP
address. I'm not sure if that is necessary, but that's how I've
always seen it done. The router may be getting confused because it
spawned both Virtual-Access interfaces from the same Virtual-Template.
Blaine Williams
On 6/16/07, markmckillop@hotmail.com <markmckillop@hotmail.com> wrote:
> I have come across this problem a few times now and can't explain how it happens and secondly how to cure it. I have a hub and spoke using PPPoFR, with a single virtual template on the hub (this spawns to virtual-access interfaces each with the same ip address) - Simple enough config..
>
> interface Serial0/0/0
> no ip address
> encapsulation frame-relay
> frame-relay interface-dlci 304 ppp Virtual-Template1
> frame-relay interface-dlci 305 ppp Virtual-Template1
>
> interface Virtual-Template1
> ip address 164.1.0.3 255.255.255.128
> ip ospf network point-to-multipoint
> no peer neighbor-route
>
> (This produces)
>
> interface Virtual-Access1
> ip address 164.1.0.3 255.255.255.128
> ip ospf network point-to-multipoint
> end
>
> interface Virtual-Access2
> ip address 164.1.0.3 255.255.255.128
> ip ospf network point-to-multipoint
> end
>
> However now what ive seen happen is that the router seems to get confused and mixes up which of the spokes the routes are learned from so I am effectively learning routes in Virtual-Access 1 that are being displayed in the routing table as through Virtual-Access 2.
>
> Im assuming the problem stems from these two entries in the routing table. I've also tried it with and without the peer neighbor route as I seen some examples online that used the 'no peer neighbor-route'.
>
> O 164.1.0.5/32 [110/1] via 164.1.0.5, 00:11:06, Virtual-Access2
> O 164.1.0.4/32 [110/1] via 164.1.0.4, 00:11:06, Virtual-Access2
>
> See routing table attached... -> This must be something common as I've come across it a couple of times, but never got around to fixing it yet :(.
>
> Any help greatly appreciated!!!!!!!!!
>
> Regards
> Mark McKillop
>
> Rack1R3#show ip route
> Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
> D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
> N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
> E1 - OSPF external type 1, E2 - OSPF external type 2
> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
> ia - IS-IS inter area, * - candidate default, U - per-user static route
> o - ODR, P - periodic downloaded static route
>
> Gateway of last resort is not set
>
> 164.1.0.0/16 is variably subnetted, 10 subnets, 3 masks
> O IA 164.1.47.0/24 [110/2] via 164.1.0.4, 00:11:06, Virtual-Access2
> O IA 164.1.55.0/24 [110/2] via 164.1.0.5, 00:11:06, Virtual-Access2
> O IA 164.1.5.0/24 [110/2] via 164.1.0.5, 00:11:06, Virtual-Access2
> O 164.1.0.5/32 [110/1] via 164.1.0.5, 00:11:06, Virtual-Access2
> O 164.1.0.4/32 [110/1] via 164.1.0.4, 00:11:06, Virtual-Access2
> O 164.1.7.0/24 [110/11113] via 164.1.0.4, 00:11:06, Virtual-Access2
> C 164.1.0.0/25 is directly connected, Virtual-Access1
> is directly connected, Virtual-Access2
> C 164.1.3.0/24 is directly connected, FastEthernet0/1
> C 164.1.13.0/24 is directly connected, Serial0/1/0
> C 164.1.23.0/24 is directly connected, Serial0/0/1.23
> 150.1.0.0/24 is subnetted, 4 subnets
> O 150.1.7.0 [110/11113] via 164.1.0.4, 00:11:08, Virtual-Access2
> O 150.1.5.0 [110/2] via 164.1.0.5, 00:11:08, Virtual-Access2 (SHOULD BE 1)
> O 150.1.4.0 [110/2] via 164.1.0.4, 00:11:08, Virtual-Access2 (CORRECT)
> C 150.1.3.0 is directly connected, Loopback0
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Jul 01 2007 - 17:24:49 ART