[c-nsp] 7206VXR w/NSE-1 ADSL aggregation L2TP problems
Rodney Dunn
rodunn at cisco.com
Thu Mar 8 23:00:38 EST 2007
On Thu, Mar 08, 2007 at 06:50:50PM -0600, Bryan King wrote:
> 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.
True. You really should look at a G1 or G2 for the best results.
>
> TAC has had the case since yesterday without any resolution. Apparently
> NSE-1s are no longer part of the available lab equipment.
It doesn't matter if they did because if you are on the latest code
and it's not fixed DE will not fix it on that processor if it's a PXF
bug on that processor. They will tell you to turn it off.
Sorry to deliver the bad, but honest, news.
Rodney
>
>
>
> 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