Re: [c-nsp] suppress bgp updates?
Hiding internal routing turmoil, as you state it, works best when you are aggregating/summarizing -- which you are not doing here. Your RIB entry for 192.168.2.0 changes between static and OSPF routes. BGP sees this as a route change and does its job of notifying neighbors. This would work better if you advertised 192.168.0.0/22 from the "edge" router, assuming you own that block of addresses. Brad Hedlund -- Sent from my mobile phone (please excuse brevity, typos) On Nov 16, 2010, at 8:04 PM, "Mark Kent" wrote: > I thought I knew how to nail down BGP announcements so that an edge > router shows a uniform face to the rest of the world, but a recent > experience and experiment tells me I was wrong. > > Here is the experiment: > > [upstream] > | > | > [edge]<>[internal] > > "upstream" and "edge" are eBGP peers, "edge" and "internal" are ospf > neighbors. The idea here is that I manage "edge" and "internal" and > some ISP runs "upstream". > > The config on "edge" is: > > router bgp 65530 > no synchronization > network 192.0.2.0 > neighbor 192.168.0.1 remote-as 65531 > > ip route 192.0.2.0 255.255.255.0 Null0 240 permanent > > My belief was that the above static route would save me from > any internal routing snafu, so that AS65531 will continually > see that path. > > Router "upstream" has: > > router bgp 65531 > bgp dampening > neighbor 192.168.0.2 remote-as 65530 > > with "debug ip bgp updates" turned on, so I can see what is happening. > > The "internal" router redistributes static routes into ospf, > so I introduce changes by alternating between: > > internal(config)#ip route 192.0.2.0 255.255.255.0 10.10.10.10 > > and > > internal(config)#no ip route 192.0.2.0 255.255.255.0 10.10.10.10 > > Whenever I do this, I do see updates making it out to the upstream: > > BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, > metric 27, path 65530 > BGP(0): 192.168.0.2 rcvd 192.0.2.0/24 > BGP(0): Revise route installing 1 of 1 routes for 192.0.2.0/24 -> > 192.168.0.2(main) to main IP table > BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, > metric 0, path 65530 > BGP(0): 192.168.0.2 rcvd 192.0.2.0/24 > > "sh ip bgp dampening flap-statistics" indicates that these updates > count as flaps and eventually lead to dampening (should anyone still do > dampening). I recognize that the routes are not being withdrawn and > then re-injected, and I am happy for that. > > You can see from the above that the metric is changing, and I can fix > this with: > > route-map FOO permit 10 > set metric 0 > set origin igp > > and > > router bgp 65530 > neighbor 192.168.0.1 route-map FOO out > > Now updates are recognized as duplicates by the upstream: > > BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, > metric 0, path 65530 > BGP(0): 192.168.0.2 rcvd 192.0.2.0/24...duplicate ignored > BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, > metric 0, path 65530 > BGP(0): 192.168.0.2 rcvd 192.0.2.0/24...duplicate ignored > > and these do not count as flaps (at least on this exact cisco7201 > masquerading as "upstream"). > > But what I want is to completely hide all internal turmoil from the > outside world... as long as "edge" is up I want it to show 192.0.2/24 > in a constant fashion. I feel like this was possible in the mid-'90s. > Was I mistaken? > > Thanks, > -mark > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] suppress bgp updates?
I thought I knew how to nail down BGP announcements so that an edge router shows a uniform face to the rest of the world, but a recent experience and experiment tells me I was wrong. Here is the experiment: [upstream] | | [edge]<>[internal] "upstream" and "edge" are eBGP peers, "edge" and "internal" are ospf neighbors. The idea here is that I manage "edge" and "internal" and some ISP runs "upstream". The config on "edge" is: router bgp 65530 no synchronization network 192.0.2.0 neighbor 192.168.0.1 remote-as 65531 ip route 192.0.2.0 255.255.255.0 Null0 240 permanent My belief was that the above static route would save me from any internal routing snafu, so that AS65531 will continually see that path. Router "upstream" has: router bgp 65531 bgp dampening neighbor 192.168.0.2 remote-as 65530 with "debug ip bgp updates" turned on, so I can see what is happening. The "internal" router redistributes static routes into ospf, so I introduce changes by alternating between: internal(config)#ip route 192.0.2.0 255.255.255.0 10.10.10.10 and internal(config)#no ip route 192.0.2.0 255.255.255.0 10.10.10.10 Whenever I do this, I do see updates making it out to the upstream: BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, metric 27, path 65530 BGP(0): 192.168.0.2 rcvd 192.0.2.0/24 BGP(0): Revise route installing 1 of 1 routes for 192.0.2.0/24 -> 192.168.0.2(main) to main IP table BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, metric 0, path 65530 BGP(0): 192.168.0.2 rcvd 192.0.2.0/24 "sh ip bgp dampening flap-statistics" indicates that these updates count as flaps and eventually lead to dampening (should anyone still do dampening). I recognize that the routes are not being withdrawn and then re-injected, and I am happy for that. You can see from the above that the metric is changing, and I can fix this with: route-map FOO permit 10 set metric 0 set origin igp and router bgp 65530 neighbor 192.168.0.1 route-map FOO out Now updates are recognized as duplicates by the upstream: BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, metric 0, path 65530 BGP(0): 192.168.0.2 rcvd 192.0.2.0/24...duplicate ignored BGP(0): 192.168.0.2 rcvd UPDATE w/ attr: nexthop 192.168.0.2, origin i, metric 0, path 65530 BGP(0): 192.168.0.2 rcvd 192.0.2.0/24...duplicate ignored and these do not count as flaps (at least on this exact cisco7201 masquerading as "upstream"). But what I want is to completely hide all internal turmoil from the outside world... as long as "edge" is up I want it to show 192.0.2/24 in a constant fashion. I feel like this was possible in the mid-'90s. Was I mistaken? Thanks, -mark ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
On Tue, 2010-11-16 at 23:10 +0100, Asbjorn Hojmark - Lists wrote: > On Tue, 16 Nov 2010 21:21:21 +0100, you wrote: > > But I fail to see why they won't support their own > > transceivers. That's just plain stupid. > > Support takes testing > Testing takes time > Time costs money Yeah. Sometimes it's just hard to understand what extremely rigorous testing scheme means that 6500/SXI doesn't support SFPs but 7600/SRD does. If they tested new IOS releases that well we wouldn't have half the problems we all write about would we? ;-) Similar thing with CAB-SFP, being supported in all the different models of 3560/3560G but not the quite similar 3750 platform. (Quite similar in hardware and quite similar in software/features.) I'd prefer they put a sticker on the thing saying "use at your own risk" (i.e. "service unsupported-transceiver") instead of plainly disallowing it's use. > ... plus, given a finite amount of time, there'll always be > prioritization on what to do when. We may not always agree with the > priorities, but you shouldn't doubt that they're done. Of course. That just means that Cisco is bound to alienate some subset of their customers. And I can't imagine Cisco doesn't know that their competitors _really_ use this to their advantage. I'm not sure e.g. HP/H3C is better, but boy do they know what irritate Ciscos customers... > If one use something else than Cisco pluggables, one should at least > use products from someone who isn't afraid to put their own name on > and in the product. Completely agree, and these (EG Electronics) indeed do. And they seem proud about it. Mind you, we haven't really tested anything yet, just talked with them. -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Nexus BGP Default local-preference
I've been looking at the online doco's (including the wiki on IOS->Nexus config), I can't find where/if I can do default local preference within the BGP configuration. All the command references that I can find references using a set command within a route-map per neighbour, but I can't find a global setting (in a terribly nested BGP config mode). Is this command actually available ? I'm using 5.0(3). Regards, Matt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
On Tue, 16 Nov 2010 21:21:21 +0100, you wrote: > I have some (though not much) sympathy for Cisco's not wanting to > support 3rd party transceivers. Hey, they have to feed their kids and > all that. But I fail to see why they won't support their own > transceivers. That's just plain stupid. Support takes testing Testing takes time Time costs money ... plus, given a finite amount of time, there'll always be prioritization on what to do when. We may not always agree with the priorities, but you shouldn't doubt that they're done. > Oh well, we're in talks with a 3rd party provider that deliver optics > that work without "service unsupported-transceiver" at a much lower > price and 3 year warranty. The problem with using Cisco-coded transceivers is that it makes it much harder to figure out what's going on. (And yes, lots of those pluggables that appear to work, frequently fails. Been there, seen it many times on support cases). There are companies producing high-quality pluggables (and sell them at a much lower price than Cisco), but there are also lots of cases where you get what you pay for (not very much). If one use something else than Cisco pluggables, one should at least use products from someone who isn't afraid to put their own name on and in the product. -A ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] VSS and 3560, convergence measurement
When i was measuring VSS convergence, i actually noted that it is better to use LACP or Pagp control protocol in active mode instead of putting a portchannel in fixed status "on". My explanation for this was: when a portchannel uses LACP or Pagp active mode, it only starts forwarding from the moment BOTH sides have agreed on the portchannel settings. I have noticed that when both sides are ON, one side immediately starts sending packets from the moment the interface comes up. The other side might not yet be ready to forward packets, therefore it drops packets. This brought down packet drops from 1.5 seconds to 100 msec for me :-) regards, Geert 2010/11/15 Pavel Skovajsa > Hello Mkhail, > > Usually VSS convergence should be below 200ms, at least on paper I > would try to turn off various "automatic features", starting with > trunk negotiation (DTP) on one end of spectrum and undesirable > portchannel on the other to find the culprit. > > -pavel > > On Sun, Nov 14, 2010 at 8:25 PM, Mikhail wrote: > > Hello, list. > > > > We have VSS 1440 and we try to measure convergence time when we pull one > of > > the copper links from 3560 (Etherchannel, PAgP, desirable-desirable, we > also > > tried on-on). > > > > We do it by sending "ping -f -i 0.1 -W 0.1 " from the Linux station: > > > > Linux -- [3560] === [VSS] === [4948] --- > > > > This command prints us about 12-18 dots which is 1200-1800ms (btw, when > we > > pull one of the 10Gb links from 4948 it prints usually 1-2 dots, > sometimes 3 > > dots). > > > > VSS design guide states that for 3xxx series port failure convergence > time > > should be about 200ms. > > > > 1. Does "ping" measurement actually give us convergence time? Is there > any > > "official" method for such type of measurement? > > > > 2. I suspect that 3560 is the root of the issue. Is it normal for that > > switch to converge for 1,5 second after losing one of the Etherchannel > > links? > > > > Thank you in any advance! > > > > ___ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS FRR with auto-bw
> can you clarify what you mean by "provide backup" for path AC via ABC? > > Looking at the picture alone I'm guessing: are you asking to only use > the path ABC for the tunnel AC if the other tunnels crossing AB leave > enough bandwidth for the AC tunnel? If tunnel AC bw requirements can't > be met on link AB, then you want it to use the AC link? > > If that's the case, you are asking for a) two path options on tunnel AC > (the primary being the ABC path, the secondary the AC direct link, or > dynamic if this is also the shortest path), and b) for different tunnel > priorities so an increase in bandwidth of the "AB"-Tunnels could > actually lead to tunnel AC using the ABC path being preempted. > > So if you configure the "couple of MPLS TE tunnels" crossing the link AB > with "tunnel mpls traffic-eng priority 4 4" (or another number lower > than the default of 7), they will preempt the AC tunnel if it is > configured with the default 7 (lower number is higher priority). > > If you mean some form of FRR, please clarify the exact requirements.. Oliver, Thanks for the answer. I'll try to elaborate it a bit. You are right, the very good option to solve it in the mentioned scenario is to use two (or more) different path options in the tunnel AC itself. I got it out of my head composing previous e-mail. But if we would come back to FRR, the question still remains open. Lets say link AC has configured backup-path (mpls traffic-eng backup-path Tunnel3010). Tunnel3010 has explicit path-option via ABC (next-hop B, next-hop C). Without bandwidth requirements everything works very well - link AC fails, tunnel(s) crossed AC link is(are) rerouted via ABC. But the point is to keep backup tunnel (Tunnel3010, ABC) up and signalled only if the enough bandwidth available along the path ABC to provide backup facility to tunnel(s) crossed AC. In other words, if AC (bw of crossed tunnels) + AB (bw of crossed tunnels) <= maximum throughput AB, tunnel3010 is up. One option I see is to use lower priority (as you mentioned) and auto-bw in the backup tunnel (tunnel mpls traffic-eng auto-bw frequency 300). But the disadvantage is (in case of lack of capacity on the path ABC) the service degradation at least 300 sec (minimum value I can set) while backup tunnel recalculates and re-requests the bandwidth. But I guess it is a very wrong way and no one would follow it. So, the question itself is how to provide bandwidth protection for tunnel(s) crossed path AC via ABC. Hope it is a bit clear now. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
In case there's no ip routing enabled and no ip default-gateway configured either, the switch will try ARPing the destination IP as it was directly connected. As highlighted by others, neighboring devices will reply if proxy-arp is enabled and if they have a valid route towards that destination. Andras On Tue, Nov 16, 2010 at 9:56 PM, Sharlon R. Carty wrote: > Was an incomplete config. Intention was to add ip routing, gateway, all that > good stuff later on. > was surprised that it was actually accessible remotely. > > On Tue, Nov 16, 2010 at 3:23 PM, Peter Rathlev wrote: > >> On Tue, 2010-11-16 at 14:59 -0400, Sharlon R. Carty wrote: >> > Looks like it's that. did a show arp and saw the arp entries. >> > So best practice is to disable proxy-arp on the interfaces? >> >> Yes, on all neighboring devices. The switch itself isn't a problem, only >> devices that route. >> >> Any special reason not to have a default gateway though? >> >> -- >> Peter >> >> >> > > > -- > --sharlon > ___ > cisco-nsp mailing list cisco-...@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
Was an incomplete config. Intention was to add ip routing, gateway, all that good stuff later on. was surprised that it was actually accessible remotely. On Tue, Nov 16, 2010 at 3:23 PM, Peter Rathlev wrote: > On Tue, 2010-11-16 at 14:59 -0400, Sharlon R. Carty wrote: > > Looks like it's that. did a show arp and saw the arp entries. > > So best practice is to disable proxy-arp on the interfaces? > > Yes, on all neighboring devices. The switch itself isn't a problem, only > devices that route. > > Any special reason not to have a default gateway though? > > -- > Peter > > > -- --sharlon ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
On Tue, 2010-11-16 at 20:04 +0100, Marian Ďurkovič wrote: > On Tue, 16 Nov 2010 10:36:06 -0800, Ian Cox wrote > > It a little more complicated on the GLC vs SFP parts. The SFP parts are > > spec'd to support a higher case temperature then the GLCs. Some > > platforms airflow at worst case temperature can not sufficiently cool > > GLC, were as SFP parts are spec'd to work at the higher temperatures. > > > > Ian > > Yep, that's yet another reason to finally discontinue GLC parts - which also > lack DOM support. Especially when the manufacturing costs difference between > SFP > and GLC parts is something like 1 USD... But... why oh why aren't SFP optics supported in the 6500[0]? If they're just supposed to be more durable I can't see the problem. And why can't I use a CAB-SFP in a 3750, even though it's completely genuine Cisco? I have some (though not much) sympathy for Cisco's not wanting to support 3rd party transceivers. Hey, they have to feed their kids and all that. But I fail to see why they won't support their own transceivers. That's just plain stupid. Oh well, we're in talks with a 3rd party provider that deliver optics that work without "service unsupported-transceiver" at a much lower price and 3 year warranty. -- Peter [0]: http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.html#wp139518 Also confirmed by an SE, telling us to buy GLCs instead. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
On Tue, 16 Nov 2010 10:36:06 -0800, Ian Cox wrote > It a little more complicated on the GLC vs SFP parts. The SFP parts are > spec'd to support a higher case temperature then the GLCs. Some > platforms airflow at worst case temperature can not sufficiently cool > GLC, were as SFP parts are spec'd to work at the higher temperatures. > > Ian Yep, that's yet another reason to finally discontinue GLC parts - which also lack DOM support. Especially when the manufacturing costs difference between SFP and GLC parts is something like 1 USD... M. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
On Tue, 2010-11-16 at 14:59 -0400, Sharlon R. Carty wrote: > Looks like it's that. did a show arp and saw the arp entries. > So best practice is to disable proxy-arp on the interfaces? Yes, on all neighboring devices. The switch itself isn't a problem, only devices that route. Any special reason not to have a default gateway though? -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
Looks like it's that. did a show arp and saw the arp entries. So best practice is to disable proxy-arp on the interfaces? thanks for the responses. On Tue, Nov 16, 2010 at 2:14 PM, wrote: > > I have a odd situation. I created a SVI on a 3560 switch, assigned an > IP > > address(public) without enabling ip routing and I was able to remotely > > access the switch. > > No default route added or anything like that. So how is it that I am able > to > > access the switch? > > switch is connected to another switch which has a trunk connection to a > > cisco 7206. > > I believe proxy ARP is still turned on by default on Cisco IP router > interfaces. > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > -- --sharlon ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
It a little more complicated on the GLC vs SFP parts. The SFP parts are spec'd to support a higher case temperature then the GLCs. Some platforms airflow at worst case temperature can not sufficiently cool GLC, were as SFP parts are spec'd to work at the higher temperatures. Ian On 11/16/10 1:57 AM, Jared Mauch wrote: > Yes. > > Cisco doesn't even support their own optics depending on the device. > > Make sure the device you are using supports the GLC vs SFP. > > Basically: If you didn't buy the optics with the device, it may not work even > with service unsupported-transciever, even if the optics are cisco purchased. > I've asked various BUs to support other cisco sold optics and been told > basically: "We don't care about you, go pound dirt." > > - Jared > > > On Nov 16, 2010, at 4:29 AM, jack daniels wrote: > >> Dear All, >> >> Are there any potential Technical issues with ignoring Cisco and >> using GLC-LH-SM >> rather than SFP-GE-L. What I can figure out is - >> with GLC-LH-SM - no monitoring (no DOM) >> SFP-GE-L higher cost. >> >> >> Regards >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] mpls on RR ?
On Tuesday, November 16, 2010 10:07:12 pm Oliver Boehmer (oboehmer) wrote: > no, not really. > I've seen one SP doing it so they can run the "same" > config/features on RRs compared to PEs and save on > testing, and there is one tiny benefit: If you run the > same MTU on all core links (including the RR links), > PMTUD on the RR will figure out the "right" MSS without > relying on frag-needed from the upstream MPLS node as > the RR already pushes a label, instead of the upstream P > node. But that's not a big argument, IMHO. I would not > enable LDP/MPLS on the RR - KISS.. If you're a multi-vendor house and use Juniper's, things can get interesting. JUNOS, by default, resolves BGP next-hops for VPNv4/v6 routes in the 'inet.3' routing table. The 'inet.3' routing table in JUNOS contains routes that are learned over MPLS LSP's created by LDP or RSVP. If you have a Juniper router running as a route reflector, in order to reflect VPNv4/v6 routes to clients, the route reflector would have to run MPLS, as only MPLS protocols can add routes to the 'inet.3' routing table. I know what you're thinking, but there are workarounds that can allow you to reflect VPNv4/v6 routes to clients without having to run MPLS on the route reflectors. They may not necessarily be obvious, but are well-documented. Just for those who plan to run multiple vendors in their network. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
We *have* it working on a 7201 running SRE2. Yep, sounds right. They've been supported since SRC2. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
> I have a odd situation. I created a SVI on a 3560 switch, assigned an IP > address(public) without enabling ip routing and I was able to remotely > access the switch. > No default route added or anything like that. So how is it that I am able to > access the switch? > switch is connected to another switch which has a trunk connection to a > cisco 7206. I believe proxy ARP is still turned on by default on Cisco IP router interfaces. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
On Tue, 2010-11-16 at 13:06 -0400, Sharlon R. Carty wrote: > I have a odd situation. I created a SVI on a 3560 switch, assigned an IP > address(public) without enabling ip routing and I was able to remotely > access the switch. > No default route added or anything like that. So how is it that I am able to > access the switch? > switch is connected to another switch which has a trunk connection to a > cisco 7206. With "no ip routing" you'd normally have "ip default-gateway" in the configuration, but I assume that's not the case here. Even with a correct netmask I've seen examples of a switch learning ARP entries for "foreign" hosts. Try "show ip arp" on the device. You should be able to configure all routers on the subnet with "no ip proxy-arp", a best practice IMO. -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS FRR with auto-bw
> > Lets say we have a MPLS-enabled triangle: > > http://i54.tinypic.com/k2lcw2.jpg > > Path AB is being crossed by a couple of MPLS TE Tunnels within automatic > bandwidth adjustment (tunnel mpls traffic-eng auto-bw). At the any given > point of time summary bandwidth of these tunnels is never exceeded the > capacity of the part AB. So bandwidth requests by these tunnels are always > satisfied. > > Also, assume that there is a tunnel AC with explicit path option. The total > bandwidth for this tunnel is unknown and is requested by automatic bandwidth > adjustment every 5 min as well. > > The question is, is there any way to provide backup facility for path AC via > path ABC only if enough bandwidth available at the path AB. For simplicity > assume that at the path BC bandwidth is always available. can you clarify what you mean by "provide backup" for path AC via ABC? Looking at the picture alone I'm guessing: are you asking to only use the path ABC for the tunnel AC if the other tunnels crossing AB leave enough bandwidth for the AC tunnel? If tunnel AC bw requirements can't be met on link AB, then you want it to use the AC link? If that's the case, you are asking for a) two path options on tunnel AC (the primary being the ABC path, the secondary the AC direct link, or dynamic if this is also the shortest path), and b) for different tunnel priorities so an increase in bandwidth of the "AB"-Tunnels could actually lead to tunnel AC using the ABC path being preempted. So if you configure the "couple of MPLS TE tunnels" crossing the link AB with "tunnel mpls traffic-eng priority 4 4" (or another number lower than the default of 7), they will preempt the AC tunnel if it is configured with the default 7 (lower number is higher priority). If you mean some form of FRR, please clarify the exact requirements.. oli ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Jumbo frames on certain VLANs with UCS fabric?
Perfect, thanks Manu. I switched them all to 9000 but I would have never found the CoS setting. I don't have CoS defined so I read that in that case it defaults to best effort in the UCS manager so I hand typed 9000 into the drop down and it took it and now I've got jumbo frame storage traffic to the EMC from vmware at ten gig. David > -Original Message- > From: Manu Chao [mailto:linux.ya...@gmail.com] > Sent: Tuesday, November 16, 2010 12:53 PM > To: David Hubbard > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] Jumbo frames on certain VLANs with UCS fabric? > > Hi David, > > (L2) MTU is not per VLAN but per physical interface. > > Make sure all interfaces in a VLAN are configured for jumbo > frames before configuring jumbo frame support on an SVI. > > You have to enable jumbo on ALL your 4900 switches interfaces. > > You have to enable jumbo on your UCS (The MTU is set on a per > CoS basis in UCS). > > R/ > Manu > > > On Tue, Nov 16, 2010 at 5:19 PM, David Hubbard > wrote: > > > Hi all, I'm working on deploying a UCS system using > iscsi to an EMC with only a pair of 4900M's in > between. I'm having a bit of trouble wrapping my > head around what I need to do to enable jumbo frames > to make it from end to end on the storage vlan. > > What I've got so far: > > 1) Two redundant UCS fabric interconnects are each > in end host mode and each dual-home to the two 4900M's > at ten gig. > > 2) Within the UCS configuration, there is a virtual > nic defined as mtu 9000, the rest of the virtual nics > are defined as mtu 1500. > > 3) The 4900M's have a storage vlan configured with an > mtu of 9000. All other vlan's are default 1500. > > 4) The ten gig interfaces to the UCS are set as mode > trunk but not mtu 9000 (I think this is an issue?). > > 5) The ten gig interfaces to the EMC's two service > processors on each 4900M are configured as > 'switchport access vlan...' and 'mtu 9000'. > > 6) The two 4900M's have a trunk between them carrying > all vlan's. (This may be an issue too?) > > > show int on the interfaces to the UCS fabrics and the > switch to switch trunk are both showing mtu 1500. Do > I need to set all of those interfaces to 9000? I tried > that, but did not test the EMC connectivity in between > because I noticed as soon as I set that I got a bunch > of MTU_Mismatch showing in "show vlan mtu" and I was > worried I was about to create a big problem. Or, is > it ok to have the mismatch there because any device > talking on the 1500 byte vlans would not generate a > larger packet anyway but devices on the 9000 byte vlan > are free to talk jumbo and the interfaces will transport > it because it's mtu 9000 all the way through, including > the switch to switch trunk? > > Thanks, > > David > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
On Tuesday, November 16, 2010 06:47:15 pm Nick Hilliard wrote: > Last time i tried, an NPE-G2 refused to accept a > GLC-SX-MM. You can imagine that this was surprising, to > say the least. I will not repeat the sentiments or > language that were expressed by the individuals involved > at the time, but let's just say that it was considered > Deeply Unhelpful that Cisco commodity hardware was not > compatible with, uh, other cisco commodity hardware. > > This is a software version dependent, and that GLC-SX-MM > transceivers will work on an NPE-G2, if you have the > right software. We *have* it working on a 7201 running SRE2. Admittedly, this is the first time we've tried it. We have a number of NPE-G2's that are using proper SFP-GE-* modules. I'd imagine, though, that for all intents and purposes, the 7201 and NPE-G2 are not terribly different. Or are they? Next time I'm in the office where we have these nodes, I'll certainly see about giving them a try. Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS FRR with auto-bw
I have never tried to solve this exact issue but you could try using the priority values to prevent the backup tunnel from preempting others on that path. I am not sure if these values are honored during FRR but you could give it a shot. -Ben On Nov 16, 2010, at 11:00 AM, Vitaliy Karlov wrote: Hello, Lets say we have a MPLS-enabled triangle: http://i54.tinypic.com/k2lcw2.jpg Path AB is being crossed by a couple of MPLS TE Tunnels within automatic bandwidth adjustment (tunnel mpls traffic-eng auto-bw). At the any given point of time summary bandwidth of these tunnels is never exceeded the capacity of the part AB. So bandwidth requests by these tunnels are always satisfied. Also, assume that there is a tunnel AC with explicit path option. The total bandwidth for this tunnel is unknown and is requested by automatic bandwidth adjustment every 5 min as well. The question is, is there any way to provide backup facility for path AC via path ABC only if enough bandwidth available at the path AB. For simplicity assume that at the path BC bandwidth is always available. In case the hardware makes sense, it is 6500 with SXH. Thanks. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Jumbo frames on certain VLANs with UCS fabric?
Hi David, (L2) MTU is not per VLAN but per physical interface. Make sure all interfaces in a VLAN are configured for jumbo frames before configuring jumbo frame support on an SVI. You have to enable jumbo on ALL your 4900 switches interfaces. You have to enable jumbo on your UCS (The MTU is set on a per CoS basis in UCS). R/ Manu On Tue, Nov 16, 2010 at 5:19 PM, David Hubbard < dhubb...@dino.hostasaurus.com> wrote: > Hi all, I'm working on deploying a UCS system using > iscsi to an EMC with only a pair of 4900M's in > between. I'm having a bit of trouble wrapping my > head around what I need to do to enable jumbo frames > to make it from end to end on the storage vlan. > > What I've got so far: > > 1) Two redundant UCS fabric interconnects are each > in end host mode and each dual-home to the two 4900M's > at ten gig. > > 2) Within the UCS configuration, there is a virtual > nic defined as mtu 9000, the rest of the virtual nics > are defined as mtu 1500. > > 3) The 4900M's have a storage vlan configured with an > mtu of 9000. All other vlan's are default 1500. > > 4) The ten gig interfaces to the UCS are set as mode > trunk but not mtu 9000 (I think this is an issue?). > > 5) The ten gig interfaces to the EMC's two service > processors on each 4900M are configured as > 'switchport access vlan...' and 'mtu 9000'. > > 6) The two 4900M's have a trunk between them carrying > all vlan's. (This may be an issue too?) > > > show int on the interfaces to the UCS fabrics and the > switch to switch trunk are both showing mtu 1500. Do > I need to set all of those interfaces to 9000? I tried > that, but did not test the EMC connectivity in between > because I noticed as soon as I set that I got a bunch > of MTU_Mismatch showing in "show vlan mtu" and I was > worried I was about to create a big problem. Or, is > it ok to have the mismatch there because any device > talking on the 1500 byte vlans would not generate a > larger packet anyway but devices on the 9000 byte vlan > are free to talk jumbo and the interfaces will transport > it because it's mtu 9000 all the way through, including > the switch to switch trunk? > > Thanks, > > David > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
Was the IP configured manually or received via dhcp? DHCP learned default route could be injected if the latter. I believe we can still have a default route, without unicast routing enabled. I thought we defined unicast routing to be between L3 interfaces on the device, but for management purposes could still have a route defined. Sorry ... been a while since I worked on a non-L3 switch, but figured I would take a stab. Rob On 11/16/2010 12:17 PM, Brandon Ewing wrote: On Tue, Nov 16, 2010 at 01:06:43PM -0400, Sharlon R. Carty wrote: Hello, I have a odd situation. I created a SVI on a 3560 switch, assigned an IP address(public) without enabling ip routing and I was able to remotely access the switch. No default route added or anything like that. So how is it that I am able to access the switch? switch is connected to another switch which has a trunk connection to a cisco 7206. If the source IP that you are connecting from is in the same subnet as the SVI you created, a return route exists via connected interface, and no default route is needed. Another case would be an incorrect netmask, with proxy-arp enabled on another ip-routing device in the broadcast network. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 SVI
On Tue, Nov 16, 2010 at 01:06:43PM -0400, Sharlon R. Carty wrote: > Hello, > > I have a odd situation. I created a SVI on a 3560 switch, assigned an IP > address(public) without enabling ip routing and I was able to remotely > access the switch. > No default route added or anything like that. So how is it that I am able to > access the switch? > switch is connected to another switch which has a trunk connection to a > cisco 7206. If the source IP that you are connecting from is in the same subnet as the SVI you created, a return route exists via connected interface, and no default route is needed. Another case would be an incorrect netmask, with proxy-arp enabled on another ip-routing device in the broadcast network. -- Brandon Ewing(nicot...@warningg.com) pgp47B1M3uzWB.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] John Rutkin has left BNP Paribas
Not a day too soon :) Stephen Stack Systems Administrator - Network CITCO -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger Sent: 16 November 2010 16:34 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] John Rutkin has left BNP Paribas On Tue, Nov 16, 2010 at 9:05 AM, wrote: > > I will be out of the office starting 12/11/2010 and will not return until > 11/09/3000. > > Hello, im sorry I wont be able to get back to you as I have left! Easily the best out of office reply I've seen in a while. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Disclaimer link. To see it, click the link below, or copy and paste it into your browser's address line. http://www.citco.com/emaildisclaimer.htm ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ACE File System
Hello group, I'm curious about the ACE file system and I found this on the Cisco Live presentation BRKAPP-3003: "Load debug plug-in to access ACE file system" Is this plug-in available somewhere ? What's the procedure in order to load it ? I see there's one "load" command available: loadLoad plug-in image I always found the ACE file system really obscure but it seems there's a tool to help us. Thanks. Regards, Antonio Soares, CCIE #18473 (R&S/SP) amsoa...@netcabo.pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 3560 SVI
Hello, I have a odd situation. I created a SVI on a 3560 switch, assigned an IP address(public) without enabling ip routing and I was able to remotely access the switch. No default route added or anything like that. So how is it that I am able to access the switch? switch is connected to another switch which has a trunk connection to a cisco 7206. -- --sharlon ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] John Rutkin has left BNP Paribas
On Tue, Nov 16, 2010 at 9:05 AM, wrote: > > I will be out of the office starting 12/11/2010 and will not return until > 11/09/3000. > > Hello, im sorry I wont be able to get back to you as I have left! Easily the best out of office reply I've seen in a while. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Jumbo frames on certain VLANs with UCS fabric?
Hi all, I'm working on deploying a UCS system using iscsi to an EMC with only a pair of 4900M's in between. I'm having a bit of trouble wrapping my head around what I need to do to enable jumbo frames to make it from end to end on the storage vlan. What I've got so far: 1) Two redundant UCS fabric interconnects are each in end host mode and each dual-home to the two 4900M's at ten gig. 2) Within the UCS configuration, there is a virtual nic defined as mtu 9000, the rest of the virtual nics are defined as mtu 1500. 3) The 4900M's have a storage vlan configured with an mtu of 9000. All other vlan's are default 1500. 4) The ten gig interfaces to the UCS are set as mode trunk but not mtu 9000 (I think this is an issue?). 5) The ten gig interfaces to the EMC's two service processors on each 4900M are configured as 'switchport access vlan...' and 'mtu 9000'. 6) The two 4900M's have a trunk between them carrying all vlan's. (This may be an issue too?) show int on the interfaces to the UCS fabrics and the switch to switch trunk are both showing mtu 1500. Do I need to set all of those interfaces to 9000? I tried that, but did not test the EMC connectivity in between because I noticed as soon as I set that I got a bunch of MTU_Mismatch showing in "show vlan mtu" and I was worried I was about to create a big problem. Or, is it ok to have the mismatch there because any device talking on the 1500 byte vlans would not generate a larger packet anyway but devices on the 9000 byte vlan are free to talk jumbo and the interfaces will transport it because it's mtu 9000 all the way through, including the switch to switch trunk? Thanks, David ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] John Rutkin has left BNP Paribas
I will be out of the office starting 12/11/2010 and will not return until 11/09/3000. Hello, im sorry I wont be able to get back to you as I have left! If you are external to BNPP please direct your queries to UK Networks uk@bnpparibas.com or contact them on 0207 595 4948 Internal users please call 4948 or 711 4948 if outside the uk. This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Do not print this message unless it is necessary, consider the environment. - Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. N'imprimez ce message que si necessaire, pensez a l'environnement. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] MPLS FRR with auto-bw
Hello, Lets say we have a MPLS-enabled triangle: http://i54.tinypic.com/k2lcw2.jpg Path AB is being crossed by a couple of MPLS TE Tunnels within automatic bandwidth adjustment (tunnel mpls traffic-eng auto-bw). At the any given point of time summary bandwidth of these tunnels is never exceeded the capacity of the part AB. So bandwidth requests by these tunnels are always satisfied. Also, assume that there is a tunnel AC with explicit path option. The total bandwidth for this tunnel is unknown and is requested by automatic bandwidth adjustment every 5 min as well. The question is, is there any way to provide backup facility for path AC via path ABC only if enough bandwidth available at the path AB. For simplicity assume that at the path BC bandwidth is always available. In case the hardware makes sense, it is 6500 with SXH. Thanks. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 9k and 100GE
Hello! Yes, You should upgrade [both] RSP to receive linerate bandwidth on 2x100G line cards. On Tue, Nov 16, 2010 at 12:47:45PM +0100, tim wrote: > Hi list, > > Short question about the ASR 9006/9010: > > Do I need to replace the switch fabric (or something else - like with > the GSR/12000 series when upgrading to 12400/12800) when 100GE is > available? Or do I just buy a new 100GE Linecard and put it into the > chassis? > > (We "found" some money in the budget for this year and are thinking of > buying some ASR 9k with 10GE Linecards and replacing (one-by-one) some > Cisco 12410. Later these ASR 9k should carry 100GE links. So if I need > to make bigger upgrades to the ASR 9k to make them 100GE capable, it is > probably not profitable.) > > Thanks, > -tim > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Dmitry Kiselev ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] mpls on RR ?
> Let me rephrase my question> > if RR not in forwarding path, is there a reason for MPLS on RR no, not really. I've seen one SP doing it so they can run the "same" config/features on RRs compared to PEs and save on testing, and there is one tiny benefit: If you run the same MTU on all core links (including the RR links), PMTUD on the RR will figure out the "right" MSS without relying on frag-needed from the upstream MPLS node as the RR already pushes a label, instead of the upstream P node. But that's not a big argument, IMHO. I would not enable LDP/MPLS on the RR - KISS.. Just make extra-sure that RRs will never be in the forwarding path, ISIS OL-bit or max-metric should be enabled.. oli ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] mpls on RR ?
Let me rephrase my question> if RR not in forwarding path, is there a reason for MPLS on RR 2010/11/16 Stephen.Chen > yes，core routers always act RR， when no additional investment for network > construction > > > > Stephen.Chen > > 2010/11/16 selamat pagi > > Now, I came across some examples with mpls enabled on RR and want to verify >> if there are >> reasons for enabling MPLS in network offering Internet-accees and L3VPNs >> > > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] mpls on RR ?
yes，core routers always act RR， when no additional investment for network construction Stephen.Chen 2010/11/16 selamat pagi > Now, I came across some examples with mpls enabled on RR and want to verify > if there are > reasons for enabling MPLS in network offering Internet-accees and L3VPNs > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] 6500 Priority Queuing (DSCP & EXP no COS based)
I would to translate following 7200 QoS template configuration to Catalyst 6500: class-map match-any PQ match dscp ef match mpls experimental topmost 5 policy-map QOS-PE-OUT class PQ priority percent 33 class class-default Does the priority command supported on 6500 or do we have to care about additionnal qos interface command like priority-queue cos-map (i don t see dscp or exp equivalent)? Thanks in advance ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] mpls on RR ?
> I believed that mpls is not needed on ipv4 RR and vpnv4 RR. > (as RR should not be in the forwarding path) > > Now, I came across some examples with mpls enabled on RR and want to verify > if there are > reasons for enabling MPLS in network offering Internet-accees and L3VPNs ? There may be reasons to have the RR in the forwarding path, especially for ipv4. Less so for vpnv4. So "RR should not be in the forwarding path" is not universally applicable. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] mpls on RR ?
I believed that mpls is not needed on ipv4 RR and vpnv4 RR. (as RR should not be in the forwarding path) Now, I came across some examples with mpls enabled on RR and want to verify if there are reasons for enabling MPLS in network offering Internet-accees and L3VPNs ? cheers, keti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ASR 9k and 100GE
Hi list, Short question about the ASR 9006/9010: Do I need to replace the switch fabric (or something else - like with the GSR/12000 series when upgrading to 12400/12800) when 100GE is available? Or do I just buy a new 100GE Linecard and put it into the chassis? (We "found" some money in the budget for this year and are thinking of buying some ASR 9k with 10GE Linecards and replacing (one-by-one) some Cisco 12410. Later these ASR 9k should carry 100GE links. So if I need to make bigger upgrades to the ASR 9k to make them 100GE capable, it is probably not profitable.) Thanks, -tim ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
On 16/11/2010 11:02, Mark Tinka wrote: We've been able to run GLC-* type modules in routers like the 7201 with no problem. I haven't tried the reverse on a switch. Last time i tried, an NPE-G2 refused to accept a GLC-SX-MM. You can imagine that this was surprising, to say the least. I will not repeat the sentiments or language that were expressed by the individuals involved at the time, but let's just say that it was considered Deeply Unhelpful that Cisco commodity hardware was not compatible with, uh, other cisco commodity hardware. This is a software version dependent, and that GLC-SX-MM transceivers will work on an NPE-G2, if you have the right software. More information on: http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.html Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
On Tuesday, November 16, 2010 05:29:46 pm jack daniels wrote: > Dear All, > > Are there any potential Technical issues with ignoring > Cisco and using GLC-LH-SM > rather than SFP-GE-L. What I can figure out is - > with GLC-LH-SM - no monitoring (no DOM) > SFP-GE-L higher cost. We've been able to run GLC-* type modules in routers like the 7201 with no problem. I haven't tried the reverse on a switch. The 7600 WS-X67xx line cards support either as far as we tested. We haven't tried the SFP-GE-* on the 6500. The GLC-* works on the integrated switches of the RP's on a CRS platform, but that's really a switch, so... Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GLC-LH-SM vs SFP-GE-L
Yes. Cisco doesn't even support their own optics depending on the device. Make sure the device you are using supports the GLC vs SFP. Basically: If you didn't buy the optics with the device, it may not work even with service unsupported-transciever, even if the optics are cisco purchased. I've asked various BUs to support other cisco sold optics and been told basically: "We don't care about you, go pound dirt." - Jared On Nov 16, 2010, at 4:29 AM, jack daniels wrote: > Dear All, > > Are there any potential Technical issues with ignoring Cisco and > using GLC-LH-SM > rather than SFP-GE-L. What I can figure out is - > with GLC-LH-SM - no monitoring (no DOM) > SFP-GE-L higher cost. > > > Regards > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] GLC-LH-SM vs SFP-GE-L
Dear All, Are there any potential Technical issues with ignoring Cisco and using GLC-LH-SM rather than SFP-GE-L. What I can figure out is - with GLC-LH-SM - no monitoring (no DOM) SFP-GE-L higher cost. Regards ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DFC3CXL CPU
On Tue, 2010-11-16 at 10:33 +0300, Sergey Nikitin wrote: > And once again, could anyone tell me what DFC CPU is used in the > WS-X6708-10G-3CXL? I believe that "remote command module X show version" > will show this information. Switch#show module | incl ^ 6 68 CEF720 8 port 10GE with DFCWS-X6708-10GE XXX 6 001d.45ff. to 001d.45ff. 1.3 12.2(18r)S1 12.2(33)SXI1 Ok 6 Distributed Forwarding Card WS-F6700-DFC3C XXX 1.0Ok 6 Pass Switch#remote command module 6 show version Cisco IOS Software, c6lc2 Software (c6lc2-SP-M), Version 12.2(33)SXI1, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Sat 28-Mar-09 10:29 by prod_rel_team ROM: System Bootstrap, Version 12.2(18r)S1, RELEASE SOFTWARE (fc1) Switch uptime is 1 week, 4 days, 2 hours, 8 minutes System returned to ROM by power-on System restarted at 07:20:58 CET Fri Nov 5 2010 Running default software cisco Catalyst 6000 (SB1121) processor with 1048576K bytes of memory. Processor board ID XXX SB1121 Processor (Rev 32) SB-1 CPU at 400Mhz, Implementation 0x401, Rev 0.3 Last reset from power-on 123K bytes of non-volatile configuration memory. 16384K bytes of Flash internal SIMM (Sector size 256K). Configuration register is 0x100 Switch# -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 deployment
Hi, On Tue, Nov 16, 2010 at 06:13:47AM +, Edward Iong wrote: > We are planning to implement IPv6 to our existing IPv4 network. Good! > There are several things I would like to ask:- > > 1. Can IPv4 and IPv6 devices exist at the same time in the same LAN? Yes. > and can they communicate with each other? No. That is: an IPv4-only device can not directly speak with an IPv6-only device. But your devices can be IPv4-and-IPv6 dual-stack, and speak both protocols at the same time. > 2. If both IPv4 and IPv6 devices can be in the same LAN, what kind of > rounting technology can route the ip packet? In the same LAN, no routing technology needed. Between LANs, OSPF, EIGRP, ISIS, BGP - whatevery you're used to. > 3. To route the traffic to the other LAN through WAN(MPLS), is it 6to4 will > need to be in place? > 4. To access internet, it points to our PIX instead of PE router(MPLS), so > is it I will need to implement 6to4 as well(if ISP can only provide ipv4 > public address)? Don't do 6to4. Either get your provider to provide IPv6, or change providers to one that provides IPv6, or get a tunnel from a tunnel broker (he.net or sixxs.net for example). > 5. We are using Microsoft IAS for Wireless connection and network device > access authentication. If we implement IPv6, will IAS support IPv6? No idea. > 6. Will PIX support IPv6? will have many site2site vpn connection. PIX supports IPv6, but you might need a software update. Dunno which version IPv6 started. > If anyone who has experiences in IPv6 implementation project, please let me > know as well. We're doing this since 13 years or so, so I'd count this as "some experience" :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp2G7fFAOrrE.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DFC3CXL CPU
Distributed Forwarding Card WS-F6700-DFC3C SB1121 Processor (Rev 32) SB-1 CPU at 400Mhz, Implementation 0x401, Rev 0.3 Aivars > Thank you all. > And once again, could anyone tell me what DFC CPU is used in the > WS-X6708-10G-3CXL? I believe that "remote command module X show version" > will show this information. > Thanks > Benjamin Lovell wrote: >> What he said, while adding that the CPU on the DFC is the same CPU as >> the SP on the PFC. DFC can still see pretty significant CPU usage as >> even if the RP or SP is doing the export the DFC CPU must still do all >> the recored creation, aging, etc. Very fast aging timers drive up the >> DFC CPU usage as this is the bulk of the work. Exporting is really just >> wrapping up the DFC made records in an IP packet to correct destination. >> >> -Ben >> >> On Nov 15, 2010, at 12:24 PM, Łukasz Bromirski wrote: >> >>> On 2010-11-15 16:31, Phil Mayers wrote: >>> Actually, as I understand it in certain configurations the NDE packets can be generated and emitted by the DFC CPU. As I recall, certain netflow options and/or masks prevent this from happening, and require the RP CPU to either modify the NDE packets which the DFC CPU generates, or generate the packets itself. IIRC things like src/dst AS number and other things you'd expect the RP to know, but the DFC to not, come into this category. >>> >>> Close :) >>> >>> Traditionally, a NDE is a work of active RP gathering the flows from >>> PFC TCAMs and DFC TCAMs if they're installed on the LCs and exporting >>> them to the external destination. >>> >>> Starting from 12.2(18)SXE onwards, the SP CPU (the one on the >>> Supervisor board) can export the traffic directly from non-DFC enabled >>> LCs, with the exception being a 6708-10GE (w/DFC) which can also export >>> autonomously. Other, DFC-enabled cards have to export the traffic via >>> the RP using EOBC as a transport between them and RP. >>> >>> -- >>> "Everything will be okay in the end. | Łukasz Bromirski >>> If it's not okay, it's not the end." | http://lukasz.bromirski.net >>> ___ >>> cisco-nsp mailing list cisco-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 deployment
On Tuesday, November 16, 2010 02:13:47 pm Edward Iong wrote: > 1. Can IPv4 and IPv6 devices exist at the same time in > the same LAN? Yes, this is called dual-stack. Single-stack is when only one of these IP protocols exists on the wire. > and can they communicate with each other? Well, not really - v4 talks to v4, and v6 talks to v6. But there are options one can use to transport one of these protocols over the other. > 2. If both IPv4 and IPv6 devices can be in the same LAN, > what kind of rounting technology can route the ip > packet? OSPFv3 provides v6 support for link-state routing, as does the current implementation of IS-IS. Current BGP-4 also supports v6 address families. So many of the routing protocols you're used to today already support a decent amount of v6. Static routing too :-). > 3. To route the traffic to the other LAN through > WAN(MPLS), is it 6to4 will need to be in place? If you choose the dual-stack option (which is my recommendation since it's simpler), you don't need to worry about making your MPLS network carry v6 traffic, although it can. Using MPLS to carry v6 traffic is known as 6PE. > 4. To > access internet, it points to our PIX instead of PE > router(MPLS), so is it I will need to implement 6to4 as > well(if ISP can only provide ipv4 public address)? Not sure whether the PIX supports v6 (never used one before). If it does, dual-stack is your friend. If it doesn't, not sure whether the PIX supports 6-in-4 tunneling. I find 6-in-4 tunneling to be the next best option after dual-stacking, in case your platform can run it. But that's just me... > 5. We > are using Microsoft IAS for Wireless connection and > network device access authentication. If we implement > IPv6, will IAS support IPv6? Not sure, don't use Windows much. But I know v6 is now mainstream in Vista and 7, but uncertain how much it bleeds into its other native applications. Someone else more Windows savvy than me can probably answer this one. Linux and FreeBSD have decent v6 support, as does Mac (a few things are broken, but it's a work-in-progress). > 6. Will PIX support IPv6? > will have many site2site vpn connection. See 4, above. > If anyone who has experiences in IPv6 implementation > project, please let me know as well. We've been running v6 in our Transit network since 2007 - I started running v6 in commercial production networks in 2005. We went the dual-stack route, even with our MPLS network in place. Lots of things to look out for, but there's is plenty of experience here: http://www.getipv6.info/index.php/Main_Page http://www.civil-tongue.net/6and4/ Lots of other resources online, too. The 'c-nsp' archives are quite handy too. One piece of advice I'd give, make sure any kit or software you're buying now supports v6, as well as any features you're looking to implement in your network. You don't want to realize, 36 months from now, that all the millions you spent on hardware can't support v6. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Software Download Enhancements
On Tuesday, November 16, 2010 08:27:09 am Michael Loftis wrote: > Ah, sort of. With Juniper there's basically there's one > image for each major product category -- more or less. > So the J series has an image, the M/T another. The MX > has it's image,... Ummh, not quite: - the M/MX/T all share the same image. > and last I knew there's two for the EX > series (one for like the EX2200s and another for the > EX8K boxen)... Not anymore - at the point where the EX-series arrived on the scene, based on currently supported software which is JUNOS 9.3, the all EX platforms shared a single image (but still separate from that used by the M/MX/T). This changed in 9.4, where the EX3200, EX4200 and EX8200 each got their own image. With 10.1, the EX2200 was added, with its own image too. With 10.2, the EX4500 was added, with its own image too. > There's even more consistency in > interface naming/numbering (IMO anyway, I've heard > others take a dislike to it!) I believe this is where the "a single OS" mantra could still apply. The core interface is generally the same across all platforms, although there are now a few platform-specific differences. Not that hard to keep track of, but worth taking note of all the same. What I do like with JUNOS is what Cisco have done with IOS XR (and I hope they don't change that) - just two feature sets, one with SSH, and another without. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 deployment
Edward, Some answers inline. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Edward Iong Sent: Tuesday, November 16, 2010 08:14 To: cisco-nsp@puck.nether.net Subject: [c-nsp] IPv6 deployment Dear All, We are planning to implement IPv6 to our existing IPv4 network. There are several things I would like to ask:- 1. Can IPv4 and IPv6 devices exist at the same time in the same LAN? and can they communicate with each other? [Arie Vayner] Yes, you can have IPv4 and IPv6 hosts on the same LAN, but they cannot communicate with each other directly. Most likely what you are looking for is to deploy your hosts in dual-stack mode, meaning they would have, at the same time, an IPv4 and an IPv6 address, and the hosts would select which one to use for a specific session (based on things such as DNS or other higher layer information) 2. If both IPv4 and IPv6 devices can be in the same LAN, what kind of rounting technology can route the ip packet? [Arie Vayner] IPv6 can use most of the same routing protocols but with some extensions. BGP, OSPF (v3...) ISIS and EIGRP can be used for IPv6. Also, RIP (RIPng) is possible. It works more or less the same way it does for IPv4, but there are some differences, and design considerations for each of the protocols. 3. To route the traffic to the other LAN through WAN(MPLS), is it 6to4 will need to be in place? [Arie Vayner] 6to4 is a tunneling technology for passing IPv6 traffic through an IPv4 only transient network. Other tunneling technologies can be used and each one has a different native application (for example hosts in a corporate LAN would most likely use a different technology than residential ADSL CPEs...) Also, if you manage the MPLS core, then there are 6PE and 6VPE which allow core networks to support IPv6 through MPLS. 4. To access internet, it points to our PIX instead of PE router(MPLS), so is it I will need to implement 6to4 as well(if ISP can only provide ipv4 public address)? [Arie Vayner] Most likely the right way would be to work with your ISP (or other ISP...) to get IPv6 support... You could also use some temporary tunneling solution. 5. We are using Microsoft IAS for Wireless connection and network device access authentication. If we implement IPv6, will IAS support IPv6? [Arie Vayner] No clue... sorry. 6. Will PIX support IPv6? will have many site2site vpn connection. [Arie Vayner] You should look at ASA or maybe ASR1K If anyone who has experiences in IPv6 implementation project, please let me know as well. Many Thanks, Edward ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DFC3CXL CPU
On 11/16/2010 04:13 AM, Benjamin Lovell wrote: What he said, while adding that the CPU on the DFC is the same CPU as the SP on the PFC. DFC can still see pretty significant CPU usage as even if the RP or SP is doing the export the DFC CPU must still do all the recored creation, aging, etc. Very fast aging timers drive up the DFC CPU usage as this is the bulk of the work. Exporting is really just wrapping up the DFC made records in an IP packet to correct destination. All interesting stuff; thanks guys ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Software Download Enhancements
g...@greenie.muc.de (Gert Doering) wrote: > On Tue, Nov 16, 2010 at 01:35:36AM +0100, ?ukasz Bromirski wrote: > > ...and a very limited subset of platforms comparing to Cisco. In terms > > of going forward, IOS is being unified under IOS-XR umbrella (SPs), > > NX-OS (DC) and IOS-XE (everything else). > > Looking forward to see IOS-XE on Cisco 800s, Linksys products, Access Points. Probably also means, "soft-reconfiguration inbound" will break on *all* platforms. Can you believe the account team wanted to *phone* me to *explain* why the bug would not be fixed? The nerve. Elmar. pgp2lk1kdJy1V.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
