Password On 2/24/10, [email protected] <[email protected]> wrote: > Send cisco-nsp mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://puck.nether.net/mailman/listinfo/cisco-nsp > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cisco-nsp digest..." > > > Today's Topics: > > 1. Re: MPLS VPN with lot of PPP interfaces and central firewall > (Half Duplex VRF / HDVRF) (Gerald Krause) > 2. Re: what is it with 3550s? (Asbjorn Hojmark - Lists) > 3. Re: Getting serial number for 3640s (Asbjorn Hojmark - Lists) > 4. Re: Getting serial number for 3640s (Cory Ayers) > 5. ES20 throughput in the weeds? (Jason Lixfeld) > 6. Re: what is it with 3550s? (Gert Doering) > 7. Re: what is it with 3550s? (Asbjorn Hojmark - Lists) > 8. Re: BRAS Redundancy (Gert Doering) > 9. Re: MPLS VPN with lot of PPP interfaces and central firewall > (Half Duplex VRF / HDVRF) (Oliver Boehmer (oboehmer)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Feb 2010 23:16:12 +0100 > From: Gerald Krause <[email protected]> > To: "Oliver Boehmer (oboehmer)" <[email protected]> > Cc: [email protected] > Subject: Re: [c-nsp] MPLS VPN with lot of PPP interfaces and central > firewall (Half Duplex VRF / HDVRF) > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Am 23.02.2010 16:47, Oliver Boehmer (oboehmer) schrieb: >> >>> Hello Oli, thx for your support again. I have configured the HUB/PE as >>> suggested: >>> [..] >>> I see that a traceroute from CPE1 to CPE2 now take the path over the >> HUB >>> and then back to the LNS as expected: >>> [...] >>> When I remove the def-route on the HUB, I'am still able to reach CPE2 >>> from CPE1 directly over the LNS: >>> >>> cpe1-vrftest#traceroute >>> Target IP address: 10.98.2.1 >>> Source address: 10.98.1.1 >>> Tracing the route to 10.98.2.1 >>> 1 10.99.17.254 68 msec 60 msec 64 msec (Loopback102 LNS) >>> 2 10.99.17.2 152 msec * 148 msec (CPE2) >>> >>> So I *can* re-direct the traffic from CPE to CPE through the HUB but >> in >>> the case the HUB fails, the CPEs are directly connected again through >>> the LNS/SPOKE PE. Is that the expected behaviour? Or is there still >> some >>> thing I'am missing (RPF is enabled on the Vi's)? >> >> That's strange.. Can you open a TAC case to get this looked at? > > Ok, I will do so if I can't get ahead soon. > >> I just >> tried this with "regular" serial interfaces, and I don't see the issue, >> i.e. without a default route, the CEs don't see each other. > > I assume even without any MP-BGP between the SPOKE and HUB PEs, it > should be possible to isolate two interfaces on the SPOKE/PE with the > Half Duplex VRF feature enabled. I'am right here? So how looks your > SPOKE/PE test setup regarding the VRF configuration (VRF definition, > interfaces and static routes for that VRF)? That would be interesting > for me. Maybe I can build a similar setup with some unused FastEth's in > my LNS/SPOKE/PE. > >> Can you remove urpf and try again? > > I've tried that, looks like uRPF has no influence. I get the same > resluts with and without. > > Thx a lot so far! > -- > Gerald > > > > ------------------------------ > > Message: 2 > Date: Wed, 24 Feb 2010 00:42:17 +0100 > From: Asbjorn Hojmark - Lists <[email protected]> > To: Gert Doering <[email protected]> > Cc: [email protected], Jon Lewis <[email protected]> > Subject: Re: [c-nsp] what is it with 3550s? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Tue, 23 Feb 2010 22:41:18 +0100, you wrote: > >> I have no idea how to get that point (BFD is good! make it happen! >> on SVI!) across to the relevant people... *sigh* > > The SP people do get it, and I'm sure it's now (again) roadmapped for > the 7600, where it's relevant. Whether it'll ever show up on a campus > switch (6500) may be another story. > > -A > > > ------------------------------ > > Message: 3 > Date: Wed, 24 Feb 2010 00:47:34 +0100 > From: Asbjorn Hojmark - Lists <[email protected]> > To: "Meister, Daniel J." <[email protected]> > Cc: [email protected] > Subject: Re: [c-nsp] Getting serial number for 3640s > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Tue, 23 Feb 2010 14:25:13 -0600, you wrote: > >> While not exactly the same, we've got a 3660 running old IOS that >> supports the command 'show c3600' which will display the chassis serial >> number. > > Something also worth trying is 'sh diag', which works on all the old > gear, and gives a chassis serial number for some of it. I don't know > if it works on a 3600, but it does work on the 3725 that I at home. > > -A > > > ------------------------------ > > Message: 4 > Date: Tue, 23 Feb 2010 17:55:36 -0600 > From: "Cory Ayers" <[email protected]> > To: "Bielawa, Daniel W. (NS)" <[email protected]>, > <[email protected]> > Subject: Re: [c-nsp] Getting serial number for 3640s > Message-ID: <[email protected]> > Content-Type: text/plain; charset="Windows-1252" > >> Hello, >> We had a similar problem with our 7200 series. According to TAC >> some Cisco products do not report the serial number. That was the case >> with us, and the only way to verify was to physically go to the box and >> check. Given the age of the 3600 series routers, I would guess the same >> limitation applies to your case. >> >> Thank You >> >> Daniel Bielawa >> Network Engineer >> Liberty University Network Services >> Email: [email protected] >> Phone: 434-592-7987 >> >> >> > I've going over a customer's inventory, and I'm having some trouble >> with >> > serial numbers. How do you get the serial number for a 3640 router? I >> > usually look for the processor board ID in 'sho ver', but that's not >> > matching what's listed in the inventory. > > I don't believe there is a way to pull chassis serial from the command line > on the older router models (2600, 3600, 7200). You can pull the mainboard > serial, but this does not match the sticker on the outside of the chassis. > > > ------------------------------ > > Message: 5 > Date: Tue, 23 Feb 2010 18:32:13 -0500 > From: Jason Lixfeld <[email protected]> > To: [email protected] > Subject: [c-nsp] ES20 throughput in the weeds? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > We've got an 7600-ES20-GE3CXL HW 1.2 FW 12.2(33r)SRB SW 12.2(33)SRC4 in a > 7609/Sup720 3BXL chassis. We ran some performance tests for a customer, and > we were quite appalled by the results. We're using Exfo test sets to run > RFC2544 patterns between two ports. > > We're using 7 frame sizes; 64, 128, 256, 512, 1024, 1280, 1518. > > When we look at the throughput results, we see this: > > Frame Size TX-to-RX - Layer 1-2-3 (Mbps) > 64 449.197861 > 128 538.181818 > 256 560.97561 > 512 974.358974 > 1024 956.043956 > 1280 1000 > 1518 994.825356 > > Now if we do that same test on another card, say a WS-X6724-SFP, we get very > different results: > > Frame Size TX-to-RX - Layer 1-2-3 (Mbps) > 64 1000 > 128 1000 > 256 1000 > 512 1000 > 1024 1000 > 1280 1000 > 1518 1000 > > I've tried the same test on a Juniper EX4200, and an ME3400E-12CS and all > the results are identical to the WS-X6724-SFP. The ES20 seems to be the > anomaly here. > > I know that processing smaller packets is generally much more taxing than > processing large packets, so I didn't really expect to see line rate on any > of the tests that were run, but considering the 6724 reported what seem to > be line rate results vs. the ES20, I can't help but to wonder whether I've > got a bad card or something. > > ------------------------------ > > Message: 6 > Date: Wed, 24 Feb 2010 08:29:54 +0100 > From: Gert Doering <[email protected]> > To: Asbjorn Hojmark - Lists <[email protected]> > Cc: Gert Doering <[email protected]>, Jon Lewis <[email protected]>, > [email protected] > Subject: Re: [c-nsp] what is it with 3550s? > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > On Wed, Feb 24, 2010 at 12:42:17AM +0100, Asbjorn Hojmark - Lists wrote: >> On Tue, 23 Feb 2010 22:41:18 +0100, you wrote: >> >> > I have no idea how to get that point (BFD is good! make it happen! >> > on SVI!) across to the relevant people... *sigh* >> >> The SP people do get it, and I'm sure it's now (again) roadmapped for >> the 7600, where it's relevant. Whether it'll ever show up on a campus >> switch (6500) may be another story. > > Now that you mention it. I did not rant over the BU split for at least > two months, did I? > > The decision for which (mid-to-high end platforms) a certain feature is > "relevant" is something I find highly interesting. As if enterprise > customers don't want high availability. > > gert > -- > USENET is *not* the non-clickable part of WWW! > > //www.muc.de/~gert/ > Gert Doering - Munich, Germany > [email protected] > fax: +49-89-35655025 > [email protected] > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 305 bytes > Desc: not available > URL: > <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100224/ba171b99/attachment-0001.bin> > > ------------------------------ > > Message: 7 > Date: Wed, 24 Feb 2010 08:43:54 +0100 > From: Asbjorn Hojmark - Lists <[email protected]> > To: Gert Doering <[email protected]> > Cc: Gert Doering <[email protected]>, Jon Lewis <[email protected]>, > [email protected] > Subject: Re: [c-nsp] what is it with 3550s? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > On Wed, 24 Feb 2010 08:29:54 +0100, you wrote: > >>> The SP people do get it, and I'm sure it's now (again) roadmapped for >>> the 7600, where it's relevant. Whether it'll ever show up on a campus >>> switch (6500) may be another story. > >> Now that you mention it. I did not rant over the BU split for at least >> two months, did I? > > No I don't think so, but the bait worked very well ;-) > > -A > > > ------------------------------ > > Message: 8 > Date: Wed, 24 Feb 2010 09:42:10 +0100 > From: Gert Doering <[email protected]> > To: Anthony McGarry <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [c-nsp] BRAS Redundancy > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > hi, > > On Tue, Feb 23, 2010 at 10:38:30AM +0000, Anthony McGarry wrote: >> What I really need to know is how to assign static IPs to clients if >> they log into either BRAS when both BRASs have a different network range >> on their loopbacks. > > Dynamic routing between the BRASs and their next-hop router. > > gert > -- > USENET is *not* the non-clickable part of WWW! > > //www.muc.de/~gert/ > Gert Doering - Munich, Germany > [email protected] > fax: +49-89-35655025 > [email protected] > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 305 bytes > Desc: not available > URL: > <https://puck.nether.net/pipermail/cisco-nsp/attachments/20100224/36b80681/attachment-0001.bin> > > ------------------------------ > > Message: 9 > Date: Wed, 24 Feb 2010 09:53:26 +0100 > From: "Oliver Boehmer (oboehmer)" <[email protected]> > To: "Gerald Krause" <[email protected]> > Cc: [email protected] > Subject: Re: [c-nsp] MPLS VPN with lot of PPP interfaces and central > firewall (Half Duplex VRF / HDVRF) > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="US-ASCII" > > > >> > I just >> > tried this with "regular" serial interfaces, and I don't see the > issue, >> > i.e. without a default route, the CEs don't see each other. >> >> I assume even without any MP-BGP between the SPOKE and HUB PEs, it >> should be possible to isolate two interfaces on the SPOKE/PE with the >> Half Duplex VRF feature enabled. I'am right here? So how looks your >> SPOKE/PE test setup regarding the VRF configuration (VRF definition, >> interfaces and static routes for that VRF)? That would be interesting >> for me. > > very simple: > > ip vrf down > rd 1:2 > ! > ip vrf up > rd 1:1 > ! > ip cef > ! > interface Loopback1 > ip vrf forwarding up > ip address 1.0.0.1 255.255.255.255 > ! > interface Serial2/0 > ip vrf forwarding up downstream down > ip unnumbered Loopback1 > ip verify unicast reverse-path > encapsulation ppp > peer default ip address pool default > serial restart-delay 0 > ! > interface Serial2/1 > ip vrf forwarding up downstream down > ip unnumbered Loopback1 > ip verify unicast reverse-path > encapsulation ppp > peer default ip address pool default > serial restart-delay 0 > ! > ip local pool default 2.0.0.1 2.0.0.10 > > Didn't try with static routes.. also don't have MPLS/BGP configured on > this "PE".. it's a standalone box.. > >> Maybe I can build a similar setup with some unused FastEth's in >> my LNS/SPOKE/PE. > > hmm, not sure if FastEth will work, HD-VRF is only supported on > unnumbered interfaces. > > oli > > > > ------------------------------ > > _______________________________________________ > cisco-nsp mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > > End of cisco-nsp Digest, Vol 87, Issue 84 > ***************************************** >
-- Sent from my mobile device _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
