From: Marko Milivojevic (markom@vodafone.is)
Date: Sat Jun 16 2007 - 11:33:35 ART
Try creating loopback interface with IP address 164.1.0.3/26 and using "ip
unnumbered loopbackX" in Virtual-Template.
Pay attention to OSPF router-id issues in this case!
> From: <markmckillop@hotmail.com>
> Reply-To: <markmckillop@hotmail.com>
> Date: Sat, 16 Jun 2007 05:06:17 -0400
> To: <ccielab@groupstudy.com>
> Subject: PPPoFR
>
> 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