[c-nsp] cisco-nsp Digest, Vol 87, Issue 84
Gong Wei
gongwei.nus at gmail.com
Wed Feb 24 06:07:51 EST 2010
Password
On 2/24/10, cisco-nsp-request at puck.nether.net
<cisco-nsp-request at puck.nether.net> wrote:
> Send cisco-nsp mailing list submissions to
> cisco-nsp at puck.nether.net
>
> 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
> cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> cisco-nsp-owner at puck.nether.net
>
> 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 <gk at ax.tc>
> To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MPLS VPN with lot of PPP interfaces and central
> firewall (Half Duplex VRF / HDVRF)
> Message-ID: <4B8453AC.9090805 at ax.tc>
> 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 <lists at hojmark.org>
> To: Gert Doering <gert at greenie.muc.de>
> Cc: cisco-nsp at puck.nether.net, Jon Lewis <jlewis at lewis.org>
> Subject: Re: [c-nsp] what is it with 3550s?
> Message-ID: <pjp8o55oep0n5fgqh9h66n48pa3144ta9u at hojmark.net>
> 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 <lists at hojmark.org>
> To: "Meister, Daniel J." <dmeister at sisunet.org>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Getting serial number for 3640s
> Message-ID: <o3q8o5le8nc6ai7risqd8sqaqj4im4o0cp at hojmark.net>
> 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" <cayers at ena.com>
> To: "Bielawa, Daniel W. (NS)" <dwbielawa at liberty.edu>,
> <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Getting serial number for 3640s
> Message-ID: <A7B0A9F02975A74A845FE85D0B95B8FA0DD0B6E6 at misex01.ena.com>
> 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: dwbielawa at liberty.edu
>> 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 <jason at lixfeld.ca>
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ES20 throughput in the weeds?
> Message-ID: <FBC0341F-4B16-43D4-9C19-F5276F0A92AA at lixfeld.ca>
> 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 <gert at greenie.muc.de>
> To: Asbjorn Hojmark - Lists <lists at hojmark.org>
> Cc: Gert Doering <gert at greenie.muc.de>, Jon Lewis <jlewis at lewis.org>,
> cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] what is it with 3550s?
> Message-ID: <20100224072954.GE9556 at greenie.muc.de>
> 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
> gert at greenie.muc.de
> fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
> -------------- 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 <lists at hojmark.org>
> To: Gert Doering <gert at greenie.muc.de>
> Cc: Gert Doering <gert at greenie.muc.de>, Jon Lewis <jlewis at lewis.org>,
> cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] what is it with 3550s?
> Message-ID: <bgl9o5trstt6nnm5f78tu4d6mskg75k4r1 at hojmark.net>
> 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 <gert at greenie.muc.de>
> To: Anthony McGarry <anthony.mcgarry at plannet21.ie>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] BRAS Redundancy
> Message-ID: <20100224084210.GH9556 at greenie.muc.de>
> 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
> gert at greenie.muc.de
> fax: +49-89-35655025
> gert at net.informatik.tu-muenchen.de
> -------------- 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)" <oboehmer at cisco.com>
> To: "Gerald Krause" <gk at ax.tc>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MPLS VPN with lot of PPP interfaces and central
> firewall (Half Duplex VRF / HDVRF)
> Message-ID:
> <6E4D2678AC543844917CA081C9D6B33F0145A27E at XMB-AMS-103.cisco.com>
> 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
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> End of cisco-nsp Digest, Vol 87, Issue 84
> *****************************************
>
--
Sent from my mobile device
More information about the cisco-nsp
mailing list