[c-nsp] 7206VXR w/NSE-1 ADSL aggregation L2TP problems
Bryan King
bking at inline.com
Thu Mar 8 19:50:50 EST 2007
Thanks Rodney, I don't know why I did not try that sooner. Whether or
not it is a PXF bug, turning off PXF resolved the issue. I will try an
IOS upgrade and re-enable PXF during maintenance this weekend. Not much
point in having an NSE-1 if PXF is disabled.
TAC has had the case since yesterday without any resolution. Apparently
NSE-1s are no longer part of the available lab equipment.
b r y a n king | Network Engineer
InLine> Solutions Through Technology
600 Lakeshore Pkwy
Birmingham AL, 35209
205-278-8139 [p]
205-941-1934[f]
bking at inline.com
www.InLine.com
--------------------------------------------------------
From: Rodney Dunn [mailto:rodunn at cisco.com]
Sent: Thursday, March 08, 2007 4:12 PM
To: Bryan King
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 7206VXR w/NSE-1 ADSL aggregation L2TP problems
I didn't look too much at the detail because I'm not a BBAGG expert.
But I can tell you to start off disable PXF via 'no ip pxf' and
see if you see the same problem.
Because if it's a bug in PXF on that processor it will not be fixed
just like the 7401.
Rodney
On Thu, Mar 08, 2007 at 02:45:16PM -0600, Bryan King wrote:
> We are completing our transition from Bellsouth's PVC-Based ADSL
network
> to their "Broadband Gateway" (delivered over L2TP) network. Standard
> customers doing PPPoE and getting a public IP address (either
statically
> or via an IP Pool) are working just fine. However, our customers' that
> are assigned a VRF do not route within their assigned VRF. We are
using
> RADIUS and Cisco avpairs to assign VRF and IP unnumbered for the
> virtual-access interfaces. This is working just fine for the devices
> that are still connecting via a dedicated PVC whose PPPoE session is
> terminating on the 7206, but the devices that are terminating via the
> VPDN group and L2TP tunnel sessions are not. They connect, RADIUS
> assigns their VRF correctly and assigns "IP unnumbered Loopback 22"
just
> fine. I have a TAC case open with Cisco on it right now, but they have
> not been able to help yet. The users listed below as connected via
PPPoE
> are working in the VRF and have been for years now, the new
connections
> listed as PPPoVPDN cannot communicate to any other connected device
> within the VRF. They can ping the loopback interface and the VLAN
> interface on the 7206 which are in the VRF. Likewise, I can ping the
> PPPoVPDN connected DSL routers from the VRF locally on the 7206, but
not
> from any other connected devices.
>
> As usual certain items have been sanitized to protect the innocent
>
> 7206OXM-ADSL#sh ver
> Cisco IOS Software, 7200 Software (C7200-JK9S-M), Version 12.3(8)T,
> RELEASE SOFTWARE (fc2)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2004 by Cisco Systems, Inc.
> Compiled Thu 13-May-04 21:20 by eaarmas
>
> System image file is "disk0:c7200-jk9s-mz.123-8.T.bin"
>
> Cisco 7206VXR (NSE-1) processor (revision A) with 245760K/16384K bytes
> of memory.
> Processor board ID 26791472
> R7000 CPU at 262MHz, Implementation 39, Rev 2.1, 256KB L2 Cache
> 6 slot VXR midplane, Version 2.6
> ============================================================
> ip vrf CustomerA
> rd 100:1
> vpn id A1:A1
> route-target export 100:1
> route-target import 100:1
> !
> ip cef
> ip cef load-sharing algorithm original
> vpdn enable
> vpdn multihop
> vpdn session accounting network ACS-Radius
> vpdn ip udp ignore checksum
> !
> vpdn-group group01
> accept-dialin
> protocol any
> virtual-template 26
> terminate-from hostname someBellsouthLAC
> local name BBG-Gateway
> lcp renegotiation on-mismatch
> l2tp tunnel password blahblahblah
> l2tp tunnel receive-window 100
> l2tp tunnel retransmit timeout min 2
> ip mtu adjust
> !
> vpdn-group inline02
> accept-dialin
> protocol pppoe
> virtual-template 26
> ip mtu adjust
> !
> interface Loopback22
> ip vrf forwarding CustomerA
> ip address 10.254.254.254 255.255.255.255
> !
> interface FastEthernet2/0.309
> description CustomerA VRF vLAN 309
> encapsulation dot1Q 309
> ip vrf forwarding CustomerA
> ip address 10.254.254.241 255.255.255.248
> no cdp enable
> !
>
> interface Virtual-Template26
> description Bellsouth aggregation
> ip unnumbered Loopback102
> no peer default ip address
> ppp mtu adaptive
> ppp authentication chap pap ACS-Radius
> ppp authorization ACS-Radius
> ppp accounting ACS-Radius
> !
> ======================================================
>
> 7206OXM-ADSL#sh user | incl CustomerA
> Vi4.142 CustomerA1adsl at ispAb PPPoVPDN 00:00:01 10.1.0.1
> Vi5 CustomerA15adsl at ispA PPPoE 1d00h 10.15.0.1
> Vi7 CustomerA18adsl at ispA PPPoE 1d20h 10.18.0.1
> Vi8 CustomerA9adsl at ispAb PPPoE 01:06:46 10.9.0.1
> Vi9 CustomerA2adsl at ispAb PPPoE 1d00h 10.2.0.1
> Vi10 CustomerA55adsl at ispA PPPoE 21:20:32 10.55.0.1
> Vi11 CustomerA3adsl at ispAn PPPoE 1d00h 10.3.0.1
> Vi12 CustomerA5adsl at ispAn PPPoE 1d00h 10.5.0.1
> Vi13 CustomerA53adsl at ispA PPPoE 20:54:47 10.53.0.1
> Vi14 CustomerA56adsl at ispA PPPoE 00:40:54 10.56.0.1
> Vi15 CustomerA6adsl at ispAn PPPoE 1d00h 10.6.0.1
> Vi16 CustomerA7adsl at ispAn PPPoE 1d20h 10.7.0.1
> Vi17 CustomerA4adsl at ispAn PPPoE 22:37:02 10.4.0.1
> Vi18 CustomerA54adsl at ispA PPPoE 1d00h 10.54.0.1
> Vi19 CustomerA10adsl at ispA PPPoE 1d00h 10.10.0.1
> Vi20 CustomerA52adsl at ispA PPPoE 1d20h 10.52.0.1
> Vi21 CustomerAtest at ispAbb PPPoVPDN 00:51:18 10.200.0.1
>
>
> 7206OXM-ADSL#sh ip vrf detail CustomerA
> VRF CustomerA; default RD 100:1; default VPNID A1:A1
> Interfaces:
> Loopback22 FastEthernet2/0.309
Virtual-Template22
> Virtual-Access5 Virtual-Access7 Virtual-Access9
> Virtual-Access10 Virtual-Access12 Virtual-Access11
> Virtual-Access13 Virtual-Access14 Virtual-Access15
> Virtual-Access16 Virtual-Access18 Virtual-Access19
> Virtual-Access20 Virtual-Access17 Virtual-Access21
> Virtual-Access8
> Connected addresses are not in global routing table
> Export VPN route-target communities
> RT:100:1
> Import VPN route-target communities
> RT:100:1
> No import route-map
> No export route-map
> CSC is not configured.
>
> 7206OXM-ADSL#sh ip route vrf CustomerA
>
> Routing Table: CustomerA
> 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 10.254.254.243 to network 0.0.0.0
>
> 10.0.0.0/8 is variably subnetted, 33 subnets, 3 masks
> U 10.10.0.0/16 [1/0] via 10.10.0.1
> C 10.10.0.1/32 is directly connected, Virtual-Access19
> C 10.9.0.1/32 is directly connected, Virtual-Access8
> U 10.9.0.0/16 [1/0] via 10.9.0.1
> C 10.15.0.1/32 is directly connected, Virtual-Access5
> U 10.15.0.0/16 [1/0] via 10.15.0.1
> C 10.3.0.1/32 is directly connected, Virtual-Access11
> U 10.2.0.0/16 [1/0] via 10.2.0.1
> U 10.3.0.0/16 [1/0] via 10.3.0.1
> C 10.2.0.1/32 is directly connected, Virtual-Access9
> C 10.7.0.1/32 is directly connected, Virtual-Access16
> U 10.6.0.0/16 [1/0] via 10.6.0.1
> U 10.7.0.0/16 [1/0] via 10.7.0.1
> C 10.6.0.1/32 is directly connected, Virtual-Access15
> C 10.5.0.1/32 is directly connected, Virtual-Access12
> U 10.4.0.0/16 [1/0] via 10.4.0.1
> U 10.5.0.0/16 [1/0] via 10.5.0.1
> C 10.4.0.1/32 is directly connected, Virtual-Access17
> U 10.18.0.0/16 [1/0] via 10.18.0.1
> C 10.18.0.1/32 is directly connected, Virtual-Access7
> U 10.56.0.0/16 [1/0] via 10.56.0.1
> C 10.56.0.1/32 is directly connected, Virtual-Access14
> C 10.55.0.1/32 is directly connected, Virtual-Access10
> U 10.54.0.0/16 [1/0] via 10.54.0.1
> U 10.55.0.0/16 [1/0] via 10.55.0.1
> C 10.54.0.1/32 is directly connected, Virtual-Access18
> C 10.53.0.1/32 is directly connected, Virtual-Access13
> U 10.52.0.0/16 [1/0] via 10.52.0.1
> U 10.53.0.0/16 [1/0] via 10.53.0.1
> C 10.52.0.1/32 is directly connected, Virtual-Access20
> C 10.200.0.1/32 is directly connected, Virtual-Access21
> C 10.254.254.254/32 is directly connected, Loopback22
> C 10.254.254.240/29 is directly connected, FastEthernet2/0.309
> S* 0.0.0.0/0 [1/0] via 10.254.254.243
>
>
>
> b r y a n king | Network Engineer
> InLine> Solutions Through Technology
> 600 Lakeshore Pkwy
> Birmingham AL, 35209
> 205-278-8139 [p]
> 205-941-1934[f]
> bking at inline.com
> www.InLine.com
> --------------------------------------------------------
> --------------------------------------------------------
>
> All Quotes from InLine are only valid for 30 days. This message and
any attached files may contain confidential information and are intended
solely for cisco-nsp at puck.nether.net. If you are not
cisco-nsp at puck.nether.net you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
information is strictly prohibited. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender (bking at inline.com) therefore does not accept
liability for any errors or omissions in the contents of this message,
which arise as a result of e-mail transmission. If verification is
required please request a hard-copy version.
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list