[c-nsp] IOS XR MLACP and L3VPN static routes
We have a setup where a pair of A99K boxes (IOS XR 7.1.3) are working as PE routers, and on MLACP (active/standby) Bundle towards Metro Switch are mixed L2/L3 subinterfaces. When we try to configure static routes on standby node in customer VRF, routes are advertised through both active and standby PoAs to the core MPLS (it is advertised on both routers). Is there any way on IOS-XR (7.1.3) that provides blocking of advertising static routes on standby PoA in L3VPN MC-LAG environment. Something tells me that this is not normal behavior (BUG maybe, or feature XD ) I've found that on IOS-XE this works normal, feature is called: Multichassis Link Aggregation Group for L3VPN https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/xe-16-9/mp-l3-vpns-xe-16-9-book/mc-lag-for_l3vpn.pdf ___ 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] ASR9K XR 6.4.2 and SNMP monitoring
Sorry - I was unclear. I was referring to the OID(s) for the alarms in the original post (no issues regarding the systemowner bit). :-) On Fri, 20 Dec 2019 at 00:21, Gert Doering wrote: > Hi, > > On Thu, Dec 19, 2019 at 10:25:45PM +1300, Ivan Walker wrote: > > If you do work this out please share. I did search and was unsuccessful > on > > older software sometime ago. > > There's this thing called "Google". Third hit on a search for > "IOS XR SNMP privilege" turns up this link: > > > https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/system_management/command/reference/b_sysman_cr41crs/b_sysman_cr41crs_chapter_01110.pdf > > which suggests the missing bit might be adding "SystemOwner" to the > "snmp-server community..." commnads. > > As in > > snmp-server community MySecret RO SystemOwner > > > (we do not have this active anywhere right now, but it rings familiar) > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ 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] ASR9K XR 6.4.2 and SNMP monitoring
If you do work this out please share. I did search and was unsuccessful on older software sometime ago. Ivan On Thu, 19 Dec 2019 at 08:03, Gert Doering wrote: > Hi, > > On Wed, Dec 18, 2019 at 09:27:46AM -0800, Lee Starnes wrote: > > I did check out both the alarm and environment MIBs and none of the OIDs > in > > them come back as valid. In fact, a walk of those enterprise OIDs results > > in no such object on this agent. > > ISTR that there is a magic "admin" config setting that makes "critical" > SNMP information visible, which is normally hidden. Chassis information > is part of that. > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ > 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] Cisco 4000 series (4461) as a BGP router?
Lukasz, > That’s true of course. 9901 would be better entry-level choice with > years in front of it. I find that the 9901 being entry level is quite high. There is the 120Gbps license but the device itself is quite heavy and large and the power consumption more than the 9001. I think the success of the ASR920 shows that small size and low power usage are highly valued. I would love to see a smaller option - just a single NPU, maybe 1RU, and half the power usage. This would give a much more fitting entry level model and allow users to push out the ASR99xx 64bit xr model to smaller sites where the ASR9901 is just too big . Thanks Ivan ___ 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] ASR920 and ASR9001 SPAN / Traffic Capture
ASR920: Running 16.6.3. Ideal outcome would be to have a SPAN session with a source from a service instance (EFP) into a a PW (PW-SPAN). This doesn't seem to be supported. Any known work arounds? I did find https://lists.gt.net/cisco/nsp/193632?page=last that suggested using a loopback cable. Not that elegant, burns up ports and it seems the local span doesn't support EFPs as a source either - just entire physical ports. Interestingly enough the command line seems to allow configuring EFP as a source but doesn't actually work. monitor session 1 type local source service instance 4 GigabitEthernet0/0/0 destination interface Gi0/0/11 Anyone put in a feature request for mirroring from an EFP or for PW-SPAN on the ASR920? ASR9001: Running 6.2.3. This platform does support PW-SPAN, but as far as I can tell it is not possible to use PW-Ether interfaces (PWHE) as a source. Any known work around for this or has anyone raised a feature request for this? Thanks Ivan ___ 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] ASR9K Upgrade
Also beware of http://www.cisco.com/c/en/us/support/docs/field-notices/639/fn63979.html "On October 17, 2015, the previously implemented CSS certificates used in classic Cisco IOS-XR will expire. *After the October 17, 2015 expiration date*, attempts to install a new Cisco IOS-XR image, SMU, or PIE *without the mandatory SMU installed first will fail*." On 13 March 2016 at 22:24, Tassos Chatzithomaoglou wrote: > > https://supportforums.cisco.com/document/123576/asr9000xr-understanding-turboboot-and-initial-system-bring > > -- > Tassos > > Mohammad Khalil wrote on 13/3/16 09:34: > > Dears > > I am trying to upgrade my ASR9K router from 4.3.2 to 5.3.2 > > The issue am facing is the space , am running out of space > > My questions are: > > Like IOS , if I deleted the existing OS while the system is running , > well the system keeps functioning? > > What the packages do I need to install (minimum) for the system to boot > up successfully with no problems and then I can remove the old OS packages? > > > > Thanks > > > > BR, > > Mohammad > > > > > > ___ > > 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] PBB-EVPN
Thanks for the response. > LACP PDUs are layer-2 and can be transported across Ethernet circuits. > Providing your Ethernet provider will accept & L2PT those frame types, > it is possible to run LACP across the sort of circuit you're describing. > Talk to your providers! If you coupled that with some form of LACP-based > MLAG/MC-LAG/VPC (not all vendor implementations are) then you might be > able to do PE resilience. > > I am thinking the issue is having to pop out the tunnelled (L2PT) LACP frames at the core end. Especially if the service is delivered over a shared NNI interface. Imagine if the tagged service at the NNI is taken to the I-Component via a pseudowire attachment circuit I don't think there is any LACP function on the core side. Popping the L2PT LACP out on a physical port somewhere else doesn't really scale. > AFAIR, SPB-M goes further to remove the multi-homing issues inherent in > PBB, but I've not done any good reading into PBB-EVPN to see if you can > simply multi-home a given C-MAC address and have it work. If it is > hobbled in the same way that PBB is, then yeah, I can see a world where > LACP is the only way forward. Still, it seems oddly limiting. I will have a look into SPB-M - hadn't heard of it. :-) ___ 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] PBB-EVPN
I have been looking into PBB-EVPN and would be interested in hearing experience from others. As far as I have understood there are two real benefits: 1) PBB / MAC in MAC reduces the load on BGP as BGP only needs to worry about the B-MACs 2) Per-flow redundancy and load balancing Is it correct that the only way to connect a CE device to 2 PEs for all active per-flow redundancy is via LACP? Given that LACP operates at the physical port level this seems a little limiting. I am thinking scenarios where the PE-CE link(s) may be some kind of l2 service from third parties delivered over a shared NNI, or perhaps where pseudowire attachment circuits are used (into the I-Component). Thanks Ivan ___ 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] ASR920 Buffers
I understand the ASR920 has a 12MB shared buffer (compared with 44MB for for the ME3600X and 352MB for the ME3800X) Can anyone using the ASR920 provide feedback on how they have found the buffer size? Thanks Ivan ___ 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] ME3600X mLDP
A very interesting discussion. In regards to NG-mVPN when there are ME3600Xs in the network what are the options? *Replace *Don't use the ME3600X to terminate L3VPN/NG-mVPN. What is the implication when ME3600X may still be in traffic some paths but there is no mLDP - RPF issues? *Ingress replication - guessing not supported on ME3600X but would be an option if terminating L3VPN/NG-mVPN on devices that can do NG-mVPN. And when ME3600Xs are around in the network and not supporting mLDP. Is ingress replication an evil option that will kill the ingress PE? * Anything else? ___ 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] ME3600X mLDP
Thanks Mark for clearing that up. Not the answer that I wanted in regards to the ME3600X as I have some already. Great to see the ASR920 is going well as I will be getting some. Cheers Ivan On 9 July 2015 at 22:44, Mark Tinka wrote: > > > On 9/Jul/15 03:36, Ivan wrote: > > I am hoping someone can confirm if the Cisco ME3600X and ME3800X support > > mLDP. Some older emails to this list suggest this feature was expected > in > > 2013. Looking at the Software Research tool some IOS versions show up as > > having "MLDP-Based MVPN Multicast". I have tried few versions but can't > > get capabilities P2MP, MP2MP. > > mLDP is not supported on the ME3600X, and will never. > > It is, however, supported on the ASR920. Tested and works like a charm. > > 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/
[c-nsp] ME3600X mLDP
I am hoping someone can confirm if the Cisco ME3600X and ME3800X support mLDP. Some older emails to this list suggest this feature was expected in 2013. Looking at the Software Research tool some IOS versions show up as having "MLDP-Based MVPN Multicast". I have tried few versions but can't get capabilities P2MP, MP2MP. 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/
[c-nsp] ME3600X mLDP
I am hoping someone can confirm if the Cisco ME3600X and ME3800X support mLDP. Some older emails to this list suggest this feature was expected in 2013. Looking at the Software Research tool some IOS versions show up as having "MLDP-Based MVPN Multicast". I have tried few versions but can't get capabilities P2MP, MP2MP. Thanks Ivan ___ 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] Help with an IPSec scenario
Hi Tom, Try with 'general-ikeid' on SRX side under the definition of ike gateway. You might need to upgrade Junos to have that option. host@srx# set security ike gateway general-ikeid HTH, Ivan, On Fri, Mar 13, 2015 at 3:35 PM, Tom Storey wrote: > Hi everyone, > > Trying to establish an IPSec tunnel (route based) between a Juniper > SRX and a Cisco IOS router. > > The topology is two routers with DSL services, the SRX is on a dynamic > IP, the Cisco on a static. No NAT is involved in the path between the > two routers. > > Heres the configs Im working on: http://pastebin.com/gUEFVTau > > Basically what Im getting is this... > > In main mode, phase 1 is OK, and I get probably 99% of the way in > phase 2, but it doesnt quite complete, with errors like "proxy > identities not supported". > > I can fix this by configuring Tunnel0's destination as the IP of the > SRX /at the time/ and can then ping across the tunnel. But this > obviously isnt a long term solution because if the IP of the SRX > changes (and it does, frequently, because the DSL is notoriously > unstable) then the VPN stops working. > > So I try to go aggressive mode, but this is even worse, with phase 1 > not completing with errors like "IKE packet from x.x.x.x was not > encrypted and it should've been", and never really making it past > AG_INIT_EXCH. > > This is a debug of aggressive mode: http://pastebin.com/RUAaXDyE > > Based on my supplied configs, can anyone help me come up with a > solution that allows the SRX to initiate a connection from any random > IP, and the Cisco accepts it but I dont have to configure the IP of > the SRX on the Cisco in order for it to work? I feel like Im > tantalisingly close, but after several hours at it so far and copious > amounts of googling, I just cant see the solution... > > 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/ > -- Best Regards! Ivan Ivanov ___ 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] ASR1000 IOS Version
I am looking to upgrade a number for ASR1004s. After previous comments on the list I was looking to use 3.10.5S / 15.3(3)S5 (a Cisco recommended release). I see 3.13.2S / 15.4(3)S2 is also a Cisco recommended release. Any thoughts or experiences that can be shared would be great. I am leaning towards 3.10.5S. No special requirements for new features. Thanks Ivan ___ 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] BGP error with optional attribute
Hi, Most probably you have to enable explicitly 'family inet6 unicast' under Juniper bgp configuration. But to be sure could you share the configuration on both ends? HTH Ivan, On Fri, Dec 19, 2014 at 7:51 PM, Harold Ritter (hritter) wrote: > Hi Thiyagarajan, > > You are apparently running into CSCtf27303. > > https://tools.cisco.com/bugsearch/bug/CSCtf27303 > > Regards, > > Harold > > > > Le 2014-12-19 10:29, « thiyagarajan b » a > écrit : > > >Hi everyone, > > > >I have a problem in iBGP between Cisco 7301 and juniper mx series router > >where the BGP got flapped throwing the following error in cisco end: > > > >%BGP-3-NOTIFICATION: received from neighbor 119.227.0.65 3/9 (unsupported > >option specified) 0 bytes > >%BGP-5-ADJCHANGE: neighbor 119.227.0.65 Down BGP Notification received > > > >%BGP-3-NOTIFICATION: received from neighbor 119.227.0.65 6/5 (cease) 0 > >bytes > > > >and found the following log in juniper > > > >rpd[1296]: bgp_read_v4_update:9690: NOTIFICATION sent to 210.18.0.181 > >(Internal AS 9583): code 3 (Update Message Error) subcode 9 (error with > >optional attribute), Reason: peer 210.18.0.181 (Internal AS 9583) UPDATE - > >NLRI inet6-unicast not negotiated > >rpd[1296]: Received BAD update from 210.18.0.181 (Internal AS 9583), > >family > >inet6-unicast(16), prefix 2a02:2158::/32 > > > >So is this problem caused by the prefix 2a02:2158::/32 because of it > >invalid attribute? or is it because of any mismatch SAFI update between > >the > >routers? > > > >Please suggest. > > > > > >Warm Regards, > >Thiyagarajan B. > >___ > >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/ > -- Best Regards! Ivan Ivanov ___ 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] ASR1006 Memory issue
Hi Tim, Could you elaborate on rommon version comment please. I will be upgrading myself shortly. Thanks Ivan On 16/Dec/2014 2:39 a.m., Tim Warnock wrote: Watch your rommon version too. -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jordi Magrané Roig Sent: Monday, 15 December 2014 11:34 PM To: mark.ti...@seacom.mu; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR1006 Memory issue Hello, Lukas and Mark, thanks for the information. I'm planning to upgrade the device but it will take some weeks. My worry is to check now if the device has problems. Somebody knows how I could check if the device is working fine? Thanks! From: mark.ti...@seacom.mu To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR1006 Memory issue Date: Mon, 15 Dec 2014 13:51:32 +0200 CC: luky...@hotmail.com; jordimagr...@hotmail.com On Monday, December 15, 2014 01:08:32 PM Lukas Tribus wrote: I suggest you ugprade to the latest rebuild of a supported long-term support branch (3.10S?). I'd say go to 3.10(4)S, which is 15.3(3)S4. We were on 15.4(2)S earlier and that has some serious BGP bugs that lead to router crashes, as well as other random crashes. Suffice it to say, Cisco say 3.10(4)S is their recommended release for this platform. 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/ ___ 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] IOS XR as-path-loopcheck and as-override
Hi James, Just some ideas here: In MPLS Option B and ASBR peering we exchange bgp vpnv4 labels to create LSP all the way .So we need to disable the bgp label filtering on ASBRs -On XR : router bgp -->add-family vpnv4 uni--retain route-target all. But i believe that’s not the case here as you configured the vrf on the XR. Another thing with XR and ASBR peering is that in IOS under the interface connected to the peer on the other AS mpls bgp forwarding is added automatically as there is /32 entry on CEF .Thats not the case in XR. So for the labels to be exchanged b/n the ASBR we need to manually add /32 entry for the interface connected to the ASBR peer from the other AS!!: router static-->add-family ipv4 uni-->20.0.1.1/32 int gi0/0/0/0.1/for example/.I came across the issue .Hope this helps. Ivan On Tuesday, October 28, 2014 1:45 PM, Vitkovský Adam wrote: Hi James, > I can't get the ASR9K to send the route from either eBGP neighbour in AS 65001 > to the other. May I know your reasoning behind this nonstandard setup please? As the 9K1s should know the routes from each other via the intra-AS paths. From the top of my head I can't think of a reason why it should not work. So the Ak9 in remote AS is advertising the routes over Opt.B to AS65001 but ASR9001s are dropping them please? Or the Ak9 in remote AS is not even attempting to advertise the routes back to AS65001 please? The quickest way to figure things out is to use debug. debug bgp update vpnv4 u in (rpl) or debug bgp update vpnv4 u out (rpl) adam > -Original Message- > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of > James Bensley > Sent: Tuesday, October 28, 2014 11:32 AM > To: cisco-nsp@puck.nether.net > Subject: [c-nsp] IOS XR as-path-loopcheck and as-override > > Hi All, > > I can't seem to get these features to work on my lab ASR9K1 running 4.3.4. I > have two eBGP neighbours in AS 65001 both advertising a /32 loopback to the > ASR9K (MPLS Opt B peerings). As per the output below the ASR9K receives the > /32 route from each eBGP neighbour. > > I can't get the ASR9K to send the route from either eBGP neighbour in AS 65001 > to the other. > > I have added "as-path-loopcheck out disable" under both address-families > under BGP and under the test VRF "vrf". I have also configured "as-override" > on > one of the neighbours (192.168.1.6) in both address-families. > > I understand how both of those features work, I'm not sure whythough despite > enabling them everywhere out of desperation I still don't advertise the /32 > route from 192.168.1.2 to 192.168.1.6 in the test VRF. > > RP/0/RSP0/CPU0:ASR9001#show route vrf vrf1 > > L10.0.0.1/32 is directly connected, 20:25:10, Loopback1 > B10.0.0.2/32 [20/0] via 192.168.1.6 (nexthop in vrf default), 00:08:53 > B10.0.0.3/32 [20/0] via 192.168.1.2 (nexthop in vrf default), 17:03:24 > > RP/0/RSP0/CPU0:ASR9001#show bgp vpnv4 unicast neighbors 192.168.1.6 > advertised-routes > > NetworkNext HopFromAS Path > Route Distinguisher: 5:1 > 10.0.0.1/32192.168.1.5 Local ? > > Processed 1 prefixes, 1 paths > > ASR9K: > > router bgp 5 > address-family ipv4 unicast > as-path-loopcheck out disable > allocate-label all > ! > address-family vpnv4 unicast > as-path-loopcheck out disable > ! > neighbor 192.168.1.2 > remote-as 65001 > address-family ipv4 labeled-unicast >route-policy PASS in >route-policy PASS out >send-extended-community-ebgp >next-hop-self > ! > address-family vpnv4 unicast >route-policy PASS in >route-policy PASS out >next-hop-self > ! > ! > neighbor 192.168.1.6 > remote-as 65001 > address-family ipv4 labeled-unicast >route-policy PASS in >route-policy PASS out >as-override >send-extended-community-ebgp >next-hop-self > ! > address-family vpnv4 unicast >route-policy PASS in >route-policy PASS out >as-override >next-hop-self > ! > ! > vrf vrf1 > rd 5:1 > address-family ipv4 unicast >as-path-loopcheck out disable >redistribute connected >allocate-label all > > > Any help would be greatly appreciated as I expected I have overlooked > something really obvious. > > Cheers, > James. > ___ > 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] Fiber Cable Guide
Thanks. Did see those but they look quite a bit bigger. On 6/Sep/2014 9:46 p.m., Howard Jones wrote: On 06/09/2014 03:13, Ivan wrote: I am looking for some fiber cable guides like the Cisco ones here http://www.cisco.com/c/dam/en/us/td/i/31-40/360001-37/363001-364000/363563.eps/_jcr_content/renditions/363563.jpg (These ones are for Cisco ONS. http://www.cisco.com/c/en/us/td/docs/optical/hardware/15454install/guide/hig15454/hig_15454.html#pgfId-655145) I have had no luck finding anything similar myself and would appreciate if anyone can point me to some. Like this: http://www.martinenclosures.com/product/fiber-rings/ ? ___ 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] Connecting PoP's with long distance
Hi Jared, This is something I have also been looking at. Is there any particular brand of XFP you have had success with? If we take the Cisco "80km" ZR we have TX 0 to 4 dBm and RX -7 to -24 dBm - worst case 24dB budget excluding splices, patches etc. Assuming 0.2dB/km 120km would be right on the limits. I would like to have some buffer. Thanks Ivan On 5/Sep/2014 1:32 a.m., Jared Mauch wrote: You should be able to do 120km with a ZR XFP @ 10G without anything. If you later want to add equipment to the sites, you can look at doubling your optics and something like this: http://www.perle.com/products/10-Gigabit-Standalone-Media-Converters.shtml - Jared On Sep 4, 2014, at 5:36 AM, Murat Kaipov wrote: Hello Guys. I need connect two PoP's with 10G links. Distance between PoP's nearly 120km. We have fiber optic between PoP's with two regeneration points located nearly in 40 km between each other. We have not DWDM. Can you advise some equipment (May be like EDFA) for fiber optic regeneration points Scheme like this PoP-1 ---40km---[Regeneration point1]---40km[Regeneration point2]-40km--PoP2 Thank you. ___ 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/
[c-nsp] Fiber Cable Guide
I am looking for some fiber cable guides like the Cisco ones here http://www.cisco.com/c/dam/en/us/td/i/31-40/360001-37/363001-364000/363563.eps/_jcr_content/renditions/363563.jpg (These ones are for Cisco ONS. http://www.cisco.com/c/en/us/td/docs/optical/hardware/15454install/guide/hig15454/hig_15454.html#pgfId-655145) I have had no luck finding anything similar myself and would appreciate if anyone can point me to some. Thanks Ivan ___ 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] L2TP/IPSec
I don't believe it is possible and have not been able to find any examples or documentation for site-to-site VPNs using L2TP/IPSec on Cisco ISR routers. (Actually really looking to do L2TP/IPSec between Cisco and Microsoft TMG) I would appreciate if someone could confirm it is not possible or perhaps point to some doco, hopefully with examples. (Note all doco I have found is for client vpns and ASAs). Thanks Ivan ___ 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] IOS XR - CBAC/ZBF or similar
I have been unable to find CBAC/ZBF or similar on IOS XR. I suspect these featires are not available but would be happy if someone could prove me wrong. Thanks Ivan ___ 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] Cisco 7600 pseudowire ping
Interesting enough regular mpls ping has no issue: PE1#ping mpls ipv4 172.16.14.1/32 repeat 100 Sending 100, 100-byte MPLS Echos to 172.16.14.1/32, timeout is 2 seconds, send interval is 0 msec: Codes: '!' - success, 'Q' - request not sent, '.' - timeout, 'L' - labeled output interface, 'B' - unlabeled output interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 'P' - no rx intf label prot, 'p' - premature termination of LSP, 'R' - transit router, 'I' - unknown upstream index, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. !! !! Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms PE1#ping mpls pseudowire 172.16.14.1 440 repeat 100 Sending 100, 100-byte MPLS Echos to 172.16.14.1, timeout is 2 seconds, send interval is 0 msec: Codes: '!' - success, 'Q' - request not sent, '.' - timeout, 'L' - labeled output interface, 'B' - unlabeled output interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry, 'P' - no rx intf label prot, 'p' - premature termination of LSP, 'R' - transit router, 'I' - unknown upstream index, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. !!.!.!!.!!.!!! !!!.!. Success rate is 94 percent (94/100), round-trip min/avg/max = 1/2/4 ms PE1# And the rate-limit output on the destination: PE2#show mls rate-limit | in Rate|On|UCAST Rate Limiter Type Status Packets/s Burst Sharing MCAST DFLT ADJ On 10 100 Not sharing ACL VACL LOG On2000 1 Not sharing MCAST PARTIAL SC On 10 100 Not sharing IP RPF FAILURE On 100 10 Group:0 S TTL FAILURE On 97 10 Not sharing ICMP UNREAC. NO-ROUTE On 100 10 Group:0 S ICMP UNREAC. ACL-DROP On 100 10 Group:0 S MTU FAILURE On 997 10 Not sharing UCAST IP OPTION Off - - - IP ERRORS On 100 10 Group:0 S As mentioned before we are only seeing this on devices where we are running 15.2(4)S4a Thanks Ivan On 21/Jul/2014 7:56 p.m., Vitkovský Adam wrote: And how about the regular mpls ping does that perform right? I'd check the rate limiters: show mls rate-limit and look for UCAST IP OPTION -is it ON or OFF though it should be off by default adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan Sent: Sunday, July 20, 2014 12:58 AM To: Peter Persson Cc: cisco-nsp Subject: Re: [c-nsp] Cisco 7600 pseudowire ping No CoPP. Direct ping is fine. Just the PW ping having issues. On 20/Jul/2014 2:13 a.m., Peter Persson wrote: Do you have any Control-plane policing? As i understand your email, you are pinging between two 7600's directly and not anything behind it? 2014-07-19 13:47 GMT+02:00 Ivan mailto:cisco-...@itpro.co.nz>>: I have found that mpls pseudowire pings to some 7600s running 15.2(4)S4a go missing - I see about 95/100 success rate. On other devices with older software I have no loss. The problem is not seen if the ping interval is increased to 100ms. Also pinging over the VC shows no loss. Given the above I suspect some rate-limiting may be taking place. I am hoping someone will be able to confirm and ideally share some commands that show come counters for the drops as so far I have had no success. c7600s72033-advipservicesk9-__mz.152-4.S4a.bin WS-X6704-10GE WS-SUP720-3BXL Thanks Ivan _ cisco-nsp mailing list cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net> https://puck.nether.net/__mailman/listinfo/cisco-nsp <https://puck.nether.net/mailman/listinfo/cisco-nsp> archive at http://puck.nether.net/__pipermail/cisco-nsp/ <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] Cisco 7600 pseudowire ping
No CoPP. Direct ping is fine. Just the PW ping having issues. On 20/Jul/2014 2:13 a.m., Peter Persson wrote: Do you have any Control-plane policing? As i understand your email, you are pinging between two 7600's directly and not anything behind it? 2014-07-19 13:47 GMT+02:00 Ivan mailto:cisco-...@itpro.co.nz>>: I have found that mpls pseudowire pings to some 7600s running 15.2(4)S4a go missing - I see about 95/100 success rate. On other devices with older software I have no loss. The problem is not seen if the ping interval is increased to 100ms. Also pinging over the VC shows no loss. Given the above I suspect some rate-limiting may be taking place. I am hoping someone will be able to confirm and ideally share some commands that show come counters for the drops as so far I have had no success. c7600s72033-advipservicesk9-__mz.152-4.S4a.bin WS-X6704-10GE WS-SUP720-3BXL Thanks Ivan _ cisco-nsp mailing list cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net> https://puck.nether.net/__mailman/listinfo/cisco-nsp <https://puck.nether.net/mailman/listinfo/cisco-nsp> archive at http://puck.nether.net/__pipermail/cisco-nsp/ <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] Cisco 7600 pseudowire ping
I have found that mpls pseudowire pings to some 7600s running 15.2(4)S4a go missing - I see about 95/100 success rate. On other devices with older software I have no loss. The problem is not seen if the ping interval is increased to 100ms. Also pinging over the VC shows no loss. Given the above I suspect some rate-limiting may be taking place. I am hoping someone will be able to confirm and ideally share some commands that show come counters for the drops as so far I have had no success. c7600s72033-advipservicesk9-mz.152-4.S4a.bin WS-X6704-10GE WS-SUP720-3BXL Thanks Ivan ___ 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] IPv6 duplicate address
So following on from a very old thread https://puck.nether.net/pipermail/cisco-nsp/2008-May/051088.html I have had an event where an interface got stuck in stalled state for much longer than is desirable. I tried to fix it using "ipv6 nd dad attempts 5" but no luck. I also tried disabling and enabling IPv6 on the interface that also didn't work. Manually setting the link-local address (and setting back) fixed things, but I have a few questions. Does DAD just stay in stalled state until some kind of manual intervention takes place? (Perhaps there is a method of have periodic retires?) Does "ipv6 nd dad attempts 5" help? How often are attempts made by default. I am thinking this could help prevent the stalled state in the future. This for IOS 15.2(4)S1 on an ASR1k. Thanks Ivan ___ 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] Cisco 4900M and Layer2 Broadcasts
Problem solved with "no ip verify header vlan all". It seems Cisco 4500/6500 (including the 4900M) switches do some verification of layer 3 headers (probably only the IPv4 ones as IPv6 had no issues). This happens even for layer 2 switched traffic. It is almost certain that the "HA" traffic is a little custom - at the very least I found the IP header checksum always zero (and it wasn't any fancy NIC offloading). So a few interesting commands show platform software drop-port (especially the outout for InpL2AclDrop) show platform hardware acl input entries static (especially the output for Ipv4HeaderException) And it seems this issue has been seen before, but Juniper has fixed the issue. "In Junos version 10.0 and below, the fabric link probes are using Juniper proprietary IP datagrams, where IP Total Length field is set to 0" http://kb.juniper.net/InfoCenter/index?page=content&id=KB15141 http://juniper-frac.blogspot.co.nz/2009/09/deploy-srx-cluster-across-layer-2.html Thanks to TAC. I have had some long cases but this one was sorted nice and quick! Cheers Ivan On 1/Jul/2014 1:03 p.m., Chris Marget wrote: Your case reminds me of something Tim Stevenson said about N7K and IPv4 multicast. I don't remember the details exactly, but he left me with the impression that the L2 filtering stuff for multicast frames, which usually doesn't do *exactly* what you want (subscribe to 239.1.2.3 and you'll get L2 traffic for 239.2.2.3 as well) was "fixed" on N7K: It filters/forwards at L2 using L3 criteria. Your problem is almost exactly the other way around. Sorry I don't have any answers, thanks for filling me in on the application. It makes sense that these crazy frames are generated by a "magic box" HA setup. Good luck, and please follow up with the list if TAC gives you anything helpful.. /chris On Mon, Jun 30, 2014 at 4:21 PM, Ivan mailto:cisco-...@itpro.co.nz>> wrote: Hi Chris, The traffic is some kind of state replication mechanism between to geographically diverse appliances. My guess is that the appliances are sending layer 3 headers inside layer 2 broadcast over the HA vlan. Someone asked out the config - can't get much more simpler. Also remember is working fine for IPv6. Ingress port: interface GigabitEthernet2/13 switchport trunk allowed vlan 327 switchport mode trunk switchport nonegotiate mtu 9198 load-interval 30 flowcontrol receive off flowcontrol send off no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable Egress port (same device for testing): interface TenGigabitEthernet2/7 switchport access vlan 327 switchport trunk allowed vlan none switchport mode access switchport nonegotiate mtu 9198 load-interval 30 flowcontrol receive off flowcontrol send off no cdp enable Also the counters someone was suggesting looking at; AKNNR-ISP-SW1#show int counters detail | in 2/13|Port Port InBytes InUcastPkts InMcastPkts InBcastPkts Gi2/13 222183306824 00 2114072064 PortOutBytes OutUcastPkts OutMcastPkts OutBcastPkts Gi2/13 682063116 061300 5592900 Port InPkts 64OutPkts 64InPkts 65-127 OutPkts 65-127 Gi2/13 0 1 2106943835 5103190 Port InPkts 128-255 OutPkts 128-255 InPkts 256-511 OutPkts 256-511 Gi2/13 71282265510090 0 Port InPkts 512-1023 OutPkts 512-1023 Gi2/13 0 0 PortInPkts 1024-1518 OutPkts 1024-1518 InPkts 1519-1548 OutPkts 1519-1548 Gi2/13 0 00 0 PortInPkts 1549-9216 OutPkts 1549-9216 Gi2/13 0 0 PortTx-Bytes-Queue-1 Tx-Bytes-Queue-2 Tx-Bytes-Queue-3 Tx-Bytes-Queue-4 Gi2/13 4413448 00 0 PortTx-Bytes-Queue-5 Tx-Bytes-Queue-6 Tx-Bytes-Queue-7 Tx-Bytes-Queue-8 Gi2/13 0 00 677643104 PortTx-Drops-Queue-1 Tx-Drops-Queue-2 Tx-Drops-Queue-3 Tx-Drops-Queue-4 Gi2/13 0 00 0 PortTx-Drops-Queue-5 Tx-Drops-Queue-6 Tx-Drops-Queue-7 Tx-Drops-Queue-8 Gi2/13 0 00
Re: [c-nsp] Cisco 4900M and Layer2 Broadcasts
Hi Chris, The traffic is some kind of state replication mechanism between to geographically diverse appliances. My guess is that the appliances are sending layer 3 headers inside layer 2 broadcast over the HA vlan. Someone asked out the config - can't get much more simpler. Also remember is working fine for IPv6. Ingress port: interface GigabitEthernet2/13 switchport trunk allowed vlan 327 switchport mode trunk switchport nonegotiate mtu 9198 load-interval 30 flowcontrol receive off flowcontrol send off no cdp enable spanning-tree portfast trunk spanning-tree bpdufilter enable Egress port (same device for testing): interface TenGigabitEthernet2/7 switchport access vlan 327 switchport trunk allowed vlan none switchport mode access switchport nonegotiate mtu 9198 load-interval 30 flowcontrol receive off flowcontrol send off no cdp enable Also the counters someone was suggesting looking at; AKNNR-ISP-SW1#show int counters detail | in 2/13|Port Port InBytes InUcastPkts InMcastPkts InBcastPkts Gi2/13 222183306824 00 2114072064 PortOutBytes OutUcastPkts OutMcastPkts OutBcastPkts Gi2/13 682063116 061300 5592900 Port InPkts 64OutPkts 64InPkts 65-127 OutPkts 65-127 Gi2/13 0 1 2106943835 5103190 Port InPkts 128-255 OutPkts 128-255 InPkts 256-511 OutPkts 256-511 Gi2/13 71282265510090 0 Port InPkts 512-1023 OutPkts 512-1023 Gi2/13 0 0 PortInPkts 1024-1518 OutPkts 1024-1518 InPkts 1519-1548 OutPkts 1519-1548 Gi2/13 0 00 0 PortInPkts 1549-9216 OutPkts 1549-9216 Gi2/13 0 0 PortTx-Bytes-Queue-1 Tx-Bytes-Queue-2 Tx-Bytes-Queue-3 Tx-Bytes-Queue-4 Gi2/13 4413448 00 0 PortTx-Bytes-Queue-5 Tx-Bytes-Queue-6 Tx-Bytes-Queue-7 Tx-Bytes-Queue-8 Gi2/13 0 00 677643104 PortTx-Drops-Queue-1 Tx-Drops-Queue-2 Tx-Drops-Queue-3 Tx-Drops-Queue-4 Gi2/13 0 00 0 PortTx-Drops-Queue-5 Tx-Drops-Queue-6 Tx-Drops-Queue-7 Tx-Drops-Queue-8 Gi2/13 0 00 0 PortDbl-Drops-Queue-1 Dbl-Drops-Queue-2 Dbl-Drops-Queue-3 Dbl-Drops-Queue-4 Gi2/13 0 0 0 0 PortDbl-Drops-Queue-5 Dbl-Drops-Queue-6 Dbl-Drops-Queue-7 Dbl-Drops-Queue-8 Gi2/13 0 0 0 0 Port Rx-No-Pkt-Buff RxPauseFramesTxPauseFrames PauseFramesDrop Gi2/13 0 00 0 PortUnsupOpcodePause Gi2/13 0 Have logged a support case so hopefully can report back more soon. Thanks Ivan On 1/Jul/2014 1:20 a.m., Chris Marget wrote: Hi Ivan, Your L2 broadcast / L3 unicast traffic has piqued my curiosity. Can you share some details about the use case for this unusual traffic? I have a project in mind where I'll be doing exactly the opposite: IPv4 multicast in Ethernet unicast. My use case is a multicast application with an un-graceful startup. If the application restarts mid-day, there's a long delay while it collects state information from incoming multicast packets. There is no mechanism for priming this application - the only option right now is to wait while the infrequent state messages re-build the state database. I plan to cache incoming state data in an L2 adjacent server, and blast this traffic at any instances which have recently restarted. I can't mess with the traffic at all because it's cryptographically signed by the sender, and I have to do it with unicast frames because the anti-replay mechanisms mean it's trouble if I deliver these packets to the wrong box. Thanks! /chris ___ 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] Cisco 4900M and Layer2 Broadcasts
Thanks for the response. The layer 3 traffic is unicast. I have poked around further and found the counters from the command "show platform software drop-port" for "InpL2AclDrop" are increasing with my missing packets. 4900M#show platform software drop-port | in Drop Event Reason|InpL2AclDrop|Time Time source is NTP, 16:35:59.675 NZST Sun Jun 29 2014 Drop Event ReasonPackets Dropped InpL2AclDrop1433452028 4900M#show platform software drop-port | in Drop Event Reason|InpL2AclDrop|Time Time source is NTP, 16:36:02.843 NZST Sun Jun 29 2014 Drop Event ReasonPackets Dropped InpL2AclDrop1433496091 4900M#show platform software drop-port | in Drop Event Reason|InpL2AclDrop|Time Time source is NTP, 16:36:07.020 NZST Sun Jun 29 2014 Drop Event ReasonPackets Dropped InpL2AclDrop1433539406 So far I haven't been able to find any additional details about this. I am guessing it is some kind of inbuilt L2 ACL. Cheers Ivan On 29/Jun/2014 2:33 p.m., Justin Krejci wrote: Is the layer 3 traffic multicast? Your indication of HA makes me suspect it is and perhaps you have a multicast snooping/filtering on the Cisco or some other related limiter setting. Just a total guess without any configs or other pertinent data. -Original Message- *From:* Ivan [cisco-...@itpro.co.nz] *Received:* Saturday, 28 Jun 2014, 5:10PM *To:* cisco-nsp [cisco-nsp@puck.nether.net] *Subject:* Re: [c-nsp] Cisco 4900M and Layer2 Broadcasts Sorry to respond to my own post but I have some further thoughts that may be useful. The traffic ends up being broadcast at layer 2 (dest MAC address ff:ff:ff:ff:ff:ff) but the IPv4 payload is generally unicast. So I am thinking perhaps the 4900M could be "getting upset" with these packets. Not really expecting the 4900M to look higher than layer 2 of these packets though as vlan does not have SVI. Ivan On 28/Jun/2014 10:17 p.m., Ivan wrote: I am hoping someone may have come across an issue I am seeing on a Cisco 4900M running 15.1(2)SG3. I have a device connected to an interface sending traffic from it's own MAC address to MAC address ff:ff:ff:ff:ff:ff. When the layer 3 protocol is IPv6 I see this going out other port in the same vlan as the source - all good. When the layer 3 protocol is IPv4 the frames seem to go into a black hole - very bad. I have confirmed all this with packet captures. I have poked around but cam find any indication of the issue. I will be logging a TAC case in the next day or two for this but would be interested to hear if anyone else has seen this. Thanks Ivan PS. Not really looking to get into the details of the connected devices etc - just some HA type traffic using layer 2 over a vlan. ___ 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] Cisco 4900M and Layer2 Broadcasts
Sorry to respond to my own post but I have some further thoughts that may be useful. The traffic ends up being broadcast at layer 2 (dest MAC address ff:ff:ff:ff:ff:ff) but the IPv4 payload is generally unicast. So I am thinking perhaps the 4900M could be "getting upset" with these packets. Not really expecting the 4900M to look higher than layer 2 of these packets though as vlan does not have SVI. Ivan On 28/Jun/2014 10:17 p.m., Ivan wrote: I am hoping someone may have come across an issue I am seeing on a Cisco 4900M running 15.1(2)SG3. I have a device connected to an interface sending traffic from it's own MAC address to MAC address ff:ff:ff:ff:ff:ff. When the layer 3 protocol is IPv6 I see this going out other port in the same vlan as the source - all good. When the layer 3 protocol is IPv4 the frames seem to go into a black hole - very bad. I have confirmed all this with packet captures. I have poked around but cam find any indication of the issue. I will be logging a TAC case in the next day or two for this but would be interested to hear if anyone else has seen this. Thanks Ivan PS. Not really looking to get into the details of the connected devices etc - just some HA type traffic using layer 2 over a vlan. ___ 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] Cisco 4900M and Layer2 Broadcasts
I am hoping someone may have come across an issue I am seeing on a Cisco 4900M running 15.1(2)SG3. I have a device connected to an interface sending traffic from it's own MAC address to MAC address ff:ff:ff:ff:ff:ff. When the layer 3 protocol is IPv6 I see this going out other port in the same vlan as the source - all good. When the layer 3 protocol is IPv4 the frames seem to go into a black hole - very bad. I have confirmed all this with packet captures. I have poked around but cam find any indication of the issue. I will be logging a TAC case in the next day or two for this but would be interested to hear if anyone else has seen this. Thanks Ivan PS. Not really looking to get into the details of the connected devices etc - just some HA type traffic using layer 2 over a vlan. ___ 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] Setting CS0 on ARP traffic
I ran into this same issue. In my case the carrier only took CS0 and CS6. No issues with ARP (CS6) but it turned out IPv6 neighbour discovery is marked CS7. I am still without a solution... On 29/May/2014 11:37 p.m., Ryan West wrote: First thing, that's a bad carrier. Second, they are already remarking, so why bother? If your 7609 was using a routing protocol, that would be CS6 as well. Personally, I would go the route of terminating services with that carrier, sounds like you'll be getting more surprises in the future. Sent from handheld. On May 29, 2014, at 7:27 AM, "Tony" wrote: Hi all, A new carrier that we are using requires that all traffic to them is marked as CS0. Any traffic that is non-CS0 is dropped on ingress by the carrier. We have connected the handoff from this carrier to a port on an ES20+ card in our 7609 (12.2.33.SRE9a). The first test service was refusing to work and upon inspection by the carrier (packet capture) it was shown that the ARP traffic from our box was marked as CS6. I then applied a QoS policy outbound on the sub-int we had terminated the service on to try and set all traffic to CS0, but the ARP traffic was still CS6. The carrier then applied a policy inbound on their gear (ie. from our 7609 towards them) to set everything to CS0 and the service started happily working. I then put a switch between our 7609 and the carrier so that I could SPAN the traffic and capture it via tcpdump. The results look like this: 17:04:53.446268 vlan 30, p 6, vlan 10, p 6, arp who-has 10.1.7.178 tell 10.1.7.177 So you can see on the outer VLAN 30, it is set to "p 6" and on the inner VLAN 10 it is also set to "p 6". The configuration of the interface on 7609 on our side looks like this (fairly standard): interface GigabitEthernet4/4.300010 encapsulation dot1Q 30 second-dot1q 10 ip vrf forwarding xyz ip address 10.1.7.177 255.255.255.252 I logged a case with TAC and they responded with: = We have tried this in our lab and this seem to be the default behavior. There is a restriction on ES+ card which states that control plane packets generated from the switch are sent to a special TX queue and these packets do not match the egress QOS policies configured. Please refer the link: http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap7.html#wp1540799 So this is the reason why you do not see any cos 0 packets on the other side even after applying a outbound service policy and see only cos 6 packets. I tried few other things but could not find a way around this restriction = I've asked them to go back and have another look to see if there is something else that can be done. I'm at a loss at this stage and appealing for any suggestions that people can think of, at this point in time it would appear that I have two options: 1. Terminate the services from this carrier on a different device that doesn't suffer from this problem. 2. Run the service through a switch (ie. 3750, like it is now) so that the switch can set the packets to CS0. Both of these are sub-optimal solutions, so obviously we'd like to find a way to set the outbound traffic from the ES20 card to CS0 so that it can work how we expected it to. Any suggestions appreciated. Thanks, Tony. ___ 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] Cisco ASR901 and Tunnels
Thanks Pete. Do you know if any of the other tunnelling modes are supported? ipipIP over IP encapsulation ipsec IPSec tunnel encapsulation ipv6Generic packet tunneling in IPv6 ipv6ip IPv6 over IP encapsulation Thanks Ivan > GRE is not supported on the ASR901. > > > On Mon, May 12, 2014 at 5:59 AM, Ivan wrote: > >> I have some Cisco ASR901s and would like to have a layer 2 or layer 3 >> tunnel between them over a layer 3 network. >> >> I have configured GRE and tunnel is up and it is possible to ping the >> remote ends. All looks good from the control plane side but I am not >> having success with traffic being forwarded. >> >> Although I have been able to configure this as far as I can tell there >> is >> nothing in the doco for this. I am thinking it maybe one of those "you >> can configure but not supported" things. >> >> Can anyone confirm if GRE tunnels or similar are actually supported? >> >> Hardware: ASR 901 >> Software: 15.4(1)S1 >> License Level: IPBase >> >> Thanks >> >> Ivan >> >> ___ >> 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] Cisco ASR901 and Tunnels
I have some Cisco ASR901s and would like to have a layer 2 or layer 3 tunnel between them over a layer 3 network. I have configured GRE and tunnel is up and it is possible to ping the remote ends. All looks good from the control plane side but I am not having success with traffic being forwarded. Although I have been able to configure this as far as I can tell there is nothing in the doco for this. I am thinking it maybe one of those "you can configure but not supported" things. Can anyone confirm if GRE tunnels or similar are actually supported? Hardware: ASR 901 Software: 15.4(1)S1 License Level: IPBase Thanks Ivan ___ 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] ECMP v Link Aggregation ofr MPLS
Thanks to all have responded so far. Adam, what features were not available for you when using LAG and what platform are you using? Cheers Ivan > As mentioned just make sure LAG on your platforms will allow you to use > all the features you require on your backbone. > That's why we had to go the ECMP way -the drawback is more IGP routes. > > adam >> -Original Message- >> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of >> Keegan Holley >> Sent: Friday, March 14, 2014 12:29 AM >> To: Ivan >> Cc: cisco-nsp@puck.nether.net >> Subject: Re: [c-nsp] ECMP v Link Aggregation ofr MPLS >> >> It depends on your platform, traffic and code versions. Aggregated >> links and >> MLAG are the better option since they are simpler. However they are >> more >> susceptible to bugs on certain platforms and traffic spread of course >> depends >> what kind of traffic flows will traversing the links. It's also easier >> to remove >> links from service with ECMP. If you're a transit AS you probably have >> enough diversity to ensure an even spread. All things considered I'd >> choose >> aggregated links as well. >> >> On Mar 13, 2014, at 4:28 PM, Ivan wrote: >> >> > So we are crossing the bridge to >10Gbps for some MPLS core links. I >> > am trying to work out if it is better to use aggregated links or ECMP. >> > If anyone has any experience or recommendation it would be much >> appreciated. >> > >> > Thanks >> > >> > Ivan >> > >> > ___ >> > 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/
[c-nsp] ECMP v Link Aggregation ofr MPLS
So we are crossing the bridge to >10Gbps for some MPLS core links. I am trying to work out if it is better to use aggregated links or ECMP. If anyone has any experience or recommendation it would be much appreciated. Thanks Ivan ___ 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] DC Powered Switch
I am after a basic switch but it need to be DC powered. Something like a 2960 would be more than good enough. Would the lowest cost Cisco option be the ME-3400E-24TS-M with DC supplies? Requirements are layer 2, ~24 ports and dc power. I did get a quote for one of these and the first DC power supply was listed as ME34X-PWR-DC and the second as ME34X-PWR-DC-R, but the second one costs 3 x as much - is there something special about the second PS in this model? Thanks Ivan ___ 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] ME3600X - Hairpinning/Local Connect
Just what I was after - "EVC Local Connect". Looks like i needed a newer IOS - 15.3(2)S. Thanks to those who replied. http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-3_2_S/configuration/guide/3800x3600xscg/swevc.html#wp1079580 Ivan On 20/Feb/2014 7:59 p.m., George Giannousopoulos wrote: Hi, This feature is supported in 15.3(2)S and newer images. Check http://www.cisco.com/c/en/us/td/docs/ios/15_3s/release/notes/15_3s_rel_notes/15_3s_feats_important_notes_15_3_2s.html I've tested it successfully in 15.3(3)S1a Best regards George On Thu, Feb 20, 2014 at 4:45 AM, Ivan <mailto:cisco-...@itpro.co.nz>> wrote: Hi, I have seen in the config guides at way of send traffic in and out the same port or even different ports http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-3_1_S/configuration/guide/3800x3600xscg/swevc.html#wp1051612 I was looking to use the connect statement which seems to be there but maybe not supported?? Here is what I was trying interface GigabitEthernet0/5 description Local Connect Test switchport trunk allowed vlan none switchport mode trunk mtu 9216 load-interval 30 no cdp enable spanning-tree portfast spanning-tree bpdufilter enable spanning-tree bpduguard enable service instance 123 ethernet encapsulation dot1q 123 no rewrite ingress tag pop 1 symmetric no shut interface GigabitEthernet0/6 description Local Connect Test switchport trunk allowed vlan none switchport mode trunk mtu 9216 load-interval 30 no cdp enable spanning-tree portfast spanning-tree bpdufilter enable spanning-tree bpduguard enable service instance 123 ethernet encapsulation dot1q 123 no rewrite ingress tag pop 1 symmetric no shut ME1(config)#connect test gigabitEthernet 0/5 123 gigabitEthernet 0/6 123 %CONN: invalid segment 1 %CONN: Invalid Command ME1(config)# IOS is me360x-universalk9-mz.153-1.S1.bin. Have I done something wrong or is this not supported? Thanks Ivan ___ cisco-nsp mailing list cisco-nsp@puck.nether.net <mailto: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] ME3600X - Hairpinning/Local Connect
Hi, I have seen in the config guides at way of send traffic in and out the same port or even different ports http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-3_1_S/configuration/guide/3800x3600xscg/swevc.html#wp1051612 I was looking to use the connect statement which seems to be there but maybe not supported?? Here is what I was trying interface GigabitEthernet0/5 description Local Connect Test switchport trunk allowed vlan none switchport mode trunk mtu 9216 load-interval 30 no cdp enable spanning-tree portfast spanning-tree bpdufilter enable spanning-tree bpduguard enable service instance 123 ethernet encapsulation dot1q 123 no rewrite ingress tag pop 1 symmetric no shut interface GigabitEthernet0/6 description Local Connect Test switchport trunk allowed vlan none switchport mode trunk mtu 9216 load-interval 30 no cdp enable spanning-tree portfast spanning-tree bpdufilter enable spanning-tree bpduguard enable service instance 123 ethernet encapsulation dot1q 123 no rewrite ingress tag pop 1 symmetric no shut ME1(config)#connect test gigabitEthernet 0/5 123 gigabitEthernet 0/6 123 %CONN: invalid segment 1 %CONN: Invalid Command ME1(config)# IOS is me360x-universalk9-mz.153-1.S1.bin. Have I done something wrong or is this not supported? Thanks Ivan ___ 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] IOS XR BGP Filters
Hi, I am adding some routers running ISO XR to my network. For the most part things are straight forward and I quite like RPL. In IOS BGP I would apply per neighbor BGP as-path and prefix filters and a global route-map, something like neighbor x.x.x.x filter-list x in neighbor x.x.x.x prefix-list cust-a in neighbor x.x.x.x route-map all-custs in Now with IOS XR it seems the only filtering that can be applied is a single route-policy. So I am thinking that I will be needing a parent rpl policy per neighbour for the as-path and prefix filtering (as these differ per neighbor) and a common child policy for everything else... am I on the right track? Cheers Ivan ___ 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] SFP-10G-ZR and C3KX-NM-10G
Hi, Can anyone confirm if SFP-10G-ZR works in C3KX-NM-10G for 3560X or 3750X. Doesn't seem to be on the list Thanks Ivan ___ 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] Advanced Metro license, ME-3600
ｃould be... Switch(config)#license boot level ? AdvancedMetroIPAccess AdvancedMetroIPAccess level MetroIPAccess MetroIPAccess level Ivan On 28/Sep/2012 11:30 a.m., Eric A Louie wrote: Thanks for the help. That didn't work. I opened a case with TAC to get the secret formula, because all my searches for "activate evaluation license advanced metro" gave me no configuration hints. Much appreciated, Eric Louie 619-743-5375 From: Reuben Farrelly To: Eric A Louie Cc: Aaron ; Mattias Gyllenvarg ; cisco-nsp@puck.nether.net Sent: Thu, September 27, 2012 3:34:47 PM Subject: Re: [c-nsp] Advanced Metro license, ME-3600 The Eval license does not require a license be obtained from CCO. Only permanent non-expiring licenses require the special file/key. sw6.nsw(config)#license boot level advancedMetroIPAccess Pretty sure this is all you need to activate the 60 day eval. Unfortunately I don't have any ME3600s around that don't have the ADV license to test with. This is the exact same process as other newer Catalyst switches, FWIW. It's not unique to this platform. Reuben On 28/09/2012 8:23 AM, Eric A Louie wrote: I don't see an eval license for "ME 3600X Advanced Metro" under Routers & Switches Much appreciated, Eric Louie 619-743-5375 *From:* Reuben Farrelly *To:* Aaron *Cc:* Mattias Gyllenvarg ; Eric A Louie ; cisco-nsp@puck.nether.net *Sent:* Thu, September 27, 2012 2:56:05 PM *Subject:* Re: [c-nsp] Advanced Metro license, ME-3600 If you get an E-License Delivery instead of the license coming preinstalled on the switch, the process is still actually very straightforward. All you have to do is fill in a short form online and enter a key from the E-License PDF, the actual license file itself then gets emailed back to you straight away, and it's just then a case of uploading the file to the switch. http://www.cisco.com/go/license/ I'm not a big fan of complexity, but this process really is as easy (or complex) as downloading an IOS image from CCO. If the E-license doesn't turn up with the hardware there's always the 60 day Eval License which you can activate without any keys to buy more time. Reuben On 28/09/2012 5:22 AM, Aaron wrote: > I get some with and some without... the ones without I send system serial > number to my cisco account se and she sends me a license file > > Aaron > > > -Original Message- > From: cisco-nsp-boun...@puck.nether.net <mailto:cisco-nsp-boun...@puck.nether.net> > [mailto:cisco-nsp-boun...@puck.nether.net <mailto:cisco-nsp-boun...@puck.nether.net>] On Behalf Of Mattias Gyllenvarg > Sent: Thursday, September 27, 2012 1:40 AM > To: Eric A Louie > Cc: cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net> > Subject: Re: [c-nsp] Advanced Metro license, ME-3600 > > Have had both ways. Always get them preinstalled now. > > Licencing process is a pain. > > On 27 September 2012 00:35, Eric A Louie mailto:elo...@yahoo.com>> wrote: > >> Hey folks, I'm trying to get the straight scoop on the licensing issue >> >> I received an ME 3600x from my reseller, without the Advanced Metro >> license. I did order the license from them. Is there a normal wait >> for getting it, or is the reseller trying to smokescreen me? Or, >> should I have received the license on shipment of the switch? >> >> Much appreciated, >> Eric Louie ___ 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] ME3600X Local Connect
I am running Switch#show license Index 1 Feature: AdvancedMetroIPAccess Period left: Life time License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: Medium Index 2 Feature: MetroIPAccess Index 3 Feature: 10GEUpgrade Period left: Life time License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: Medium What do you get after putting in a name for the connect - all I get is Dialer as an option. Switch(config)#connect FOO ? Dialer Dialer interface On 28/Sep/2012 12:22 a.m., Andrew K. wrote: Are you running the advanced services license? me360x-universalk9-mz.152-2.S1.bin switch#sh license Index 1 Feature: AdvancedMetroIPAccess Period left: Life time switch(config)#connect ? WORD Name for this connection On 9/27/2012 6:38 AM, Nick Hilliard wrote: On 27/09/2012 03:38, Ivan wrote: Just connecting 2 service instances is all I would like to do. There is a difference between an ESI and an xconnect. In the case of an ESI, the switch will learn all the mac addresses passing over the link. This doesn't happen for an xconnect. If you're dealing with a small number of mac addresses, this probably isn't a problem. If you're dealing with a lot, then it may be... 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/ ___ 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] ME3600X Local Connect
Hi Not sure what ESI stands for, but the main reason I don't want to do bridge mode is to avoid the MAC learning. Also better not to use up the bridges which are a global resource. Ivan On 27/Sep/2012 10:38 p.m., Nick Hilliard wrote: On 27/09/2012 03:38, Ivan wrote: Just connecting 2 service instances is all I would like to do. There is a difference between an ESI and an xconnect. In the case of an ESI, the switch will learn all the mac addresses passing over the link. This doesn't happen for an xconnect. If you're dealing with a small number of mac addresses, this probably isn't a problem. If you're dealing with a lot, then it may be... 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] ME3600X Local Connect
Just connecting 2 service instances is all I would like to do. What IOS are you running. I am unable to you the connect command. I am using me360x-universalk9-mz.152-4.S interface GigabitEthernet0/11 switchport trunk allowed vlan none switchport mode trunk service instance 1 ethernet encapsulation dot1q 10 rewrite ingress tag pop 1 symmetric interface GigabitEthernet0/12 switchport trunk allowed vlan none switchport mode trunk service instance 1 ethernet encapsulation dot1q 20 rewrite ingress tag pop 1 symmetric Switch(config)#connect FOO ? Dialer Dialer interface > Connect does exist but you can't use it with a bridge domain. > > The connect command is only used for two service instances. If you need > to link three or more that traffic must be switched, so then just use a > bridge-group. > > Connect example > > Switch (config)# interface gigabitethernet0/2 > Switch (config-if)# service instance 1 Ethernet > Switch (config-if-srv)# encapsulation dot1q 10,20,30-50 > Switch (config-if-srv)# exit > > Switch (config)# interface gigabitethernet0/3 > Switch (config-if)# service instance 1 Ethernet > Switch (config-if-srv)# encapsulation dot1q 10,20,30-50 > > > Switch (config)#connect NAMEHERE GigabitEthernet0/2 1 GigabitEthernet0/3 1 > > > > On 9/26/2012 8:38 PM, Ivan wrote: >> Hi, >> >> Does anyone know if it is possible to configure local connect on the >> ME3600X? The closest I have found is "hairpinning" >> http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.2_4_S/configuration/guide/swevc.html#wp1051612 >> >> This uses bridge domains and seems to have some limitations... >> >> Switch(config-if-srv)#bridge-domain ? >><1-8000> Bridge-domain number >> >> Switch(config-if-srv)#bridge-domain 8000 >> QOS: Bridge-Domain greater than 4095 is not supported for output >> policies >> QoS: Detaching output service-policy TEST from efp 60 >> >> Something like on the 7600 ( " connect GigabitEthernet3/3 55 >> GigabitEthernet3/3 66" would be nice. >> >> Ivan >> >> >> >> ___ >> 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] Advanced Metro license, ME-3600
Hi, My experience is that any ME3600Xs ordered with licences have come with the license pre installed. Ivan > Hey folks, I'm trying to get the straight scoop on the licensing issue > > I received an ME 3600x from my reseller, without the Advanced Metro > license. I > did order the license from them. Is there a normal wait for getting it, > or is > the reseller trying to smokescreen me? Or, should I have received the > license > on shipment of the switch? > > Much appreciated, > Eric Louie > ___ > 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] ME3600X Local Connect
Hi, Does anyone know if it is possible to configure local connect on the ME3600X? The closest I have found is "hairpinning" http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.2_4_S/configuration/guide/swevc.html#wp1051612 This uses bride domains and seems to have some limitations... Switch(config-if-srv)#bridge-domain ? <1-8000> Bridge-domain number Switch(config-if-srv)#bridge-domain 8000 QOS: Bridge-Domain greater than 4095 is not supported for output policies QoS: Detaching output service-policy TEST from efp 60 Something like on the 7600 ( " connect GigabitEthernet3/3 55 GigabitEthernet3/3 66" would be nice. Ivan ___ 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] QoS and Router Originated Traffic
Hi, I have had a lot of similar feedback. I have found * Changing the IP precedence via ""ip local policy route-map" doesn't directly set the COS - the locally generated traffic doesn't have a 802.1q header to contain the 802.1p bits. Depending on the platform (and probably other stuff) the IP precedence value may or may not end copied into the 802.1p field when the exiting interface has 802.1q tagged packets. *Testing on ASR1K and 800 Series ISRs I have found that they don't copy the IP precedence into the 802.1p field. A 7600 with ES+ does. *IPv6 NS and ND packets are marked with IP precedence 7. On the 7600 the "ip local policy route-map" doesn't work for these packets - it does work for other IPv6 packets . *The "ip local policy route-map" solution impacts RP traffic going out all interfaces. I only require a specific interface to have traffic marked in a certain way. *I would prefer to only modify the 802.1p bits while leaving the IP precedence. At this stage I am thinking the only way to achieve what I am looking for is to set only the 802.1p bits using an additional device... Ivan > Hi, > > We use "ip local policy route-map xyz" to apply a route-map to traffic > that is originated locally on the router. The route-map is like any normal > one with a match statement (using ACL), then a set statement. > > > regards, > Tony. > > > >> >> From: Anton Kapela >>To: Ivan >>Cc: cisco-nsp >>Sent: Tuesday, 25 September 2012 10:07 PM >>Subject: Re: [c-nsp] QoS and Router Originated Traffic >> >>Kind of out-dated, but useful reading: >> >>http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094612.shtml >> >>-Tk >> >>On Sep 17, 2012, at 5:21 AM, Ivan wrote: >> >>> Hi, >>> >>> I have a requirement to ensure all traffic across certain links have >>> particular CoS markings. Applying QoS polices on the links works but >>> doesn't capture router originated traffic - BGP, ARP, IPv6 ND etc. >>> >>> As a potential solution I have tested using IPv4 and IPv6 PBR to force >>> router traffic via lo0 >>> >>> route-map LP permit 10 >>> set interface Loopback0 >>> >>> ip local policy route-map LP >>> ipv6 local policy route-map LP >>> >>> and have set a QoS policy on lo0 >>> >>> interface Loopback0 >>> service-policy input LOOP0-IN >>> >>> this sets a qos-group which is matched the outgoing non-loopback >>> interface and sets CoS as required. >>> >>> As far as I can tell it works pretty well but I have a few questions >>> >>> 1) I don't think this works for ARP. I tried to match protocol arp >>> using the loopback0 policy but >>> >>> router(config-if)#service-policy input LOOP0-IN >>> 'match protocol arp' is not supported on input service-policy >>> >>> is there anyway to set the CoS value for ARP traffic from the router, >>> ideally only on some interfaces? >>> >>> 2) Is this configuration going to kill my router - maybe I am forcing >>> some process switching? >>> >>> Thanks >>> >>> Ivan >> ___ 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] ME3600 switch interface showing Packet drops on Trunk Port.
Hi Muthu, As per that thread the default buffer size for the Gi interfaces is very small and can be increased with a QoS policy as Warris described. I was seeing "Total output drops" increasing in the output of "show int gi0/x" AT a quick glance I can't see this information in the output you provided below, so you may have a different issue. Ivan On 21/Sep/2012 8:32 p.m., Muthukumar Rajagopalan wrote: Thanks Ivan for sharing the Thread, I just glanced the thread quickly, in our setup, there is no QOS applied as of now. The interface is a 1 Gig interface only and here is the show controller output. show controllers ethernet-controller gigabitEthernet 0/1 Transmit GigabitEthernet0/1 Receive 3746715079 Bytes 684001607 Bytes 1601240611 Unicast frames 1423901907 Unicast frames 3956660 Multicast frames 57515 Multicast frames 33950 Broadcast frames 111825 Broadcast frames 1603960779 Dot1Q frames 1424071247 Dot1Q frames 0 Too old frames 668768496 Unicast bytes *3690121444 Deferred frames 5900758 Multicast bytes* 0 MTU exceeded frames 9332353 Broadcast bytes 0 FCS errors 0 FCS errors 0 1 collision frames 0 Alignment errors 0 2 collision frames 0 3 collision frames 0 Oversize frames 0 4 collision frames 0 Undersize frames 0 5 collision frames 0 Collision fragments 0 6 collision frames * 0 7 collision frames 2134412 Minimum size frames 0 8 collision frames 33319889 65 to 127 byte frames 0 9 collision frames 13344585 128 to 255 byte frames 0 10 collision frames 4930119 256 to 511 byte frames 0 11 collision frames 2813946 512 to 1023 byte frames 0 12 collision frames 803808161 1024 to 1518 byte frames* 0 13 collision frames 0 Overrun frames 0 14 collision frames 0 15 collision frames 0 Pause frames 0 Pause frames 0 Excessive collisions 0 Symbol error frames 0 Late collisions 0 Invalid frames, too large 0 VLAN discard frames 563720136 Valid frames, too large 0 Excess defer frames 0 Invalid frames, too small 2310138 64 byte frames 0 Valid frames, too small 39205786 127 byte frames 14671469 255 byte frames 0 Too old frames 6687328 511 byte frames 0 Valid oversize frames 69655856 1023 byte frames 0 System FCS error frames 951464626 1518 byte frames 521236018 Too large frames 0 Good (1 coll) frames 0 Good (>1 coll) frames Thanks, Muthu. On Fri, Sep 21, 2012 at 12:07 PM, Muthukumar Rajagopalan wrote: Hi.. We have implemented ME3600 switch recently and observing random packet drops on the trunk link. On the access side, we have multi-services running, Normal Server Data traffic, Video + Voice. Below is the config on the trunk port and Q-in-Q enabled on the access. Different Pattern of traffic has been sent and observing outbound drops max up to 3%. *Present Version:* me360x-universalk9-mz.122-52.EY4.bin port-type nni switchport mode trunk mtu 1512 load-interval 30 speed nonegotiate spanning-tree bpdufilter enable spanning-tree bpduguard enable spanning-tree guard root ethernet cfm mip level 7 vlan 1-4094 ethernet oam remote-loopback supported ethernet oam hold-queue 4096 in hold-queue 4096 out Please provide your view if you folks came across this kind of issue before. Thanks, Muthu.. ___ 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] QoS and Router Originated Traffic
Hi, I have a requirement to ensure all traffic across certain links have particular CoS markings. Applying QoS polices on the links works but doesn't capture router originated traffic - BGP, ARP, IPv6 ND etc. As a potential solution I have tested using IPv4 and IPv6 PBR to force router traffic via lo0 route-map LP permit 10 set interface Loopback0 ip local policy route-map LP ipv6 local policy route-map LP and have set a QoS policy on lo0 interface Loopback0 service-policy input LOOP0-IN this sets a qos-group which is matched the outgoing non-loopback interface and sets CoS as required. As far as I can tell it works pretty well but I have a few questions 1) I don't think this works for ARP. I tried to match protocol arp using the loopback0 policy but router(config-if)#service-policy input LOOP0-IN 'match protocol arp' is not supported on input service-policy is there anyway to set the CoS value for ARP traffic from the router, ideally only on some interfaces? 2) Is this configuration going to kill my router - maybe I am forcing some process switching? Thanks Ivan ___ 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] ME3600X Output Drops
Hi Warris, Running me360x-universalk9-mz.152-2.S1.bin Thanks Ivan On 16/Sep/2012 12:20 a.m., Waris Sagheer (waris) wrote: Hi Ivan, The policy should work on EFP regardless of bridge or xconnect. Which image are you using? Regards, Waris -Original Message- From: Ivan [mailto:cisco-...@itpro.co.nz] Sent: Wednesday, September 12, 2012 7:30 PM To: Waris Sagheer (waris) Cc: Ivan; cisco-nsp Subject: RE: [c-nsp] ME3600X Output Drops Hi Warris, Thanks again for your answers. The requirement to match at vlan level is because I understood from your examples to apply a policy at the EVC level this was required "<<<<< Using vlan level confirms it is the second level and the child policy is the third level" I have found that a policy such as the following seems to work and handle both tagged and untagged traffic and can be applied to a EVC. (I wish to apply the same policy to all EVCs regardless of whether the traffic is tagged or not unless customisation is required) class-map match-any vlan match vlan 1-4094 policy-map EVC-LEAF class class-default queue-limit 491520 bytes policy-map EVC-VLAN class vlan service-policy EVC-LEAF class class-default service-policy EVC-LEAF Separate to this, and partly why I was confused, is that I have found the polices applied to the EVC seem to work when bridging but not for a xconnect. Can you confirm this is expected behavior? I would prefer to avoid having to bridge and xconnect on the vlan interface. interface GigabitEthernet0/5 switchport trunk allowed vlan none switchport mode trunk service instance 60 ethernet encapsulation dot1q 60 service-policy output EVC-VLAN bridge-domain 60 <--- bridged service instance 70 ethernet encapsulation dot1q 70 service-policy output EVC-VLAN xconnect 1.2.3.4 70 encapsulation mpls <--- xconnect Switch#show policy-map interface gi0/5 service instance 60 GigabitEthernet0/5: EFP 60 Service-policy output: EVC-VLAN Class-map: vlan (match-any) 0 packets, 0 bytes 5 minute offered rate bps Match: vlan 1-4094 Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Queue-limit 491520 bytes Queue-limit current-queue-depth 0 bytes Output Queue: Tail Packets Drop: 0 Tail Bytes Drop: 0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Queue-limit 491520 bytes <queue-limit Queue-limit current-queue-depth 0 bytes Output Queue: Tail Packets Drop: 0 Tail Bytes Drop: 0 Switch#show policy-map interface gi0/5 service instance 70 GigabitEthernet0/5: EFP 70 Service-policy output: EVC-VLAN Class-map: vlan (match-any) 0 packets, 0 bytes 5 minute offered rate bps Match: vlan 1-4094 Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate 0000 bps Match: any Hi Ivan, There is no difference in terms of queue depth in case of policy at the port level vs policy at the EVC from hardware programming perspective.. Port level policy would consume less queues as compare to queues per EVC. Policy at EVC has separate queues per service instance. However policy at the port level, queues are shared by the all the service instances under that port. Selection of the policy depends on the requirement. If there are separate customers on the EVC then per EVC policy should be used. For you last question, shouldn't untagged means no tag then why is there a requirement to match on the VLAN level? What kind of traffic is there in case of "default"? Is it tagged or untagged? If tagged, is there a range? Regards, Waris ___ 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] ME3600X Output Drops
Hi Warris, Thanks again for your answers. The requirement to match at vlan level is because I understood from your examples to apply a policy at the EVC level this was required "<<<<< Using vlan level confirms it is the second level and the child policy is the third level" I have found that a policy such as the following seems to work and handle both tagged and untagged traffic and can be applied to a EVC. (I wish to apply the same policy to all EVCs regardless of whether the traffic is tagged or not unless customisation is required) class-map match-any vlan match vlan 1-4094 policy-map EVC-LEAF class class-default queue-limit 491520 bytes policy-map EVC-VLAN class vlan service-policy EVC-LEAF class class-default service-policy EVC-LEAF Separate to this, and partly why I was confused, is that I have found the polices applied to the EVC seem to work when bridging but not for a xconnect. Can you confirm this is expected behavior? I would prefer to avoid having to bridge and xconnect on the vlan interface. interface GigabitEthernet0/5 switchport trunk allowed vlan none switchport mode trunk service instance 60 ethernet encapsulation dot1q 60 service-policy output EVC-VLAN bridge-domain 60 <--- bridged service instance 70 ethernet encapsulation dot1q 70 service-policy output EVC-VLAN xconnect 1.2.3.4 70 encapsulation mpls <--- xconnect Switch#show policy-map interface gi0/5 service instance 60 GigabitEthernet0/5: EFP 60 Service-policy output: EVC-VLAN Class-map: vlan (match-any) 0 packets, 0 bytes 5 minute offered rate bps Match: vlan 1-4094 Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Queue-limit 491520 bytes Queue-limit current-queue-depth 0 bytes Output Queue: Tail Packets Drop: 0 Tail Bytes Drop: 0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Queue-limit 491520 bytes <queue-limit Queue-limit current-queue-depth 0 bytes Output Queue: Tail Packets Drop: 0 Tail Bytes Drop: 0 Switch#show policy-map interface gi0/5 service instance 70 GigabitEthernet0/5: EFP 70 Service-policy output: EVC-VLAN Class-map: vlan (match-any) 0 packets, 0 bytes 5 minute offered rate bps Match: vlan 1-4094 Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate bps Match: any Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate bps, drop rate 0000 bps Match: any > Hi Ivan, > There is no difference in terms of queue depth in case of policy at the > port level vs policy at the EVC from hardware programming perspective. > Port level policy would consume less queues as compare to queues per EVC. > Policy at EVC has separate queues per service instance. However policy at > the port level, queues are shared by the all the service instances under > that port. > Selection of the policy depends on the requirement. If there are separate > customers on the EVC then per EVC policy should be used. > For you last question, shouldn't untagged means no tag then why is there a > requirement to match on the VLAN level? What kind of traffic is there in > case of "default"? Is it tagged or untagged? > If tagged, is there a range? > > Regards, > Waris > > ___ 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] ME3600X Output Drops
Hi Waris, Thanks very much for the detailed email. It really helps to get information on default queue-sizes and improvements on the road-map. I was wondering if when using many EVCs on a physical interface, is there any difference between applying a policy on the physical port vs individual policies on each EVC (in terms of queue-limit and buffers). That is if you apply the policy per EVC will each EVC have separate QoS resources (such as buffer space)? I am trying to work out if it is better to apply polices to the port or the service instance. Lastly is there any way to match at the "vlan level" when the EVC is matching untagged or default traffic? I have tried but haven't been able to get a successful config for this. Thanks Ivan On 27/Aug/2012 4:34 p.m., Waris Sagheer (waris) wrote: Problem Statement: When there is a speed mismatch that is 10 Gig ingress interface/1Gig egress interface or 1 Gig ingress interface/100M egress interface, microbursts can happen. For example, 10 Gig Ingress interface->1 Gig Egress Interface Traffic rate 500 M, traffic direction 10 Gig to 1 Gig interface. Instantaneous burst is possible which can cause the default queue buffers to run out at egress interface resulting in packet drops at the 1 Gig egress interface.. ME3800X/ME3600X/ME3600X-24CX default queue-limit values in time and bytes for 10/100/1000/1 Mbps Interfaces: In Bytes: 10/100/1000/1 Mbps --> 12/12/12/120 Kbytes respectively In Time: 10/100/1000/1 Mbps --> 1/1000/100/100 usec respectively How to fix this problem? Current Solution: Increase the queue-limit by using the "queue-limit xx" command. Queue-Limit Ranges: 200 to 491520 bytes 1 to 3932 us 1 to 2457 packets (Assuming 1 packet = 200 bytes) [Packet unit is supported in 15.1(2)EY] How to pick the right value? Currently there is no other way except for trial and error. It is best to start from 200K Bytes and monitor the drops. Increase the queue-limit if the drops are still seen. Roadmap Queue-limit Feature Enhancements to fix this issue: Step 1:We are planning to increase the default queue-limit to 40KB increase of 12 KB in case of 1Gig interface. Step 2:We are planning to introduce a feature called flexible queue-limit in Release 15.3(1)S, Q4CY12 which would allow the queue-limit to be increases as percentages of buffer. Similar feature is supported on ME3400E. http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_58_ex/command/reference/cli1.html#wp5095786 Step 3:To pick the right value, watermark counter will be introduced in 2HCY13 which will record the maximum tail drop value. This will enable the customers to tweak their queue-limit value accordingly. The feature is currently available in IOS XR. Queue-limit Value Configuration: 12.xx Release Output Example of user configurable queue limit value, Switch(config-pmap-c)#queue-limit ? <1-491520> <200-491520> in bytes, <1-3932> in us, maximum threshold (in us by default) 15.xx Outputs There is an issue with the command help which shows higher value than supported by the platform, it will be fixed in the future release. ME3800X-H-1(config-pmap-c)#queue-limit ? <1-8192000>in bytes, <1-3400> in ms, <1-8192000> in packets by default << Range is shown higher than the platform can support ME3800X-H-1(config-pmap-c)#queue-limit 8192000 bytes QOS: Qlimit threshold value is out of range Min and Max bytes qlimit are 200 & 491520 <<< Valid supported range queue-limit: platform params check fail ME3800X-H-1(config-pmap-c)#queue-limit 2500 packets QOS: Qlimit threshold value is out of range Min and Max packets qlimit are 1 & 2457 << Valid supported range queue-limit: platform params check fail Queue-Limit Policy Configuration Example: In many cases QoS policy will only be required to help with the issue of packet drops. ME platforms support three level hiearchy [Port, Vlan & Class] and Queue-limit is only supported at the class or third level. Valid supported Queue-limit Policy Example: class-map match-all vlan60 match vlan 60 ! policy-map EFP-qlimit class vlan60 <<<<< Using vlan level confirms it is the second level and the child policy is the third level shape average 1 service-policy COS-OUT-L3-NSP ! policy-map COS-OUT-L3-NSP class class-default queue-limit 256 packets interface GigabitEthernet0/5 switchport trunk allowed vlan none switchport mode trunk service instance 2 ethernet encapsulation dot1q 60 rewrite ingress tag pop 1 symmetric service-policy output EFP-qlimit bridge-domain 60 Three Level Class-default Policy Example: policy-map leaf class class-default queue-limit x bytes policy-map logical class class-default service-policy leaf policy-map root class class-default service-policy logic
Re: [c-nsp] ME3600X Output Drops
Thanks George. I am raising a SR to get some more information too. Are
you able to explain how the queue-limit of 2457 was selected? Also were
you given a version for the increase in the default queue size? I am
running me360x-universalk9-mz.152-2.S1.bin
Cheers
Ivan
On 23/Aug/2012 5:48 p.m., George Giannousopoulos wrote:
Hi Ivan,
In fact the default queue limit in 3800x/3600x is quite small
We also had issues with drops in all interfaces, even without congestion
After some research and an SR with Cisco, we have started applying qos
on all interfaces
policy-map INTERFACE-OUTPUT-POLICY
class dummy
class class-default
shape average X
queue-limit 2457 packets
The dummy class does nothing.
It is just there because IOS wouldn't allow changing queue limit otherwise
Also there were issues with the policy counters which should be resolved
after15.1(2)EY2
Cisco said they would increase the default queue sizes in the second half of
2012..
So, I suggest you try the latest IOS version and check again
10G interfaces had no drops in our setup too.
Regards
George
On Thu, Aug 23, 2012 at 1:34 AM, Ivan <mailto:cisco-...@itpro.co.nz>> wrote:
Replying to my own message
* Adjusting the hold queue didn't help.
* Applying QOS and per referenced email stopped the drops
immediately - I
used something like the below:
policy-map leaf
class class-default
queue-limit 491520 bytes
policy-map logical
class class-default
service-policy leaf
policy-map root
class class-default
service-policy logical
* I would be interested to hear if others have ended up applying a
similar
policy to all interfaces. Any gotchas? I expect any 10Gbps
interfaces
would be okay without the QoS - haven't seen any issue on these
myself.
*Apart from this list I have found very little information around this
whole issue. Any pointers to other documentation would be
appreciated.
Thanks
Ivan
Ivan
> Hi,
>
> I am seeing output drops on a ME3600X interface as shown below
>
> GigabitEthernet0/2 is up, line protocol is up (connected)
> MTU 9216 bytes, BW 100 Kbit/sec, DLY 10 usec,
> reliability 255/255, txload 29/255, rxload 2/255
> Encapsulation ARPA, loopback not set
> Keepalive set (10 sec)
> Full-duplex, 1000Mb/s, media type is RJ45
> input flow-control is off, output flow-control is unsupported
> ARP type: ARPA, ARP Timeout 04:00:00
> Last input 6w1d, output never, output hang never
> Last clearing of "show interface" counters 00:12:56
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output
drops: 231
> Queueing strategy: fifo
> Output queue: 0/40 (size/max)
> 30 second input rate 10299000 bits/sec, 5463 packets/sec
> 30 second output rate 114235000 bits/sec, 12461 packets/sec
> 3812300 packets input, 705758638 bytes, 0 no buffer
> Received 776 broadcasts (776 multicasts)
> 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> 0 watchdog, 776 multicast, 0 pause input
> 0 input packets with dribble condition detected
> 9103882 packets output, 10291542297 bytes, 0 underruns
> 0 output errors, 0 collisions, 0 interface resets
> 0 unknown protocol drops
> 0 babbles, 0 late collision, 0 deferred
> 0 lost carrier, 0 no carrier, 0 pause output
> 0 output buffer failures, 0 output buffers swapped out
>
> I have read about similar issues on the list:
> http://www.gossamer-threads.com/lists/cisco/nsp/157217
> https://puck.nether.net/pipermail/cisco-nsp/2012-July/085889.html
>
> 1. I have no QoS policies applied to the physical interface or EVCs.
> Would increasing the hold queue help? Is there a recommended
value - the
> maximum configurable is 24. What is the impact on the 44MB
of packet
> buffer.
>
> 2. If the hold queue isn't an option is configuring QoS required to
> increase the queue-limit from the default 100us. Again are
there any
> recommended values and what impact is there on the available 44MB of
> packet buffer.
>
> 3. I have found that when applying policies to the EVCs the
"show policy
> map" output does not have information for the queue-limit as I
have seen
> when applying polices to the physical interface. Does this mean
that EVCs
> will still suffer from output drops?
>
> Thanks
>
> Ivan
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
<mai
Re: [c-nsp] ME3600X Output Drops
Replying to my own message * Adjusting the hold queue didn't help. * Applying QOS and per referenced email stopped the drops immediately - I used something like the below: policy-map leaf class class-default queue-limit 491520 bytes policy-map logical class class-default service-policy leaf policy-map root class class-default service-policy logical * I would be interested to hear if others have ended up applying a similar policy to all interfaces. Any gotchas? I expect any 10Gbps interfaces would be okay without the QoS - haven't seen any issue on these myself. *Apart from this list I have found very little information around this whole issue. Any pointers to other documentation would be appreciated. Thanks Ivan Ivan > Hi, > > I am seeing output drops on a ME3600X interface as shown below > > GigabitEthernet0/2 is up, line protocol is up (connected) > MTU 9216 bytes, BW 100 Kbit/sec, DLY 10 usec, > reliability 255/255, txload 29/255, rxload 2/255 > Encapsulation ARPA, loopback not set > Keepalive set (10 sec) > Full-duplex, 1000Mb/s, media type is RJ45 > input flow-control is off, output flow-control is unsupported > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 6w1d, output never, output hang never > Last clearing of "show interface" counters 00:12:56 > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 231 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > 30 second input rate 10299000 bits/sec, 5463 packets/sec > 30 second output rate 114235000 bits/sec, 12461 packets/sec > 3812300 packets input, 705758638 bytes, 0 no buffer > Received 776 broadcasts (776 multicasts) > 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 0 watchdog, 776 multicast, 0 pause input > 0 input packets with dribble condition detected > 9103882 packets output, 10291542297 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 unknown protocol drops > 0 babbles, 0 late collision, 0 deferred > 0 lost carrier, 0 no carrier, 0 pause output > 0 output buffer failures, 0 output buffers swapped out > > I have read about similar issues on the list: > http://www.gossamer-threads.com/lists/cisco/nsp/157217 > https://puck.nether.net/pipermail/cisco-nsp/2012-July/085889.html > > 1. I have no QoS policies applied to the physical interface or EVCs. > Would increasing the hold queue help? Is there a recommended value - the > maximum configurable is 24. What is the impact on the 44MB of packet > buffer. > > 2. If the hold queue isn't an option is configuring QoS required to > increase the queue-limit from the default 100us. Again are there any > recommended values and what impact is there on the available 44MB of > packet buffer. > > 3. I have found that when applying policies to the EVCs the "show policy > map" output does not have information for the queue-limit as I have seen > when applying polices to the physical interface. Does this mean that EVCs > will still suffer from output drops? > > Thanks > > Ivan ___ 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] ME3600X Output Drops
Hi, I am seeing output drops on a ME3600X interface as shown below GigabitEthernet0/2 is up, line protocol is up (connected) MTU 9216 bytes, BW 100 Kbit/sec, DLY 10 usec, reliability 255/255, txload 29/255, rxload 2/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45 input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 6w1d, output never, output hang never Last clearing of "show interface" counters 00:12:56 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 231 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 10299000 bits/sec, 5463 packets/sec 30 second output rate 114235000 bits/sec, 12461 packets/sec 3812300 packets input, 705758638 bytes, 0 no buffer Received 776 broadcasts (776 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 776 multicast, 0 pause input 0 input packets with dribble condition detected 9103882 packets output, 10291542297 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out I have read about similar issues on the list: http://www.gossamer-threads.com/lists/cisco/nsp/157217 https://puck.nether.net/pipermail/cisco-nsp/2012-July/085889.html 1. I have no QoS policies applied to the physical interface or EVCs. Would increasing the hold queue help? Is there a recommended value - the maximum configurable is 24. What is the impact on the 44MB of packet buffer. 2. If the hold queue isn't an option is configuring QoS required to increase the queue-limit from the default 100us. Again are there any recommended values and what impact is there on the available 44MB of packet buffer. 3. I have found that when applying policies to the EVCs the "show policy map" output does not have information for the queue-limit as I have seen when applying polices to the physical interface. Does this mean that EVCs will still suffer from output drops? Thanks Ivan ___ 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] ME3600X Embedded Packet Capture
Hi Waris,
Thanks, I hadn't tested the bridging mode yet on this platform but have
used on the ES+ linecards. Wouldn't be looking to use all the time as I
like the per port vlan scope when doing the xconnect on the evc.
Reconfiguring to bridging method for troubleshooting purposes seems to
be the only option for checking mac address.
Cheers
Ivan
On 13/Aug/2012 7:47 p.m., Waris Sagheer (waris) wrote:
Hi Ivan,
You can use the following EVPL configuration which would allow you to see the
mac addresses e.g. in the following example you can see the mac addresses under
bridge-domain 10.
interface GigabitEthernet0/1
switchport trunk allowed vlan none
switchport mode trunk
service instance 10 ethernet
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric
bridge-domain 10
interface Vlan10
no ip address
xconnect 2.2.2.2 10 encapsulation mpls
Regards,
Waris
-Original Message-----
From: Ivan [mailto:cisco-...@itpro.co.nz]
Sent: Sunday, August 12, 2012 7:17 PM
To: Pshem Kowalczyk
Cc: Ivan; Waris Sagheer (waris); cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ME3600X Embedded Packet Capture
Hi,
Yes, as far as I understand there is no mac learning which is great for resource
utilisation and scalability. No requirement other than "it is helpful for
troubleshooting" to see any macs.
Cheers
Ivan
Hi,
On 11 August 2012 10:32, Ivan wrote:
{cut}
xconnect 1.2.3.4 666 encapsulation mpls
Speaking from general experience - this is the culprit. In
point-to-point L2VPNs there is (usually, I admit I'm not sure if
that's the case on 3600x) no MAC address learning (which nicely
conserves the resources on the switch). If you really need to see that
address - you should turn that into a point-to-point VPLS.
kind regards
Pshem
___
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] ME3600X Embedded Packet Capture
Hi,
Yes, as far as I understand there is no mac learning which is great for
resource utilisation and scalability. No requirement other than "it is
helpful for troubleshooting" to see any macs.
Cheers
Ivan
> Hi,
>
>
> On 11 August 2012 10:32, Ivan wrote:
>
> {cut}
>
>> xconnect 1.2.3.4 666 encapsulation mpls
>
> Speaking from general experience - this is the culprit. In
> point-to-point L2VPNs there is (usually, I admit I'm not sure if
> that's the case on 3600x) no MAC address learning (which nicely
> conserves the resources on the switch). If you really need to see that
> address - you should turn that into a point-to-point VPLS.
>
> kind regards
> Pshem
>
___
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] ME3600X Embedded Packet Capture
Hi Waris, When troubleshooting a layer 2 service checking what mac addresses can seen seen from the customer has been very useful. Previously with a switched access we could look at the mac addresses on the access switch. With MPLS to the edge I haven't found anyway to be able to verify customer mac addresses. I was hopeful EPC may have been an option after looking at the release notes I previously referenced. Using a ME3600X for MPLS to the edge a layer 2 handoff may look something like the following interface GigabitEthernet0/1 description Customer A switchport mode trunk mtu 9216 load-interval 30 no cdp enable service instance 666 ethernet encapsulation dot1q 666 rewrite ingress tag pop 1 symmetric xconnect 1.2.3.4 666 encapsulation mpls With a switched access there would be similar config as the above on the PE but a switch (ACCESS) with vlan 666 between the PE and the customer. Checking what mac addresses are seen from the customer is as easy as "show mac address-table dynamic vlan 666" or "show mac address-table dynamic interface GigabitEthernet 0/1" With MPLS to the edge it is great the provider doesn't have to worry about keeping mac address tables etc - much more scalable, but it would be handy if there was an easy way to "peek" to help with troubleshooting, as it generally indicates if the problem lies with the customer or provider. Thanks Ivan On 11/Aug/2012 3:53 a.m., Waris Sagheer (waris) wrote: Hi Ivan, How do you want to verify the mac address? Can you send me configuration example on access layer switch? Also, what is the current configuration on ME3600X? Regards, Waris -Original Message- From: Ivan [mailto:cisco-...@itpro.co.nz] Sent: Friday, August 10, 2012 3:27 AM To: Waris Sagheer (waris) Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ME3600X Embedded Packet Capture Hi Waris, I had come across that bug referring to EPC in "Release Notes for the Cisco ME 3800X and ME 3600X Switch" - http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.1_2_ey/release/notes/ol25360.html and had hoped that the feature was available. I wasn't able to find any other documentation thus my question to the list. What I am really looking for is a possible way to verify any seen mac addresses on a customer EVC xconnect when running MPLS to the edge for troubleshooting. This was quite easy and useful with a switched access layer. I don't really want to xconnect on vlans and bridge to EVCs (not sure that is possible on the ME3600X platform) Thanks Ivan On 10/Aug/2012 8:09 p.m., Waris Sagheer (waris) wrote: Ivan, Which packet capture you are referring to on ME3600X? There is no support of embedded packet capture on ME3600X. Regards, Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan Sent: Thursday, August 09, 2012 10:35 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ME3600X Embedded Packet Capture Hi, Has anyone used Embedded Packet Capture on the ME3600X successfully? If so are their any gotchas to be weary of? The only things that come up when I search for this is CSCtq11526 Embedded Packet Capture stops BFD neighbor adjacency, but have been unable to find details of what packets can be captured - hardware v cpu etc. Any documentation pointers would be appreciated. Thanks Ivan ___ 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] ME3600X Embedded Packet Capture
Hi Waris, I had come across that bug referring to EPC in "Release Notes for the Cisco ME 3800X and ME 3600X Switch" - http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/15.1_2_ey/release/notes/ol25360.html and had hoped that the feature was available. I wasn't able to find any other documentation thus my question to the list. What I am really looking for is a possible way to verify any seen mac addresses on a customer EVC xconnect when running MPLS to the edge for troubleshooting. This was quite easy and useful with a switched access layer. I don't really want to xconnect on vlans and bridge to EVCs (not sure that is possible on the ME3600X platform) Thanks Ivan On 10/Aug/2012 8:09 p.m., Waris Sagheer (waris) wrote: Ivan, Which packet capture you are referring to on ME3600X? There is no support of embedded packet capture on ME3600X. Regards, Waris -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan Sent: Thursday, August 09, 2012 10:35 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ME3600X Embedded Packet Capture Hi, Has anyone used Embedded Packet Capture on the ME3600X successfully? If so are their any gotchas to be weary of? The only things that come up when I search for this is CSCtq11526 Embedded Packet Capture stops BFD neighbor adjacency, but have been unable to find details of what packets can be captured - hardware v cpu etc. Any documentation pointers would be appreciated. Thanks Ivan ___ 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] ME3600X Embedded Packet Capture
Hi, Has anyone used Embedded Packet Capture on the ME3600X successfully? If so are their any gotchas to be weary of? The only things that come up when I search for this is CSCtq11526 Embedded Packet Capture stops BFD neighbor adjacency, but have been unable to find details of what packets can be captured - hardware v cpu etc. Any documentation pointers would be appreciated. Thanks Ivan ___ 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] ME3600X IOS Version
Hi, I know the ME3600X has come up quite a lot recently on this list, but as far as I recall and can find, it has been a while since there have been any comments regarding the "best/most stable" version. I am currently running 151-2.EY but will deploying some more hardware shortly and would be interested what versions others are successfully using, especially 15.2S or 15.2S1. 151-2.EY has been good so far but I am aware of the rapid development on software for this platform and also that there are quite a few issues around. Thanks Ivan ___ 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] ip access list rfc1918 help please
Hi It is probably also worth looking at RFC5735 for other IP addresses that could be filtered. Ivan On 24/Jun/2012 10:37 a.m., Randy wrote: --- On Sat, 6/23/12, Mike wrote: From: Mike Subject: [c-nsp] ip access list rfc1918 help please To: "'Cisco-nsp'" Date: Saturday, June 23, 2012, 2:42 PM Howdy, I am trying to filter out rfc1918 addresses as either source or destination addresses for my pppoe connected subscribers. Each subscriber has a radius item 'Filter-Id' with the name of a filter, with the majority being 'customer_filter1', and it seems that although this is in fact being applied to the virtual-access interfaces per customer, it doesn't work as I expect since I can clearly see traffic from customer -> rfc1918 address space still being forwarded. Here's a sample 'sh ip interface" showing the filter being applied: c7201-bras#sh ip interface virtual-access 190 Virtual-Access190 is up, line protocol is up Interface is unnumbered. Using address of Loopback0 (x.x.x.x) Broadcast address is 255.255.255.255 Peer address is y.y.y.y MTU is 1492 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is customer_filter1 Inbound access list is not set etc, etc Here is the filter itself: ip access-list extended customer_filter1 deny ip host 0.0.0.0 any deny ip 127.0.0.0 0.255.255.255 any deny ip 192.0.2.0 0.0.0.255 any deny ip 224.0.0.0 31.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny ip any host 0.0.0.0 deny ip any 127.0.0.0 0.255.255.255 deny ip any 192.0.2.0 0.0.0.255 deny ip any 224.0.0.0 31.255.255.255 deny ip any 10.0.0.0 0.255.255.255 deny ip any 172.16.0.0 0.15.255.255 deny ip any 192.168.0.0 0.0.255.255 permit ip any any Any ideas? Mike- customer-TO-rfc1918 is INBOUND on virtual-access 190 You have an outbound acl applied. In that regard, I would say it is "working as expected". ./Randy ___ 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] Filtering Routes with Private AS Numbers in the AS Path
Hi Nick, Thanks very much for your thorough response and the time your put into testing things out. I was contemplating taking this to my lab but was hoping there was some documentation or experiences from others that may have helped answer things first. Your results are interesting - I did suspect option 2 would be better but didn't really have any idea of the numbers. Saving time and processing cycles on BGP routes is always good. Interesting to see just how may routes with private AS number in their paths are out there in the DFZ too. Thanks Ivan ___ 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] Filtering Routes with Private AS Numbers in the AS Path
Hi, For filtering private as numbers (64512-65535) using an as-path access-list there are a few options I have seen: 1). All in one line ip as-path access-list 66 permit _(6451[2-9]|645[2-9][0-9]|64[6-9][0-9][0-9]|65[0-4][0-9][0-9]|655[0-2][0-9]|6553[0-5])_ 2). The above modified hopefully to be "better" in terms or regexp processing but perhaps not readability ip as-path access-list 66 permit _6(4(5(1[2-9]|[2-9][0-9])|[6-9][0-9][0-9])|5([0-4][0-9][0-9]|5([0-2][0-9]|3[0-5])))_ 3). Separate lines ip as-path access-list 66 permit _6451[2-9]_ ip as-path access-list 66 permit _645[2-9][0-9]_ ip as-path access-list 66 permit _64[6-9][0-9][0-9]_ ip as-path access-list 66 permit _65[0-4][0-9][0-9]_ ip as-path access-list 66 permit _655[0-2][0-9]_ ip as-path access-list 66 permit _6553[0-5]_ I would appreciate any feedback as to which is the least CPU intensive and if there is a better way to optimise 2 above. Thanks Ivan ___ 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] QinQ Cisco 3750 ?
Hi Oliver, I think what you are wanting to do is called "selective QinQ". For this you are looking at hardware such as ME3400 (http://www.cisco.com/en/US/docs/switches/metro/me3400e/software/release/12.2_50_se/configuration/guide/swtunnel.html#wp1059629) For port A you would end up with something like this on a ME3400 Switch(config)# interface gigabiethernet0/1 Switch(config-if)# switchport vlan mapping 500-600 dot1q-tunnel 100 Switch(config-if)# switchport vlan mapping 700-800 dot1q-tunnel 101 Switch(config-if)# switchport vlan mapping 900-1000 dot1q-tunnel 102 Switch(config-if)# switchport vlan mapping drop default Switch(config-if)# exit You can also do similar on the ES+ lincards and maybe even the 3750ME (probably limited to the ES ports..) Ivan On 8/Jan/2012 12:16 a.m., Olivier CALVANO wrote: Hi I am search a solution for this project: Cisco 7301 connected to a Cisco 3750 "A" by a Fiber Gig port. Port is in trunk C7301<==> C3750 port gig 0/24 The cisco 3750 "A" is connecter in trunk to a carrier by the Gig 0/23. The carrier supply 4 ports: 1 Central Port connected to C3750 "A" 1 Port connected to C3750 "B" 1 Port connected to C3750 "C" 1 Port connected to C3750 "D" And on each, he supply one vlan Vlan 100: From C3750"A" to Cisco 3750 "B" Vlan 101: From C3750"A" to Cisco 3750 "C" Vlan 102: From C3750"A" to Cisco 3750 "D" I want use QinQ for: Cisco 7301 use vlan 500 to 600 for going on 3750 "B" Cisco 7301 use vlan 700 to 800 for going on 3750 "C" Cisco 7301 use vlan 900 to 1000 for going on 3750 "D" Sample: C7301 ge0/1.500 => trunk => C3750 "A"<== Dot1q Tunnel into Vlan 100 ==> C3750 "B" => Trunk => C2821 ge1/1.500 C7301 ge0/1.750 => trunk => C3750 "A"<== Dot1q Tunnel into Vlan 101 ==> C3750 "C" => Trunk => C1841 ge1/1.750 C7301 ge0/1.950 => trunk => C3750 "A"<== Dot1q Tunnel into Vlan 102 ==> C3750 "D" => Trunk => C2811 ge1/1.950 It's possible ? Thanks Olivier ___ 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] MPLS-Aware (Flexible) NetFlow
Hi, I am trying to get Netflow going on some ASR1004s running asr1000rp2-advipservicesk9.03.04.01.S.151-3.S1.bin. I started off simple and did regular Netflow for IPv4 something like ip flow-export version 9 ip flow-export destination x.x.x.x 5000 interface x ip flow ingress This worked for IPv4 but gave me no stats for MPLS labelled traffic so I tried ip flow-cache mpls label-positions 1 2 That didn't help at all. I also wanted IPv6 Netflow and it seems that regular Netflow is not an option so I have now moved to "Flexible Netflow" - something like the following flow exporter FE destination x.x.x.x transport udp 5000 flow monitor FM_IPv4 record netflow ipv4 original-input exporter FE flow monitor FM_IPv6 record netflow ipv6 original-input exporter FE interface x no ip flow ingress ip flow monitor FM_IPv4 input ipv6 flow monitor FM_IPv6 input So far I seem to be good for IPv4 and IPv6 but still am missing stats for MPLS labelled packets. Does anyone know if MPLS-Aware ingress Netflow is available in ASR1004/IOS-XE in either regular or Flexible flavour? If anyone has a working example or can point to some doco that would be great. From what I have seen I am suspecting that MPLS-Aware Netflow may only be available in egress using standard no flexible version??? Also an anyone confirm Flexible Netflow is the only way to get IPv6 flows? Thanks Ivan ___ 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] Central services VRF, how to
A number of years ago I came across some limitations regarding the number of route targets that could be associated with a prefix. I do not recall the details but one could imagine that there is some limit to the number or RTs (64 bits) that can be attached to a prefix (exported). I have not been able to find any Cisco documentation but if indeed this is the case the solution you propose would only be possible up until a certain number of customer VRFs. Googling found this good reference, although I thought the number I came across was much less - perhaps an older softwrae limitaion. http://blog.ioshints.info/2011/05/scalability-of-common-services-mplsvpn.html Cheers Ivan On 24/Nov/2011 9:35 a.m., Peter Rathlev wrote: Before I make a complete fool of myself I thought I'd ask you nerds. :-) I'm testing setting up a "central services" VRF that's supposed to service 30-something other VRFs. The idea is of course to have all the other VRFs be able to reach stuff within this VRF and vice versa. Overlapping addressing is not a concern here. From "school" (642-611) I learned that one would use different "hub" and "spoke" route-targets, like described in RFC 4364 4.3.5. Something like this: ip vrf CustA rd 1:1 route-target both 1:1!<-- "own" RT route-target import 2:1 !<-- import from "spoke" RT route-target export 2:2 !<-- export to "hub" RT ! ip vrf CustB rd 1:2 route-target both 1:2!<-- same as above... route-target import 2:1 route-target export 2:2 ! ip vrf CS description Central Services rd 3:1 route-target both 3:1 route-target import 2:1 !<-- import from "hub" RT route-target export 2:2 !<-- export to "spoke" RT ! What I don't like about this is that I'd have to configure each and every PE in each of the "customer" VRFs. Why not just do like this: ip vrf CustA rd 1:1 route-target both 1:1!<-- Completely plain VRF ! ip vrf CustB rd 1:2 route-target both 1:2 ! ip vrf CS description Central Services rd 3:1 route-target both 3:1 route-target both 1:1!<-- Import& export CustA route-target both 1:2!<-- Import& export CustB ! Any gotchas with this compared to the former? What am I missing that the school book example would give me? AFAICT I would only need this configuration on the PE devices actually hosting CS networks, since I export directly to all the relevant VRFs. This is very simplified. I would of course use an import map on the CS VRF and also make sure that only the relevant prefixes are exported from it. (The networks I'd like to "CS-ify" would be the only ones in that VRF on that PE; external routes (default etc.) would come from another PE that wouldn't have this configuration.) I also tested exporting via a route-map, and though it seems to scale a little better on account of not needing the "route-target export" statements, I can find no functional differences. Feel free to refer me to literature, "fine" or otherwise. :-) ___ 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] Unable to transmit tagged frames over q-in-q tunnel
Hi, It would be useful to see your PE configuration and have details of the hardware and OS versions. I recently came across an issue like this when using ASR1001s as PEs. As far as I could tell the ASRs wouldn't match up a double tagged packet to an interface defined to match a single tag. Eventually an IOS upgrade fixed this problem. You can easily test by reconfiguring the PE interface to "encapsulation dot1Q xxx second‐dot1q any" then you may be able to pass the double tagged traffic but no longer the traffic in the native vlan (single SVID only). asr1000rp1‐advipservicesk9.03.04.01.S.151‐3.S1.bin fixed the issue for me. (I had trouble with asr1000rp1-advipservicesk9.03.03.01.S.151‐2.S1.bin and asr1001‐universalk9.03.02.00.S.151‐1.S.bin Ivan On 28/Oct/2011 5:28 a.m., Gökhan Gümüş wrote: Dear folks, I have an issue with one of our customer service. Gi0/5 Gi0/27 Gi5/13 Fa3/13 Customer SW Customer Edge Switch-A PE1 --MPLS Core --PE 2--Customer Edge Switch-B --Customer SW I am using q-in-q tunneling to enable customer traffic. Before, customer port on Customer SW facing our edge switch was in ACCESS mode and it was working. Now they have decided to configure this interface as a TRUNK to transmit multiple VLANs over the trunk. But they can not. Currently ports are configured as trunk and customer can only transmit traffic when they do not tag frames ( native-vlan config ) For note, i am not using " vlan dot1q tag native " command which is also double-tagging native vlans. MTU is fine and above 1504 bytes. Please see our configs on Customer Edge Switch below; *Customer Edge Switch A;* A#sh run interface Gigabit Ethernet0/5 Building configuration... Current configuration : 337 bytes ! interface GigabitEthernet0/5 switchport access vlan 1106 switchport mode dot1q-tunnel switchport nonegotiate load-interval 60 speed 100 duplex full l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable end A#sh run interface GigabitEthernet0/27 Building configuration... Current configuration : 251 bytes ! interface GigabitEthernet0/27 switchport trunk encapsulation dot1q switchport trunk allowed vlan 1,9,1101,1102,1106 switchport mode trunk switchport nonegotiate end - *Customer Edge Switch B;* B#sh run interface fa3/13 Building configuration... Current configuration : 366 bytes ! interface FastEthernet3/13 mtu 2000 load-interval 60 switchport switchport access vlan 1106 switchport mode dot1q-tunnel switchport nonegotiate l2protocol-tunnel cdp l2protocol-tunnel stp l2protocol-tunnel vtp no cdp enable spanning-tree bpdufilter enable end B#sh run interface gi5/13 Building configuration... Current configuration : 298 bytes ! interface GigabitEthernet5/13 mtu 2000 load-interval 30 speed nonegotiate switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1101,1102,1106 switchport mode trunk no cdp enable end Is there anybody who had such issue before? Thanks and regards, Gokhan Gumus ___ 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] How to terminate 100.000 IPsec VPN clients?
Hi Florian, Yeah, it is quite interesting! But on first look over the link maybe it does not support RA IPsec tunnels or at least it is not stated. But on the other hand the module is supported by IOS so I don't see a reason why it will not support it. If you don't forget share with us your findings as it seams that this product is pretty new. HTH, On Tue, Sep 6, 2011 at 10:34, Florian Bauhaus wrote: > On 09/05/11 21:11, Ivan Ivanov wrote: > > Hi, > > > > Did you check that? The target customers for that module are the mobile > > operators but could fit your requirements. > > > > > http://www.cisco.com/en/US/prod/collateral/wireless/wirelssw/ps10346/data_sheet_c78-532047.html- > Cisco > > Wireless Security Gateway R2 > > > > HTH, > > > > -- > > Best Regards! > > > > Ivan Ivanov > > > That one actually seems pretty interesting. I'll have a deeper look into > it. > > > Best regards, > Florian > ___ > 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/ > -- Best Regards! Ivan Ivanov ___ 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] How to terminate 100.000 IPsec VPN clients?
Hi, Did you check that? The target customers for that module are the mobile operators but could fit your requirements. http://www.cisco.com/en/US/prod/collateral/wireless/wirelssw/ps10346/data_sheet_c78-532047.html - Cisco Wireless Security Gateway R2 HTH, On Fri, Sep 2, 2011 at 16:55, Florian Bauhaus wrote: > Hello, > > What would be the best way to terminate 100k IPsec VPN clients? > > Use a 6500/7600 with appropriate modules? Put 10 ASA5580-20 in a rack? > How to manage the whole thing? > The clients won't make a lot of traffic so throughput isn't really a > matter. > > I already got a few ideas on how to do this but I would like to know if > someone else got experience with this and could help me out a bit. > > > Best regards, > Florian > ___ > 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/ > -- Best Regards! Ivan Ivanov ___ 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] 7600 RP Invalid Packet Drops
TAC did confirm that we were encountering CSCte89940. As is seems to only be an issue for ping traffic to the RP we will not be upgrading imeediately but waiting for the next upgrade cycle so I can't comment regarding the fixed software. Thanks all (especially) Antonio for your help. Cheers Ivan On 30/Apr/2011 10:07 p.m., Antonio Soares wrote: My end customer was running the same release (122-33.SRD4) but they didn't perform the upgrade since the issue was not affecting transit traffic. But TAC said that the upgrade to 122-33.SRD5 would solve the problem. Regards, Antonio Soares, CCIE #18473 (R&S/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message----- From: Ivan [mailto:cisco-...@itpro.co.nz] Sent: sábado, 30 de Abril de 2011 02:48 To: Antonio Soares; cisco-nsp Subject: Re: [c-nsp] 7600 RP Invalid Packet Drops Hi Antonio, Thanks for the bug id. I forgot to mention in my first post the 7600 in question is running 12.2(33)SRD4. The bud info indicates it should be fixed in 12.2(33)SRD5. Did you manage to upgrade your 7600 and fix the issue successfully? Cheers Ivan On 30/Apr/2011 12:54 p.m., Antonio Soares wrote: I had this problem a few weeks ago. It was bug CSCte89940: +++ IBC invalid packet drop on RSP 720 Symptoms While pinging 7600 with RSP 720 we see some drops. These drops are counted under show ibc under "Invalid pkts dropped" Conditions The issue is seen on RSP 720 with SRD image. Workaround SRC05 and SRB07 do not have this issue, nor it is present with SUP 720. +++ Regards, Antonio Soares, CCIE #18473 (R&S/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan Sent: sábado, 30 de Abril de 2011 01:24 To: cisco-nsp Subject: [c-nsp] 7600 RP Invalid Packet Drops I have a 7600 with a RSP720-3CXL-GE. When pinging between the 7600 and any other device (I have tried a few) I am loosing packets - usually 5/1 ish. I have eventually been able to match the number of lost packets with a counter from the output of "show ibc" which from my searching of the archives "shows you the inband interface leading to the RP CPU". The counter is: Invalid pkts dropped: 306 Can anyone advise what this counter indicates? Only seems to increment with my ping traffic and not any customer traffic. I have other similar hardware but can not reproduce the issue :-( The output 7600#show ibc Interface information: Interface IBC0/0(idb 0x1C88ECE8) 5 minute rx rate 1138000 bits/sec, 156 packets/sec 5 minute tx rate 2305000 bits/sec, 306 packets/sec 1529092452 packets input, 97618397184 bytes 1480180863 broadcasts received 1522436849 packets output, 93778000882 bytes 15858294 broadcasts sent 0 Bridge Packet loopback drops 1415112685 Packets CEF Switched, 0 Packets Fast Switched 0 Packets SLB Switched, 0 Packets CWAN Switched Label switched pkts dropped: 0Pkts dropped during dma: 0 Invalid pkts dropped: 306Pkts dropped(not cwan consumed): 0 Xconnect pkts processed: 29, dropped: 0 Xconnect pkt reflection drops: 0 Total paks copied for process level 29 Total short paks sent in route cache 1346148563 Total throttle drops 0Input queue drops 0 total spd packets classified (50929199 low, 6698050 medium, 34521686 high) total spd packets dropped (0 low, 0 medium, 0 high) spd prio pkts allowed in due to selective throttling (0 med, 0 high) IBC resets = 1; last at xxx 2010 Driver Level Counters: (Cumulative, Zeroed only at Reset) Frames Bytes Rx(0) 878738849 2018480538 Rx(1) 653772091 3242895654 Tx(0) 1522436850 1746755712 Input Drop Frame Count Rx0 = 0Rx1 = 0 Per Queue Receive Errors: FRME OFLW BUFE NOENP DISCRD DISABLE BADCOUNT Rx0 0 0 0 0 000 Rx1 0 0 0 0 000 Tx Errors/State: One Collision Error = 0More Collisions = 0 No Encap Error= 0Deferred Error= 0 Loss Carrier Error= 0Late Collision Error = 0 Excessive Collisions = 0Buffer Error = 0 Tx Freeze Count = 0Tx Intrpt Serv timeout= 1 Counters collected at Idb: Is input throttled= 0Throttle Count= 0 Rx Resource Errors= 0Input Drops = 306 Input Errors = 0 Output Drops = 0Giants/Runts = 0/0 Dma Mem Error = 0Input Overrun = 0 7600#sh
Re: [c-nsp] 7600 RP Invalid Packet Drops
Hi Antonio, Thanks for the bug id. I forgot to mention in my first post the 7600 in question is running 12.2(33)SRD4. The bud info indicates it should be fixed in 12.2(33)SRD5. Did you manage to upgrade your 7600 and fix the issue successfully? Cheers Ivan On 30/Apr/2011 12:54 p.m., Antonio Soares wrote: I had this problem a few weeks ago. It was bug CSCte89940: +++ IBC invalid packet drop on RSP 720 Symptoms While pinging 7600 with RSP 720 we see some drops. These drops are counted under show ibc under "Invalid pkts dropped" Conditions The issue is seen on RSP 720 with SRD image. Workaround SRC05 and SRB07 do not have this issue, nor it is present with SUP 720. +++ Regards, Antonio Soares, CCIE #18473 (R&S/SP) amsoa...@netcabo.pt http://www.ccie18473.net -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan Sent: sábado, 30 de Abril de 2011 01:24 To: cisco-nsp Subject: [c-nsp] 7600 RP Invalid Packet Drops I have a 7600 with a RSP720-3CXL-GE. When pinging between the 7600 and any other device (I have tried a few) I am loosing packets - usually 5/1 ish. I have eventually been able to match the number of lost packets with a counter from the output of "show ibc" which from my searching of the archives "shows you the inband interface leading to the RP CPU". The counter is: Invalid pkts dropped: 306 Can anyone advise what this counter indicates? Only seems to increment with my ping traffic and not any customer traffic. I have other similar hardware but can not reproduce the issue :-( The output 7600#show ibc Interface information: Interface IBC0/0(idb 0x1C88ECE8) 5 minute rx rate 1138000 bits/sec, 156 packets/sec 5 minute tx rate 2305000 bits/sec, 306 packets/sec 1529092452 packets input, 97618397184 bytes 1480180863 broadcasts received 1522436849 packets output, 93778000882 bytes 15858294 broadcasts sent 0 Bridge Packet loopback drops 1415112685 Packets CEF Switched, 0 Packets Fast Switched 0 Packets SLB Switched, 0 Packets CWAN Switched Label switched pkts dropped: 0Pkts dropped during dma: 0 Invalid pkts dropped: 306Pkts dropped(not cwan consumed): 0 Xconnect pkts processed: 29, dropped: 0 Xconnect pkt reflection drops: 0 Total paks copied for process level 29 Total short paks sent in route cache 1346148563 Total throttle drops 0Input queue drops 0 total spd packets classified (50929199 low, 6698050 medium, 34521686 high) total spd packets dropped (0 low, 0 medium, 0 high) spd prio pkts allowed in due to selective throttling (0 med, 0 high) IBC resets = 1; last at xxx 2010 Driver Level Counters: (Cumulative, Zeroed only at Reset) Frames Bytes Rx(0) 878738849 2018480538 Rx(1) 653772091 3242895654 Tx(0) 1522436850 1746755712 Input Drop Frame Count Rx0 = 0Rx1 = 0 Per Queue Receive Errors: FRME OFLW BUFE NOENP DISCRD DISABLE BADCOUNT Rx0 0 0 0 0 000 Rx1 0 0 0 0 000 Tx Errors/State: One Collision Error = 0More Collisions = 0 No Encap Error= 0Deferred Error= 0 Loss Carrier Error= 0Late Collision Error = 0 Excessive Collisions = 0Buffer Error = 0 Tx Freeze Count = 0Tx Intrpt Serv timeout= 1 Counters collected at Idb: Is input throttled= 0Throttle Count= 0 Rx Resource Errors= 0Input Drops = 306 Input Errors = 0 Output Drops = 0Giants/Runts = 0/0 Dma Mem Error = 0Input Overrun = 0 7600#show platform hardware pfc mode PFC operating mode : PFC3CXL Cheers Ivan ___ 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] 7600 RP Invalid Packet Drops
I have a 7600 with a RSP720-3CXL-GE. When pinging between the 7600 and any other device (I have tried a few) I am loosing packets - usually 5/1 ish. I have eventually been able to match the number of lost packets with a counter from the output of "show ibc" which from my searching of the archives "shows you the inband interface leading to the RP CPU". The counter is: Invalid pkts dropped: 306 Can anyone advise what this counter indicates? Only seems to increment with my ping traffic and not any customer traffic. I have other similar hardware but can not reproduce the issue :-( The output 7600#show ibc Interface information: Interface IBC0/0(idb 0x1C88ECE8) 5 minute rx rate 1138000 bits/sec, 156 packets/sec 5 minute tx rate 2305000 bits/sec, 306 packets/sec 1529092452 packets input, 97618397184 bytes 1480180863 broadcasts received 1522436849 packets output, 93778000882 bytes 15858294 broadcasts sent 0 Bridge Packet loopback drops 1415112685 Packets CEF Switched, 0 Packets Fast Switched 0 Packets SLB Switched, 0 Packets CWAN Switched Label switched pkts dropped: 0Pkts dropped during dma: 0 Invalid pkts dropped: 306Pkts dropped(not cwan consumed): 0 Xconnect pkts processed: 29, dropped: 0 Xconnect pkt reflection drops: 0 Total paks copied for process level 29 Total short paks sent in route cache 1346148563 Total throttle drops 0Input queue drops 0 total spd packets classified (50929199 low, 6698050 medium, 34521686 high) total spd packets dropped (0 low, 0 medium, 0 high) spd prio pkts allowed in due to selective throttling (0 med, 0 high) IBC resets = 1; last at xxx 2010 Driver Level Counters: (Cumulative, Zeroed only at Reset) Frames Bytes Rx(0) 878738849 2018480538 Rx(1) 653772091 3242895654 Tx(0) 1522436850 1746755712 Input Drop Frame Count Rx0 = 0Rx1 = 0 Per Queue Receive Errors: FRME OFLW BUFE NOENP DISCRD DISABLE BADCOUNT Rx0 0 0 0 0 000 Rx1 0 0 0 0 000 Tx Errors/State: One Collision Error = 0More Collisions = 0 No Encap Error= 0Deferred Error= 0 Loss Carrier Error= 0Late Collision Error = 0 Excessive Collisions = 0Buffer Error = 0 Tx Freeze Count = 0Tx Intrpt Serv timeout= 1 Counters collected at Idb: Is input throttled= 0Throttle Count= 0 Rx Resource Errors= 0Input Drops = 306 Input Errors = 0 Output Drops = 0Giants/Runts = 0/0 Dma Mem Error = 0Input Overrun = 0 7600#show platform hardware pfc mode PFC operating mode : PFC3CXL Cheers Ivan ___ 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] IP Header Checksum Errors
Hi, I have a 6509 running 12.2(18)SXF4. I find a lot of the following errors in the logs %MLS_STAT-SP-4-IP_CSUM_ERR: IP checksum errors %EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-fatal interrupt Packet Parser block interrupt >From what I read, these are informational (http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801b42bf.shtml#EARL) While as per the above I could disable the informational message I could also try to locate and fix the problem. I don't imagine SPAN will actually SPAN packets with IP header checksum errors and even if it does it seems it may be hard to get a sniffer that has an OS that will not also discard the packets. I was wondering if anyone had any ideas or experience with this. Also using ELAM (http://cisco.cluepon.net/index.php/Using_capture_buffer_with_ELAM or https://supportforums.cisco.com/message/3006679?tstart=-1) would be good. I am not sure if the filter can be set to packets with IP header checksum errors either Cheers Ivan ___ 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] VTP war stories (was Re: EoMPLS or VPLS loop prevention/storm control)
It is not always as well known, but client mode will not prevent "usurping the vtp domains" This article covers things in a bit more detail - http://www.networkworld.com/community/node/19931 Ivan > I'd agree that vtp can cause major problems if not deployed with caution > & mechanisms to mitigate disasters. we have a huge lan infrastructure > here with over 65,000 edge ports. what we do is divide the > campus/enterprise into 18 vtp domains so if there is a layer2 or vtp > meltdown this doesn't affect all of campus; also the core switch (in > this case 6509 w/sup720-3bxl) per vtp domain is the sole designated vtp > "server" mode device (this is important) as well as the root bridge > (fine-tune stp cost to do so); all others are in client mode or > transparent. for edge or distribution switches, it also important to > change default "server" mode to client (or transparent) -- again this is > important to avoid usurping the vtp domains. vtp comes in handy when > dealing with large amount of ports and one doesn't want to hand > configure vlan to port mapping manually; however as already mention all > of this is not without risks. > > when our current network was deployed intially about 7 years ago, we had > periodic spanning-tree meltdown per vtp domain, but never to all 18 vtp > domain at the same time; root cause was typical offenders: > * misbehaving gear that seized control as root bridge > * dumb hub connecting multiple vlans > * etc. > > over the years, cisco ios has had many vtp/stp/layer-2 bugs worked out; > and I'd say one doesn't see as much issues in this area as was in the > past; but caution is always a good thing. > > > -- > Regards, > Ge Moua > > Network Design Engineer > University of Minnesota | OIT - NTS > -- > > > On 2/9/11 4:28 PM, Paul Wozney wrote: >> I've seen VTP fail spectacularly. >> >> A customer was using it on about 30 switches distributed to about 10-15 >> wiring closets. They had a temp student come in who wanted to learn >> about >> networking, so the student copied the core switch configuration and >> deployed >> it on a lab switch. The student decided to wipe the VLANs from this lab >> switch and start from scratch. >> >> When the lab switch was connected to the production network, its VTP >> instance had the correct VTP password (as it was copied from the core >> switch), but it had none of the VLANs required for the correct operation >> of >> the network, and of course it had the higher revision number. >> >> It was an innocent mistake, but it ended up to be a very bad day for >> everyone involved and we've never used VTP for any other customer since >> that >> day. >> >> --- >> Paul Wozney >> Network Consultant >> phone: +1 604-629-9975 >> toll free: +1 866-748-0516 >> email: p...@wozney.ca >> web: http://wozney.ca >> >> >> >> On Wed, Feb 9, 2011 at 14:10, Martin Barry wrote: >> >>> $quoted_author = "Nick Hilliard" ; >>>> Also, don't use VTP unless you like living dangerously. >>> Nick, that sounds like you have a good war story or three. Care to >>> share? >>> >>> Can't say I've blown anything up with VTP ... yet. :-) >>> >>> cheers >>> Marty >>> ___ >>> 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] Mysterious tunnel interfaces
> I was working on a ISR 1941 with 15.0(1)M2. I am running DMVPN on it > and using one tunnel interface. (Tunnel 1). No other tunnel > interfaces are configured on the router. However when I do "show int > summary" I get this; > > #sh int summary > > *: interface is up > IHQ: pkts in input hold queue IQD: pkts dropped from input queue > OHQ: pkts in output hold queueOQD: pkts dropped from output queue > RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec) > TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec) > TRTL: throttle count > > Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL > > * GigabitEthernet0/0 0 00 0 60005 600050 > GigabitEthernet0/1 0 00 0 00 000 > * Serial0/0/0 0 00 0 30003 200020 > NVI0 0 00 0 00 000 > * Tunnel0 0 00 0 00 000 > * Tunnel1 0 0010 10002 100020 > * Tunnel2 0 00 0 00 000 > * Tunnel3 0 00 0 00 000 > > I thought may be something got left behind while I was monkeying > around in it so I reloaded the router and the tunnel 0,2,3 are still > there and it says it's up. None of those interfaces are in the > startup or running-config. > > What is going on here? My other routers with similar config on a 1841 > with 12.4(15)T* doesn't have this issue. It doesn't seem to be > affecting the routing of traffic but it's really bothering me. > > -Jay I have seen similar on ASRs. From memory I think there were some of the mystery tunnels and then quite a few more after enabling multicast.. Would be great to see an explaination though. Cheers Ivan ___ 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] IPv6 ACL
Can anyone confirm that IPv6 ACLs successfully match packets on upper layer protocols (ULP) such as TCP even when the Hop-by-Hop EH (extension header) is present? I found some information regarding matching ULPs when the AH extension header is present but have been unable to do the same for the Hop-by-Hop EH. (http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-sec_trfltr_fw.html#wp1072428) Cheers Ivan ___ 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] Bundling ports on different WS6704 linecards
On 9/Aug/2010 11:22 p.m., Phil Mayers wrote: On 09/08/10 08:47, Rin wrote: Hi group, We are building a Core network of 3 7609 routers connecting as a 40Gbps ring. On each router we have 4 WS6704 linecards. Each router will be connected to other routers via 4 10G-links, these links will be configured as Port-Channel. Should we place each link of the port-channel on different linecard on each router or should we allocate all 4 links on the same linecard? Anyone has any problem with configuring etherchannel for ports on different WS6704 linecards? We do that extensively. It works fine. It is better to have cross-linecard portchannels in general. HOWEVER - there are a couple of caveats to be aware of. One is if you've got different linecards with different QoS queuing, you will need: int PoX no mls qos channel-consistency Second is that there are some issues with cross-linecard portchannels if you have service modules (ACE, FWSM, WiSM) in the chassis. I can't remember the details or find the link at the moment. ___ 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/ I was bitten by the FWSM and DEC. The link that was referred to is probably http://www.cisco.com/en/US/ts/fn/610/fn61935.html Field Notice: FN - 61935 - Catalyst 6500 Series and 7600 Series Service Module Incompatibility With Distributed EtherChannel and Packet Re-Circulation "Problem Description When the listed service modules transmit packets to VLANs also used with Distributed EtherChannel (DEC), those packets may be dropped and lost. Background The listed service modules do not support packet re-circulation. Packet re-circulation is a specific means to forward packets internal to the chassis between modules. When the service module attempts to forward a packet onto such a VLAN with packet-recirculation enabled, it may fail and the packet might be lost. When packet re-circulation is not enabled on the destination VLAN, even if DEC is present, this problem will not be encountered." We ended up getting rid of the DEC and using plain EC and "no monitor session servicemodule" as the span sessions were required for other purposes. (http://www.cisco.com/en/US/products/hw/modules/ps2706/products_qanda_item09186a00801e9e26.shtml#q44) Cheers Ivan ___ 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] 3750 and L3 service policies
"The show policy-map interface command is not supported on 3750 and 3560 switches, even though it is allowed to be typed in the CLI." (https://supportforums.cisco.com/message/545443#545443) *It is possible to see some statistics using the following commands clear mls qos interface statistics show mls qos interface statistics but the output doesn't confirming marking occurring rather just details the (DSCP) markings on traffic entering and leaving interfaces. Ivan > Hi, > > We had to deploy some L3 service policies on a WS-C3750E-24TD. After > the config was put in place we could see it working on the interface, > but according the the statistics on the input route-map - there was > nothing matching at all. > Is that expected? The switch runs only as a L2 switch, except for that > single access list. > > software: 12.2(44)SE1 > > class-map match-all CLASS_SLAP > match access-group name ACL_SLAP > > policy-map POLICY_SLAP > class CLASS_SLAP > police 8000 128000 exceed-action drop > > ip access-list extended ACL_SLAP > deny tcp any eq www any > permit ip any any > > kind regards > pshem > ___ > 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] Etherchannel load balancing catalyst 3560-E-24TS
Hi all I'd like to know if is possible to achieve equal load balancing on 3560-E-TS switch. Basically I got 2 switches interconneted with 2 FE ports. 200Mbps is desirable throughput between themselves. IP routing enabled. CEF not enabled. port channel is L2 trunk dot1q. I have 2 VRFs VLAN 100 - SW1 customer VRF1 VLAN 200 - SW1 and SW2 interconnection between swithces for VRF1 VLAN 300 - SW2 customer VRF1 VLAN 400 - SW1 customer 2 VRF2 VLAN 500 - SW1 and SW2 interconnection between swtiches for VRF2 VLAN 600 - SW2 customer 2 VRF2 over SVIs is running 2 OSPF processes for VRFs. Routing is fine. My issue is as follow: I can't achieve load balancing even I'm trying to setup src-ip, dst-ip etc. cisco describes examples but on CCIE blog guy is saying use same config on each end of etherchannel group otherwise won't work. I've speculated with all possible combination (hope :) but no success. Strange is that I'm using testers dedicated to generate traffic. VRF1 has full 100Mbps duplex VRF2 has follow: SW 1 side tester1 : TX-100Mbps RX-100Mbps SW 2 side tester2 : TX-100Mbps RX-50Mbps Can You please explain me where is 50Mbps? Hope these 50s are not in different VRF. Thanks a lot ___ 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] Etherchannel load balancing
Hi Billy thanks a lot. Can you send me that doc? Link isn't working :-( Regards Ivan On 24 June 2010 14:16, Billy Guthrie wrote: > When you configure an etherchannel bundle, the frames are distributed > across the individual bundled links deterministically; however, the load is > not balanced equally across all the links. You may or may not know, but the > frames are forwarded on a specific link due to the hashing algorithm that is > used. The algorithm can use destination IP address, source IP address, or a > combination of both source and destination IP addresses, source and > destination MAC addresses, or TCP and UDP port numbers. The hashing > algorithm computes a binary pattern that selects a link number in a bundle > to carry each frame. > > Document may or may not help: > > http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtm > > > Good Luck > Billy > > > Ivan Šimko wrote: > >> Hi all >> >> I've got two switches 3560 >> group with 2xFE on both switches and inteconnected together. >> port channel is L2 >> 2 VRFs - ivan, mark >> 4 VLANs: >> - vlan 100 VRF "ivan" for interconnection between swtiches >> - vlan 11 VRF "ivan" for customer's connection >> >> - vlan 200 VRF"mark" for interconnection between switches >> - vlan 12 VRF "mark" for customer's connection >> >> ports 12 and 13 as trunks >> - interconnection between switches >> >> OSPF runs over SVIs of 100 and 200. >> >> I'm strugling with load balancing: >> when I setup port channel load balancing dst-ip switch does correct >> balancing between interconnected vlans but not for customers' vlans. >> - vlan 100 would use port 12 - switch interconnection >> - vlan 200 would use port 13 - switch interconnection >> - vlan 11 would use port 13 - customer 1 >> - vlan 12 would use port 13 - customer 2 >> >> when I setup port channel load balancing src-dst-ip switch does correct >> balance for customers' vlans but not for interconnected vlans. >> - vlan 100 would use port 13 >> - vlan 200 would use port 13 >> - vlan 11 would use port 12 >> - vlan 12 would use port 13 >> >> Result is not full bandwidth used for both customers' traffic resp. only >> 100 >> Mbps. >> >> >> Any ideas how to sort it out? >> >> 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/
[c-nsp] Etherchannel load balancing
Hi all I've got two switches 3560 group with 2xFE on both switches and inteconnected together. port channel is L2 2 VRFs - ivan, mark 4 VLANs: - vlan 100 VRF "ivan" for interconnection between swtiches - vlan 11 VRF "ivan" for customer's connection - vlan 200 VRF"mark" for interconnection between switches - vlan 12 VRF "mark" for customer's connection ports 12 and 13 as trunks - interconnection between switches OSPF runs over SVIs of 100 and 200. I'm strugling with load balancing: when I setup port channel load balancing dst-ip switch does correct balancing between interconnected vlans but not for customers' vlans. - vlan 100 would use port 12 - switch interconnection - vlan 200 would use port 13 - switch interconnection - vlan 11 would use port 13 - customer 1 - vlan 12 would use port 13 - customer 2 when I setup port channel load balancing src-dst-ip switch does correct balance for customers' vlans but not for interconnected vlans. - vlan 100 would use port 13 - vlan 200 would use port 13 - vlan 11 would use port 12 - vlan 12 would use port 13 Result is not full bandwidth used for both customers' traffic resp. only 100 Mbps. Any ideas how to sort it out? 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/
[c-nsp] Etherchannel plus OSPF in GNS3
Hi all I've got question for GNS experienced guys. In my attached topology I have routers with etherchannel groups. Then 2 VRFs light and OSPF over SVI. Purpose of the network is achieve load balancing on port-channels and load balancing over OSPF also. Better understanding is here: Router has got 2 Etherchannel groups Router has got VRF with 2 VLANs One VLAN is memmber of etherchannel group 1 Second VLAN memmber of group 2 Each group consists from 2 ports - I'm using two different links for transmitting and want use them for higher throughput, that is the reason for etherchannel group OSPF for VRF Both VLANs are memmber of same VRF. Interconnections are VLANs /30. Netwrok works pretty nice but only thing what I'm missing are counters on physical FE ports and Port-channels what are still zero. Only ones updated counters are SVIs. OSPF does load balancing based on flow Port channel is set up based on src-dst-ip - how to confirm?? I want prove that portchannel is using both ports in one direction only. Counters should to help me but nothing is incremented. Used devices: 3640 Thanks for comments Ivan ___ 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] mst over etherchannel + QoS
hmmm :-( thanks a lot On 16 June 2010 14:35, Pavel Skovajsa wrote: > Hello Ivan, > > no currently it is not possible to simulate (proper term is actually > emulate) anything else "above" PVST+, as the only switch oriented card > in dynamips is NM-16ESW - which only supports PVST+. > > Due to the proprietary hardware used in switches, I don't think you > will find any other emulator that does this (not speaking about the > fact that AFAIK there is no other cisco emulator then dynamips). > > -pavel > > > On Wed, Jun 16, 2010 at 2:44 PM, Ivan Šimko wrote: > > Hi all > > > > I'd like to ask You if is possible simulate network in GNS for > etherchannel > > with mst and QoS. If not please can You recommned any simulator for? > > > > Thanks a lot > > > > Ivan > > ___ > > 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] mst over etherchannel + QoS
Hi all I'd like to ask You if is possible simulate network in GNS for etherchannel with mst and QoS. If not please can You recommned any simulator for? Thanks a lot Ivan ___ 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] Leaking VRF routes
Hello Dave, Please check and try this link: http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml Maybe it will save you the BGP configuration :) Regards, On Tue, May 18, 2010 at 6:46 AM, Dave Weis wrote: > > Hello > > I am doing VRF lite on a 7200 to place PPPoA/PPPoE users into a VRF. My end > of the PPP link terminates to a loopback in the customer's VRF and assigning > the far end of the PPP link a routable IP address but still inside the VRF. > It's all working well. > > What I want to accomplish it to make that far end routable IP reachable > either from the global table or a separate IP range for traffic graphing and > ping testing. This monitoring segment needs to be able to reach any customer > VRF as well as being globally routable. I am assigning the far end routers > unique routable IP's so there is no overlap. > > We work around this on Ethernet and T1 customers by using a separate > management VLAN or DLCI but we are limited to a single PVC on the DSL side. > > Any advice? > > Thanks > Dave > > > ___ > 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/ > -- Best Regards! Ivan Ivanov ___ 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] ASA 8.3
Hi All, Shortly I will be deploying some new ASAs and came across the 8.3 release. I didn't expect that a minor release would have quite so many fundamental changes. Without looking at the release notes, migration notes (http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html) and various blogs etc on the Internet I would have expected things to be not too different than 8.2 which I have used recently. I would appreciate any feedback from those who have deployed 8.3 as a new install or migration. I will eventually have to decide if it is better to stick with the known 8.2 or the new 8.3 (new features and new bugs) to save the pain of an update later. Ivan ___ 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] Dropping tcp session due to Invalid Flags
All, I've recently migrated my Cisco 2821 routers to 15.1T. It works good except one thing. For some connections I get messages like this: Apr 29 13:29:57 10.0.143.254 11979: rtr02.tu: [sys...@9 s_sn="11979" s_id="rtr02.dc3:514" s_tc="3542767" s_dc="0"]: 011979: Apr 29 14:29:56.363 MDT: %FW-6-DROP_PKT: Dropping tcp session 143.127.138.33:8085 143.127.138.34:179 on zone-pair zp-out-self class cls_permitbpg due to Invalid Flags with ip ident 0 In this 143.127.138.34 is my router and 143.127.138.33 an upstream router and BGP neighbor. In this particular case BGP is up, I should mention. I do see those messages for other connections, too, not related to BGP. I'm running ZBF. Here are the related parts of config. - ... class-map type inspect match-all cls_permitbpg match access-group name acl_permitbgp ... policy-map type inspect pol-permit class type inspect cls_encrypt pass log class type inspect cls_permittoself inspect class type inspect cls_permitbpg inspect class type inspect cls_denytoself pass log class class-default drop log ... zone-pair security zp-out-self source out-zone destination self service-policy type inspect pol-permit ... ip access-list extended acl_permitbgp permit tcp host 143.127.138.33 eq bgp host 143.127.138.34 permit tcp host 143.127.138.33 host 143.127.138.34 eq bgp --- Note about this config: I don't see matches against first rule (odd in case of BGP), I do see matches against second rule and those packets are logged as being dropped (odd!). BGP is up (according to 'show ip bgp'). I have another example with a different set of ports. Any help is appreciated! Thank you! -- Ivan Poddubnyy Sr. Systems Administrator Symantec Corporation / EHG ___ 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] IOS 15.1 and 'inspect' rule (zone-based firewall)
Arie, No, it didn't work as expected. However, I got it working by adding another class-map and modifying existing class-map. Here how it looks now: -- ... parameter-map type inspect audit audit-trail on alert off ... class-map type inspect match-any cls_ip_protocols match protocol icmp match_protocol tcp match protocol udp class-map type inspect match-all cls_10.0.128.0 match access-group name acl_10.0.128.0 match class-map cls_ip_protocols ... policy-map type inspect pol-OutsideToDMZ class type inspect cls_10.0.128.0 inspect audit class class-default drop log ... ip access-list extended acl_10.0.128.0 permit ip 10.0.128.0 0.0.15.255 10.0.80.0 0.0.0.255 ... -- The new class-map fixes it. BTW, what Brian suggested in his reply partially answered the question. I read the document, but there's an example there that has only ACL applied to the policy-map (thus, like in my case, it'll generate "all packets will be dropped" message). I'm talking about the example after this line in the document: "By contrast, a similar configuration that adds application-specific classes provides more granular application statistics and control, and still accommodates the same breadth of services that was shown in the first example by defining the last-chance class-map matching only the ACL as the last chance in the policy-map:" Anyways, the problem seems to be resolved. Thank you! -- Ivan Poddubnyy Sr. Systems Administrator Symantec Corporation / EHG Arie Vayner (avayner) wrote: Ivan, I could find a reference with this information: The reported error message is just seen upon bootup. Reason for this is router loads the config from top to bottom. Therefore, by the time it executes the class-map, it has not read the ACL yet. Therefore giving warning that there's "No specific protocol of access-group configured on the class" Can you confirm that the router works as expected after the complete bootup process? Tnx Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ivan Poddubnyy Sent: Thursday, April 22, 2010 07:30 To: Cisco-nsp Subject: [c-nsp] IOS 15.1 and 'inspect' rule (zone-based firewall) Hi all, I couldn't find explanation to this oddity on TAC, I would appreciate some help. I'm running (migrating to) 15.1 on Cisco 2821 router. The router configured with zone-based firewall. The config has following lines: -- ... parameter-map type inspect audit audit-trail on alert off ... class-map type inspect match-all cls_10.0.128.0 match access-group name acl_10.0.128.0 ... policy-map type inspect pol-OutsideToDMZ class type inspect cls_10.0.128.0 inspect audit class class-default drop log ... ip access-list extended acl_10.0.128.0 permit ip 10.0.128.0 0.0.15.255 10.0.80.0 0.0.0.255 ... -- The way I'm reading it is that class-map is configured with named ACL. Then the class-map is applied to policy-map with action 'inspect'. There's no protocol specified thus all protocols should be inspected (this is what I want). Here is the problem. When router is booting up the following message appears on the console: %No specific protocol or access-group configured in class cls_10.0.128.0 for inspection. All packets will be dropped IMO this is not correct: there's ACL configured in class-map. Before (in 12.4) this message was different -- it was about "no protocols specified, all protocols will be inspected". Has something changed in the way ZBF behaves in 15.x? And is it documented anywhere? I was not able to find the information. Any help is appreciated! Thank you! -- Ivan Poddubnyy Sr. Systems Administrator Symantec Corporation / EHG ___ 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] IOS 15.1 and 'inspect' rule (zone-based firewall)
Hi all, I couldn't find explanation to this oddity on TAC, I would appreciate some help. I'm running (migrating to) 15.1 on Cisco 2821 router. The router configured with zone-based firewall. The config has following lines: -- ... parameter-map type inspect audit audit-trail on alert off ... class-map type inspect match-all cls_10.0.128.0 match access-group name acl_10.0.128.0 ... policy-map type inspect pol-OutsideToDMZ class type inspect cls_10.0.128.0 inspect audit class class-default drop log ... ip access-list extended acl_10.0.128.0 permit ip 10.0.128.0 0.0.15.255 10.0.80.0 0.0.0.255 ... -- The way I'm reading it is that class-map is configured with named ACL. Then the class-map is applied to policy-map with action 'inspect'. There's no protocol specified thus all protocols should be inspected (this is what I want). Here is the problem. When router is booting up the following message appears on the console: %No specific protocol or access-group configured in class cls_10.0.128.0 for inspection. All packets will be dropped IMO this is not correct: there's ACL configured in class-map. Before (in 12.4) this message was different -- it was about "no protocols specified, all protocols will be inspected". Has something changed in the way ZBF behaves in 15.x? And is it documented anywhere? I was not able to find the information. Any help is appreciated! Thank you! -- Ivan Poddubnyy Sr. Systems Administrator Symantec Corporation / EHG ___ 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] Load-sharing with two links to the same ISP
This might help: http://www.nil.com/ipcorner/LoadBalancingBGP/ Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -Original Message- > From: Matthew Melbourne [mailto:m...@melbourne.org.uk] > Sent: Friday, February 05, 2010 12:33 PM > To: cisco-nsp@puck.nether.net > Subject: [c-nsp] Load-sharing with two links to the same ISP > > Hi, > > What techniques are available to load-share traffic on two links (of > equal bandwidth) to the same ISP (same AS) given that BGP only enters > the best path into the RIB? We could announce our prefixes over both > links, but splitting the preferred path announcements over the two > links, either using MED or ISP communities, but this only really > addresses inbound traffic. More of an issue is trying to load-share > outbound traffic; we assume we'll learn the same set of prefixes over > both links from the same ISP - one technique may be to simple split > the IPv4 address space in half and local-pref accordingly to prefer > one link or the other depending on the destination IP prefix? > > Cheers, > > Matt > > -- > Matthew Melbourne ___ 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 VPN Running BGP w/ failover IPSec VPN Over Internet
OK, it looks like I've over-engineered the solution ;)
The best solution (if you can make it work) would be to run BGP over the backup
links and use BGP attributes to make backup links a less desirable BGP path.
Running OSPF on backup links and BGP on MPLS VPN can be made to work ...
barely. I did a workshop once using almost exactly the same network. Each site
was fully redundant with two routers, one connected to Internet, the other one
to MPLS VPN network. I was able to make it work after a lot of tweaking and
two-way redistribution, but I'm not sure anyone in the audience got all the
details ;)
Your situation might be easier as you're using default routing from the central
site, but do try to go for "BGP everywhere".
Ivan Pepelnjak
blog.ioshints.info / www.ioshints.info
> -Original Message-
> From: Jason LeBlanc [mailto:jasonlebl...@gmail.com]
> Sent: Wednesday, January 27, 2010 11:12 PM
> To: Ivan Pepelnjak
> Cc: 'Luan Nguyen'; 'Cisco-nsp'
> Subject: Re: [c-nsp] MPLS VPN Running BGP w/ failover IPSec VPN Over
> Internet
>
> Exactly. This is a secondary form of calling back home if the MPLS Link
> or BGP breaks. We have static routes at the remote site pointing traffic
> over the IPSEC tunnel if it fails. If MPLS is lost we want the remote
> campus to be able to communicate with the main datacenter which is also
> where the main MPLS router exists. We currently have a VPN devices at the
> Datacenter that runs OSPF on the home end.
>
>
>
> MPLS Router 7200---> {AT&T MPLS Cloud} -->
>
> /
> \
> Core 6500 --> Distribution Router 6500 --
> -- Campus Router Cisco or Juniper SSG
>
> \
> /
>
> Site to site VPN Juniper ISG-1000 --> {ISP IPSEC VPN}>
>
>
>
>
> On Jan 27, 2010, at 11:22 AM, Ivan Pepelnjak wrote:
>
> > Jason, are you trying to solve only the remote site problem? Is the main
> campus receiving specific routes for each remote site through the MPLS VPN
> cloud?
> >
> >> -Original Message-
> >> From: Jason LeBlanc [mailto:jasonlebl...@gmail.com]
> >> Sent: Wednesday, January 27, 2010 1:48 AM
> >> To: Luan Nguyen
> >> Cc: 'Cisco-nsp'
> >> Subject: Re: [c-nsp] MPLS VPN Running BGP w/ failover IPSec VPN Over
> >> Internet
> >>
> >> Current topology is pretty simple. AT&T drops an MPLS circuit either
> PPP
> >> Multilink Bundled T1's or an Ethernet hand off. On another interface
> we
> >> generally have an ethernet hand off from another ISP. We run BGP to
> move
> >> all the traffic around on one 172.x.x.x/30's and then our LAN is on
> >> 10.x.x.x. We have an outside IP address on another ethernet port which
> is
> >> the IPSEC termination point. BGP from our main campus injects a
> default
> >> route which we receive. Currently we just manually added static
> 0.0.0.0
> >> routes out the tunnel interfaces with a metric of 32000. So when BGP
> >> drops off we will route over the IPSEC VPN Tunnel back home.
> >>
> >> Headquarters 172.1.1.1/30 --> ATTMPLS 172.1.1.2/30 -->
> >>
> >> ATTMPLS 172.2.2.1/30 --> Remote Campus 172.2.2.2/30 (running BGP) -->
> >> 10.1.1.1/24
> >>
> >> ISP-X Ethernet 200.1.1.1/30 --> Remote Campus 200.1.1.2/30 --> IPSEC
> VPN
> >> Tunnel.1 10.1.1.20/24 --> Headquarters Tunnel.1 10.1.1.21/24
> >>
> >> BGP Provides default route
> >> Static 0.0.0.0 0.0.0.0 Tunel.1 Metric 32000
> >>
> >> It is my assumption that if the traffic cant get to its destination
> >> because BGP has lost it our backup link the IPSEC VPN with the higher
> >> metric will become the new default route.
> >
___
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] ip sla echo vrf with df-bit set?
Just guessing: Local policy routing that sets DF bit on ICMP ECHO traffic between two known IP addresses with the "set ip df 1" command within the route-map. Let me know if it works ;) Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -Original Message- > From: Christopher Hunt [mailto:dharmach...@gmail.com] > Sent: Thursday, January 28, 2010 12:05 AM > To: cisco-nsp@puck.nether.net > Subject: [c-nsp] ip sla echo vrf with df-bit set? > > I'm trying to setup a mechanism for ensuring end-to-end MTU in our L3 MPLS > VPN network. I'd like to use ip sla tracking to do so and I have setup a > monitor: > > ip sla monitor 99 > type echo protocol ipIcmpEcho x.x.x.x > request-data-size 1500 > vrf XYZ > > Unfortunately, I cannot find any way to set the DF bit using "ip sla > monitor". Anyone know if it's available anywhere or coming soon? Can > anyone else think of another strategy? I'm currently running 12.4(22)T on > a > series of 7200VXRs. > > Cheer, > Christopher Hunt ___ 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 VPN Running BGP w/ failover IPSec VPN Over Internet
Gert, If I understood the original question correctly, he's an MPLS VPN customer running BGP with his Service Provider. Unless I'm mistaken, it's somewhat hard to run IGP on top of that, unless you build GRE or DMVPN tunnels over MPLS VPN first. Ivan > This is why I suggested to make this much more simple - treat all links, > IPSEC and MPLS, as "AS internal" links, run an IGP over them, and let > protocols handle end-to-end keepalive and failover that are built to do > this. One can do this with BGP, of course, but it tends to be less > convenient/helpful in these scenarios. > > gert ___ 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 VPN Running BGP w/ failover IPSec VPN Over Internet
* Configure EBGP sessions over IPSec between remote sites and central site. * On remote sites use EEM to detect MPLS VPN EBGP neighbor loss (either default route is gone or you might rely on SNMP traps) * When the MPLS VPN EBGP neighbor is down, enable IPSec tunnel. Only then will the EBGP session be established and you'll get more specific routes over IPSec. This will ensure that the IPSec tunnel on remote sites is operational only when the connectivity with the MPLS VPN cloud is gone and so the central site uses default route into MPLS VPN cloud unless it has a more specific one over IPSec due to failure at one of the remote sites. Note: You might want to use something else to detect MPLS VPN failure, for example IP SLA between remote router and central router. This will detect a failure anywhere in the end-to-end path. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info > -Original Message- > From: Jason LeBlanc [mailto:jasonlebl...@gmail.com] > Sent: Tuesday, January 26, 2010 10:20 PM > To: Cisco-nsp > Subject: [c-nsp] MPLS VPN Running BGP w/ failover IPSec VPN Over Internet > > Team, > > This questions was put out there before in another chain but I wasn't able > to figure out the best solution. We have multiple campuses connecting to > an MPLS VPN cloud running BGP internally. At some locations we have > backup ISP services and an IPSec VPN tunnel over that. Currently BGP > provides a default route to each campus as external BGP / Pref 40 / Metric > 0. Our backup IPSec is in as a Static / Pref 20 / Metric 32000. When we > lose BGP/MPLS VPN we want the IPSec tunnel to begin routing traffic > between the campus and our main datacenter. What is the best way to > achieve this? > > Thanks, > > //LeBlanc > > > ___ 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] CPE with tracking redundancy and long lived (UDP) nat sessions
Just did a few tests with 12.4(24)T. IOS NAT is extra stupid when it comes to
clearing NAT translation table. Even though you have NAT rules tied to an
interface ("ip nat inside ... interface") they are not cleared when the
interface IP address is lost or when the interface is shut down.
So (I guess) the best you can do is to catch changes in tracked object's state
with an EEM applet that clears all NAT translations.
Ivan Pepelnjak
blog.ioshints.info / www.ioshints.info
> So what is the bottom line? Is this the best that can be done with
> simple end site redundancy with object tracking and without dynamic
> routing?
___
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] CPE with tracking redundancy and long lived (UDP) nat sessions
> The problem is that the session stays active. I want the session to be > lost. I believe the rules should be adhered to a bit more strictly. The session DOES NOT stay active. The phone is stupid. It should have realized there's no reply and restart the session. > If the current matching nat statement would result in a different value > for the inside global address, than a new translation should be called > for. > > It isnt actually all that hard to check for, conceptually. And then you'd complain about the CPU load. What do you think is cheaper: checking the NAT table or NAT rules (including route maps) for every packet? > (What would you expect to happen when the DHCP client address changes on > the egress interface? Or if you change the ip address on an interface > referenced by the ip nat statement?) You'd lose all sessions, obviously. What else would you expect? > Apparently, the end stations dont change the source port for new > attempts. Proves my point. The phone is stupid ;) There's a reason every new client session should use a new dynamic port number. > This behavior has very disruptive end user symptoms. Many stupid implementations have disruptive end-user symptoms. Microsoft Network Load Balancing with unknown unicast MAC addresses immediately comes to mind ;) Ivan Pepelnjak blog.ioshints.info / www.ioshints.info ___ 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] CPE with tracking redundancy and long lived (UDP) nat sessions
> After the routing and egress changes, the router should be well aware > that continued traffic no longer matches the > > ip nat inside source route-map ISPA Di1 overload > > and now matches the > > ip nat inside source route-map ISPB Di2 overload > > for a simplistic example. > > So the old translations are no longer valid with the new egress. They > should be abandoned and new ones created. Obviously the router does NOT check the "ip nat" rules if it gets a match in the NAT translation table. This behavior makes sense; if you'd change the NAT parameters of a live session, you'd lose the session anyway. > And I would be quite happy clearing just the translations for the > "wrong" global for all local inside translations, but syntax does not > seem to allow that. Write a Tcl script that does "show ip nat translations" and kills only the relevant ones ;) Ivan Pepelnjak blog.ioshints.info / www.ioshints.info ___ 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/
