Re: [c-nsp] Monitoring tools for MPLS VPN customers
You definitely want a Management vrf that you leak into all your customer vrf's, from this you can use something like nagios or whatever your tool of choice is to alert to downed nodes, just remember not to overlap your CPE IP addressing even though they are in separate vrf's. As far as voip monitoring goes you can use ip sla on your routers to monitor jitter/loss/delay etc.. Check out - http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white _paper0900aecd8017531d.html and http://www.cisco.com/en/US/technologies/tk648/tk362/tk920/technologies_white _paper0900aecd801752ec.html For ideas on what ip sla can do for you, there are plenty of configuration examples around to look at too. Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Saykao Sent: Friday, 31 October 2008 4:25 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Monitoring tools for MPLS VPN customers Hi All, We have some MPLS VPN customers waiting to come on board and have asked us about what sort of monitoring we can provide for all their sites. By monitoring I can only guess that the customer is asking us to identify when a VPN site goes down. Other desirable features might be to implement some SLA to monitor latency and round trip time for those customer's who rely heavily on VoIP. Ideally, the IT person for the organization should be doing most of this monitoring, but Management have asked me to investigate what we sort of monitring we can provide to the customer to help bring them on baord. We are currently using Cisco's MPLS Diagnostics Expert but this doesn't seem to have any proactive monitoring tool via it's SLA feature. We could set up a management station within a management VRF and run some monitoring software on it which is another option. Just curious to know what software Service Providers are using to proactively monitor their VPN customers. Thanks. Andy This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organisation. Finally, the recipient should check this email and any attachments for the presence of viruses. The organisation accepts no liability for any damage caused by any virus transmitted by this email. ___ 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] Giants and mtu-size
Hi Folks. Could someone give a hint at what I need to look at. I've got several tag-switching interfaces that got giant in the counters. We are using jumbo ( mtu 9216 ) frames on Gigabit Ethernet interfaces and the mtu for mpls ip is 1546. Negotiation is off on all interfaces. I know that giants is packets that are discarded because they exceed the medium's maximum packet size. But how can I verify the right mtu size. /Arne ___ 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] EARL_L2_ASIC-SP-4-DBUS_HDR_ERR
Hi, Any idea if this is a bad thing? We've seen it three times on a 7600 just just upgraded from SUP720 to RSP720. Judging by the replies, it sounds like it's a good idea to have TAC take a look at it and tell us if we need to RMA it. Thanks, -- Regards Christian Bering ___ 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] Giants and mtu-size
On Fri, 31 Oct 2008, Arne Larsen / Region Nordjylland wrote: I know that giants is packets that are discarded because they exceed the medium's maximum packet size. But how can I verify the right mtu size. Please share MTU-related config from both ends and we'll be able to help. Short story: Set MTU to whatever you want the highest MTU to be (normally what you want MPLS to use). Set clns mtu (if you're running ISIS) and ip mtu if other end needs it. So, for instance if you're running a LAN with mixed MPLS enabled devices and some not, and some only supports 1500 ip mtu: int gi1/0 mtu 1546 ip mtu 1500 clns mtu 1497 ipv6 mtu 1500 As far as I have been able to discern from the cisco docs (and after being pointed out to me actually on this list), the only time mpls mtu (tag-switching mtu) should be used is on old 7200 FE based ports. There are platforms with cosmetics bugs where all jumbos are counted as giants in interface counters, you might want to check the bug database. -- Mikael Abrahamsson email: [EMAIL PROTECTED] ___ 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] Lightstream Alternative
-Ursprüngliche Nachricht- Von: Mateusz B?aszczyk [mailto:[EMAIL PROTECTED] I am not sure but it seems to me that some fancy SPA card in c7600 would do the local switching, wouldn't it? I'm not sure. In the end-of-live announcement for the lightstream I've found, that cat 4500 and cat 6500 should be able to take over for the lightstream. But I can't find anything at cisco, which assures that can configure everything on the cat 6500, which I've configured on my lightstream. If the SPA card for the 7600 could do the switching, the cat 6500 should also be able to do it. But even for the 7600 I can't find any information on atm switching. I just need to switch pvc from one OC3/STM-1 to another and configure soft-vc's. Sebastian ___ 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] Giants and mtu-size
Hi Mikael Here are two interface config that peers. interface GigabitEthernet1/15 description B: Uplink to MPLS aasnxc2 gi5/1 mtu 9216 ip address x ip router isis load-interval 30 tag-switching mtu 1546 tag-switching ip interface GigabitEthernet5/1 description B: Uplink to MPLS aasnxt1 gi1/15 mtu 9216 ip address x ip router isis load-interval 30 tag-switching mtu 1546 tag-switching ip /Arne -Oprindelig meddelelse- Fra: Mikael Abrahamsson [mailto:[EMAIL PROTECTED] Sendt: 31. oktober 2008 08:01 Til: Arne Larsen / Region Nordjylland Cc: cisco-nsp@puck.nether.net Emne: Re: [c-nsp] Giants and mtu-size On Fri, 31 Oct 2008, Arne Larsen / Region Nordjylland wrote: I know that giants is packets that are discarded because they exceed the medium's maximum packet size. But how can I verify the right mtu size. Please share MTU-related config from both ends and we'll be able to help. Short story: Set MTU to whatever you want the highest MTU to be (normally what you want MPLS to use). Set clns mtu (if you're running ISIS) and ip mtu if other end needs it. So, for instance if you're running a LAN with mixed MPLS enabled devices and some not, and some only supports 1500 ip mtu: int gi1/0 mtu 1546 ip mtu 1500 clns mtu 1497 ipv6 mtu 1500 As far as I have been able to discern from the cisco docs (and after being pointed out to me actually on this list), the only time mpls mtu (tag-switching mtu) should be used is on old 7200 FE based ports. There are platforms with cosmetics bugs where all jumbos are counted as giants in interface counters, you might want to check the bug database. -- Mikael Abrahamsson email: [EMAIL PROTECTED] ___ 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] RS232 to TCP/IP
Hi, We have been using MOXA NPort servers to communicate to serial devices over TCP/IP. For more information refer to the specifications and applications at MOXA site. I remember the document has plenty of examples. Cheers, Venu ___ 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] 10G 6704 and 6708
vince anton wrote: Hi, im looking at 10G cards for 7600 with SUP720-3BXL (running SXF) and wanted an opinion from the list Both seem to work fine in our 6500s using SXF10 (caveat - we're using -3B/3C, not XL) The QoS queueing model is different between 6704 and 6708. This had the practical outcome in our case of preventing a port channel with on port on a 6704 and one on a 6708. 6708s do not support VACL capture, which we are using (so a 6704 had to stay in the box to run the ports we want to capture). 6708 are unsupported in 6503 or 7603 chassis. ___ 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] Restricting VLANs on 802.1q Tunnel Port
On Thu, Oct 30, 2008 at 10:47, FAHAD ALI KHAN [EMAIL PROTECTED] wrote: Consider a scenario, if im using 802.1q tunnel service to carry customer VLANs and want to allow only 10, 11 12 VLANs from CE (by restricting it on UPE port). Is this possible on ME3400 with Merto Access IOS? Is there any workarround available? Not on the classic ME3400. You need hardware that can do Selective Q-in-Q (the EVC-framework), like ME3400E or 7600 with ES20 (could be others as well). -- Pelle ___ 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] hierarchical MPLS VPN
Hi All i have a small question about the set up of hierarchical MPLS VPN (carrier-of-carriers VPN) , the customer carrier will establish MP-iBGP sessions between its PEs directly to exchange VPNv4 routes and all LDP or BGP between customer carrier CE and backbone provider PE to exchange IPv4 routes and labels my question is , i believe there will be some command needed at backbone provide PE to enable carrier-of-carriers support and allow PE to tag incoming labeled packets with double-label based on 2 lookups , lookup for incoming label and lookup for NH network in Juniper , this feature is supported by *mpls topology-driven-lsp *command , what about Cisco IOS ? ** ** best regards --Ibrahim Abo Zaid ___ 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 and Calea Feature Set
Not sure about the Cisco approach to this, but I am doing almost the same thing, with the exception that we SPAN from the point of customer entry into our network, which in this case is a switch, so all traffic can be captured. We are using the OpenCALEA standard: http://www.opencalea.org/ Good luck elucidating the Cisco options ... interested to know what people have to say about it Thanks, Adam - Original Message - From: Frank Bulk [EMAIL PROTECTED] To: 'Forrest W Christian' [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Sent: Thursday, October 30, 2008 11:30 PM Subject: Re: [c-nsp] IOS and Calea Feature Set You may want to check out this project: http://www.openintercept.org/ I have a contact involved with this, if you need it. Regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Forrest W Christian Sent: Thursday, October 30, 2008 1:11 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] IOS and Calea Feature Set I'm working on improving my CALEA compliance here. One of the big things I need to handle is better extraction of frames out of several cisco routers we have scattered around our network. Today, we handle our CALEA requests by using a span/mirroring port on a switch plugged into a CALEA collection device which conforms to the WISPA CALEA standard. That way, we can capture all of the internet and most of the on-network traffic, but not quite 100% since traffic which never leaves the border router doesn't ever exit the border router so it can't be captured for Law Enforcement. It looks like the IP Traffic Export would allow me to basically use the tools we already have in place for this. But, I also am looking at the CALEA features in the later IOS'es. Unfortunately, the documentation is written in CALEA-speak, which makes for confusing reading, especially when you are trying to figure out what pieces you need to make this work. I'm curious if someone on-list has gotten the CALEA features to work in a Broadband provider setting, and if so, if they could perhaps point me in the right direction as far as what pieces we need (aka specific products instead of functions) other than the Cisco router w/CALEA features? -forrest ___ 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 and Calea Feature Set
Forrest, I'm not an expert in this area but... my understanding is Lawful Intercept (search Cisco.com for lawful intercept) is supposed to be the target solution for what you describe. Rodney On Thu, Oct 30, 2008 at 12:10:40PM -0600, Forrest W Christian wrote: I'm working on improving my CALEA compliance here. One of the big things I need to handle is better extraction of frames out of several cisco routers we have scattered around our network. Today, we handle our CALEA requests by using a span/mirroring port on a switch plugged into a CALEA collection device which conforms to the WISPA CALEA standard. That way, we can capture all of the internet and most of the on-network traffic, but not quite 100% since traffic which never leaves the border router doesn't ever exit the border router so it can't be captured for Law Enforcement. It looks like the IP Traffic Export would allow me to basically use the tools we already have in place for this. But, I also am looking at the CALEA features in the later IOS'es. Unfortunately, the documentation is written in CALEA-speak, which makes for confusing reading, especially when you are trying to figure out what pieces you need to make this work. I'm curious if someone on-list has gotten the CALEA features to work in a Broadband provider setting, and if so, if they could perhaps point me in the right direction as far as what pieces we need (aka specific products instead of functions) other than the Cisco router w/CALEA features? -forrest ___ 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] hierarchical MPLS VPN
Ibrahim Abo Zaid wrote: Hi All i have a small question about the set up of hierarchical MPLS VPN (carrier-of-carriers VPN) , the customer carrier will establish MP-iBGP sessions between its PEs directly to exchange VPNv4 routes and all LDP or BGP between customer carrier CE and backbone provider PE to exchange IPv4 routes and labels my question is , i believe there will be some command needed at backbone provide PE to enable carrier-of-carriers support and allow PE to tag incoming labeled packets with double-label based on 2 lookups , lookup for incoming label and lookup for NH network well, there is no specific enable CsC command, it's only the presence of LDP or eBGP+label on the PE-CE VRF interface which tells the PE to populate the LFIB and to label-switch packets.. oli ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Multiple RTR trackers
Hi there.. I'm trying to get multiple RTR trackers running on a 7206VXR-NPE2G: track 1 rtr 1 reachability ! track 2 rtr 2 reachability ip sla 1 icmp-echo xxx.xxx.xxx.116 timeout 3000 ip sla schedule 1 life forever start-time now ip sla 2 icmp-echo xxx.xxx.xxx.198 timeout 3000 ip sla schedule 2 life forever start-time now The first one works great: Oct 22 07:04:30: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up Oct 26 19:29:33: %TRACKING-5-STATE: 1 rtr 1 reachability Up-Down Oct 26 19:30:34: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up Oct 28 16:54:38: %TRACKING-5-STATE: 1 rtr 1 reachability Up-Down Oct 28 16:55:34: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up The second one doesn't work at all can't figure out if I'm missing something obvious ;) What I'm using this for is to setup static routes based on reachability ... long story as to why.. ip route xxx.xxx.xxx.0 255.255.255.240 xxx.xxx.xxx.116 track 1 Any clues? Thanks, Paul ___ 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] CSC unable to ping PE address
I have a basic CSC topology and am having inconsistent problems on both 12.2(25)S9 and also on S15 Below is a snip of the configs from both boxes. The issue is on the CE if I try to ping the PE 150.1.12.2 it does not work. You can see the CE is tagging a label of 20 on the packet but it is not been seen in the CE forwarding table. Also on the PE has no label twenty installed If I clear the ldp neighbor while the neighbor is down I can ping from CE to neighbor so it is not a basic L2 issue. Any ideas ? =CE= interface Serial2/2 ip address 150.1.12.1 255.255.255.0 mpls ip serial restart-delay 0 no clns route-cache end Rack1R1# 1d21h: ldp: Scan listening TCBs Rack1R1#show ip route 150.1.12.2 Routing entry for 150.1.12.0/24 Known via connected, distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Serial2/2 Route metric is 0, traffic share count is 1 Rack1R1#show ip cef 150.1.12.2 150.1.12.0/24 attached to Serial2/2 label 20 Rack1R1# Rack1R1#show mpls for Local Outgoing PrefixBytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 16 Pop Label 150.1.3.3/32 208868Se2/1 point2point 18 23150.1.56.0/24 0 Se2/2 point2point 19 24150.1.45.0/24 0 Se2/2 point2point 20 25150.1.6.6/32 67Se2/2 point2point 21 26150.1.5.5/32 0 Se2/2 point2point 22 22150.1.222.222/32 0 Se2/2 point2point Rack1R1# =CSC PE Current configuration : 141 bytes ! interface Serial2/2 ip vrf forwarding csc ip address 150.1.12.2 255.255.255.0 mpls ip serial restart-delay 0 no clns route-cache end Rack1R2#show mpls for vrf csc Local Outgoing PrefixBytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface 18 No Label 150.1.1.1/32[V] 0 Se2/2 point2point 19 No Label 150.1.3.3/32[V] 331 Se2/2 point2point 20 Pop Label 150.1.12.0/24[V] 687164Se2/2 point2point 21 No Label 150.1.13.0/24[V] 0 Se2/2 point2point 22 Aggregate 150.1.222.222/32[V] \ 0 csc 23 25150.1.56.0/24[V] 0 Fa0/0 150.1.24.4 24 24150.1.45.0/24[V] 0 Fa0/0 150.1.24.4 25 23150.1.6.6/32[V] 235922Fa0/0 150.1.24.4 26 22150.1.5.5/32[V] 0 Fa0/0 150.1.24.4 Rack1R2# Rack1R2#sho ip cef vrf csc 150.1.12.1 150.1.12.0/24 attached to Serial2/2 Rack1R2#sho ip cef vrf csc 150.1.12.2 150.1.12.2/32 receive ___ 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] 10G 6704 and 6708
You can disable that check with no mls qos channel-consistency. Tim At 02:48 AM 10/31/2008, Phil Mayers observed: The QoS queueing model is different between 6704 and 6708. This had the practical outcome in our case of preventing a port channel with on port on a 6704 and one on a 6708. Tim Stevenson, [EMAIL PROTECTED] Routing Switching CCIE #5561 Technical Marketing Engineer, Data Center BU Cisco Systems, http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] Order-of-operations question about adjust-mss and crypto...
If you apply the ip tcp adjust-mss command on an interface that has a crypto statement on it... Does it perform the MSS adjustment on outbound packets before they are encrypted? Does it perform the MSS adjustment on inbound packets after they are decrypted? I know that this is typically placed on a tunnel interface or, for instance, on an ethernet interface of a remote VPN site or something... but I have a case where we have many GET encryped sub-interfaces (each in their own VRF) which are the only logical IP interfaces on the box. The backside is MPLS so there is no place to put the statement there... so I was just going to apply it to the interfaces where the crypto maps are.. not sure if this will work. I'll probably have to lab it up I'm guessing. Derick ___ 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] CSC unable to ping PE address
kevin gannon wrote: I have a basic CSC topology and am having inconsistent problems on both 12.2(25)S9 and also on S15 Below is a snip of the configs from both boxes. The issue is on the CE if I try to ping the PE 150.1.12.2 it does not work. You can see the CE is tagging a label of 20 on the packet but it is not been seen in the CE forwarding table. Also on the PE has no label twenty installed [...] Rack1R2#show mpls for vrf csc Local Outgoing PrefixBytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface ? 20 Pop Label 150.1.12.0/24[V] 687164Se2/2 The PE has label 20 installed, however it didn't store this as an aggregate label (to trigger another lookup), which is wrong. This looks like a bug, but can't dig into this further right now (sorry, need to run).. you might want to contact TAC. oli ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ME Switch Managment over Trunk Interfaces?
I'm new to Cisco ME switches, so please bare with my basic question. I am having a difficult time trying to manage the device over trunk interface. It doesn't work. My management IP lives on a vlan interface. Below is my configuration. I tried vlan1 without luck too. Do I really have to burn a port for management? I'm probably missing something simple. Any assistance is appreciated. Thanks, Chip vlan 100-106 interface GigabitEthernet0/1 port-type nni switchport trunk native vlan 106 switchport trunk allowed vlan 100-106 switchport mode trunk interface Vlan106 ip address 10.24.100.2 255.255.255.252 ___ 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] 10G 6704 and 6708
Tim Stevenson wrote: You can disable that check with no mls qos channel-consistency. That's very useful to know. Does it have any adverse effect or unwelcome implications? ___ 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] 10G 6704 and 6708
Clearly each port in the channel may treat the same traffic differently, depending on how you configure the queuing for those port types. If you are not using qos, then there should be no functional difference. Tim At 10:48 AM 10/31/2008, Phil Mayers observed: Tim Stevenson wrote: You can disable that check with no mls qos channel-consistency. That's very useful to know. Does it have any adverse effect or unwelcome implications? Tim Stevenson, [EMAIL PROTECTED] Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco Systems, http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] Order-of-operations question about adjust-mss and crypto...
The MSS tells the maximum data a host will accept in an TCP/IP datagram. Each side reports the value to the other side and the sending will abide by it. It's all before encryption. So typically like you said, people put ip tcp adjust-mss 1360 on the group member LAN interface and also set ip mtu 1400 on the WAN side hoping for PMTUD to work its magic. Putting both on the WAN interface should work as well, though, I don't quite understand the backside is MPLS statement :)...the packet has to be originated from somewhere. There's a very good paper here on Fragmentation http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00 800d6979.shtml#t3 Luan Nguyen Chesapeake NetCraftsmen, LLC. www.NetCraftsmen.net (blog) http://ccie-security.blogspot.com/ (e) [EMAIL PROTECTED] (aim/yahoo): luancnc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derick Winkworth Sent: Friday, October 31, 2008 11:52 AM To: Rodney Dunn Cc: cisco-nsp@puck.nether.net Subject: [c-nsp] Order-of-operations question about adjust-mss and crypto... If you apply the ip tcp adjust-mss command on an interface that has a crypto statement on it... Does it perform the MSS adjustment on outbound packets before they are encrypted? Does it perform the MSS adjustment on inbound packets after they are decrypted? I know that this is typically placed on a tunnel interface or, for instance, on an ethernet interface of a remote VPN site or something... but I have a case where we have many GET encryped sub-interfaces (each in their own VRF) which are the only logical IP interfaces on the box. The backside is MPLS so there is no place to put the statement there... so I was just going to apply it to the interfaces where the crypto maps are.. not sure if this will work. I'll probably have to lab it up I'm guessing. Derick ___ 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] ME Switch Managment over Trunk Interfaces?
On Fri, Oct 31, 2008 at 17:06, cp [EMAIL PROTECTED] wrote: I'm new to Cisco ME switches, so please bare with my basic question. I am having a difficult time trying to manage the device over trunk interface. It doesn't work. My management IP lives on a vlan interface. Below is my configuration. I tried vlan1 without luck too. Do I really have to burn a port for management? I'm probably missing something simple. Any assistance is appreciated. Could you be a little bit more specific as to what exactly does not work? Some questions: * Did you create VLAN 106? * Did you enable Vlan interface (no shut)? * Do you have a route back to your management station? * Is the device on the other end configured to accept tagged frames? -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.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/
[c-nsp] VRF question
Hi all, Not sure if this is possible, but in an ME3400, can you create a route in the global configuration with a next hop in a VRF? Thanks, evt ___ 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 and Calea Feature Set
The Lawful Intercept feature uses SNMP V3 and MIBs like ciscoIpTapMIB and ciscoTap2MIB. You setup a group and a view including these mibs and intiate the intercept from your mediation/sniffer device. It can be tricky if you are doing PPP, because you specify the IP to tap. Your configuration could include setting up a AAA group and allowing the mediation device to receive accounting records to determine end-user IP addresses. The median device needs to be able to act as a RADIUS server so it isn't marked Dead by the AAA processes in the router. Dan - Original Message - From: Forrest W Christian [EMAIL PROTECTED] To: cisco-nsp@puck.nether.net Sent: Thursday, October 30, 2008 2:10 PM Subject: [c-nsp] IOS and Calea Feature Set I'm working on improving my CALEA compliance here. One of the big things I need to handle is better extraction of frames out of several cisco routers we have scattered around our network. Today, we handle our CALEA requests by using a span/mirroring port on a switch plugged into a CALEA collection device which conforms to the WISPA CALEA standard. That way, we can capture all of the internet and most of the on-network traffic, but not quite 100% since traffic which never leaves the border router doesn't ever exit the border router so it can't be captured for Law Enforcement. It looks like the IP Traffic Export would allow me to basically use the tools we already have in place for this. But, I also am looking at the CALEA features in the later IOS'es. Unfortunately, the documentation is written in CALEA-speak, which makes for confusing reading, especially when you are trying to figure out what pieces you need to make this work. I'm curious if someone on-list has gotten the CALEA features to work in a Broadband provider setting, and if so, if they could perhaps point me in the right direction as far as what pieces we need (aka specific products instead of functions) other than the Cisco router w/CALEA features? -forrest ___ 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] Multiple RTR trackers
Paul, Did you try attaching the track 2 policy to a static route? Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Friday, October 31, 2008 17:38 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Multiple RTR trackers Hi there.. I'm trying to get multiple RTR trackers running on a 7206VXR-NPE2G: track 1 rtr 1 reachability ! track 2 rtr 2 reachability ip sla 1 icmp-echo xxx.xxx.xxx.116 timeout 3000 ip sla schedule 1 life forever start-time now ip sla 2 icmp-echo xxx.xxx.xxx.198 timeout 3000 ip sla schedule 2 life forever start-time now The first one works great: Oct 22 07:04:30: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up Oct 26 19:29:33: %TRACKING-5-STATE: 1 rtr 1 reachability Up-Down Oct 26 19:30:34: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up Oct 28 16:54:38: %TRACKING-5-STATE: 1 rtr 1 reachability Up-Down Oct 28 16:55:34: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up The second one doesn't work at all can't figure out if I'm missing something obvious ;) What I'm using this for is to setup static routes based on reachability ... long story as to why.. ip route xxx.xxx.xxx.0 255.255.255.240 xxx.xxx.xxx.116 track 1 Any clues? Thanks, Paul ___ 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] ME Switch Managment over Trunk Interfaces?
Thanks for replying. I'm trying to pass any(icmp at the moment) traffic from a vlan interface through the trunk port via /30. It's a /30 so no return route needed. Yes, I created vlan 106. Yes I shut / no shut vlan106 interface. Yes, the device on the other side accepts tagged frames. Other traffic such as non vlan interface traffic passes fine. There isn't an arp or mac-address table entry for the remote IP of the /30, which leaves me to believe traffic is being block by ME's overall uni/eni/nni port-type design. Anyone else have a similar experience? When I switch the port from trunk to access mode and only test the vlan 106 it works fine. -Chip . -Original Message- From: Marko Milivojevic [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2008 2:40 PM To: cp Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ME Switch Managment over Trunk Interfaces? On Fri, Oct 31, 2008 at 17:06, cp [EMAIL PROTECTED] wrote: I'm new to Cisco ME switches, so please bare with my basic question. I am having a difficult time trying to manage the device over trunk interface. It doesn't work. My management IP lives on a vlan interface. Below is my configuration. I tried vlan1 without luck too. Do I really have to burn a port for management? I'm probably missing something simple. Any assistance is appreciated. Could you be a little bit more specific as to what exactly does not work? Some questions: * Did you create VLAN 106? * Did you enable Vlan interface (no shut)? * Do you have a route back to your management station? * Is the device on the other end configured to accept tagged frames? -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.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] ME Switch Managment over Trunk Interfaces?
On the other device, do you have a native vlan configured? What device is it? On Fri, Oct 31, 2008 at 19:16, cp [EMAIL PROTECTED] wrote: Thanks for replying. I'm trying to pass any(icmp at the moment) traffic from a vlan interface through the trunk port via /30. It's a /30 so no return route needed. Yes, I created vlan 106. Yes I shut / no shut vlan106 interface. Yes, the device on the other side accepts tagged frames. Other traffic such as non vlan interface traffic passes fine. There isn't an arp or mac-address table entry for the remote IP of the /30, which leaves me to believe traffic is being block by ME's overall uni/eni/nni port-type design. Anyone else have a similar experience? When I switch the port from trunk to access mode and only test the vlan 106 it works fine. -Chip . -Original Message- From: Marko Milivojevic [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2008 2:40 PM To: cp Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ME Switch Managment over Trunk Interfaces? On Fri, Oct 31, 2008 at 17:06, cp [EMAIL PROTECTED] wrote: I'm new to Cisco ME switches, so please bare with my basic question. I am having a difficult time trying to manage the device over trunk interface. It doesn't work. My management IP lives on a vlan interface. Below is my configuration. I tried vlan1 without luck too. Do I really have to burn a port for management? I'm probably missing something simple. Any assistance is appreciated. Could you be a little bit more specific as to what exactly does not work? Some questions: * Did you create VLAN 106? * Did you enable Vlan interface (no shut)? * Do you have a route back to your management station? * Is the device on the other end configured to accept tagged frames? -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.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/ ___ 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] Multiple RTR trackers
Thanks very much Well.. umm.. yes, I did it on the static route and it didn't work - but (feeling kinda silly) I did realize that track 2 rtr 2 reachability was missing from the actual config :0 Funny how it works just fine now Ooops... thanks for the reply... going to crawl under a rock now...;) Paul -Original Message- From: Arie Vayner (avayner) [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2008 3:16 PM To: Paul Stewart; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Multiple RTR trackers Paul, Did you try attaching the track 2 policy to a static route? Arie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Stewart Sent: Friday, October 31, 2008 17:38 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Multiple RTR trackers Hi there.. I'm trying to get multiple RTR trackers running on a 7206VXR-NPE2G: track 1 rtr 1 reachability ! track 2 rtr 2 reachability ip sla 1 icmp-echo xxx.xxx.xxx.116 timeout 3000 ip sla schedule 1 life forever start-time now ip sla 2 icmp-echo xxx.xxx.xxx.198 timeout 3000 ip sla schedule 2 life forever start-time now The first one works great: Oct 22 07:04:30: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up Oct 26 19:29:33: %TRACKING-5-STATE: 1 rtr 1 reachability Up-Down Oct 26 19:30:34: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up Oct 28 16:54:38: %TRACKING-5-STATE: 1 rtr 1 reachability Up-Down Oct 28 16:55:34: %TRACKING-5-STATE: 1 rtr 1 reachability Down-Up The second one doesn't work at all can't figure out if I'm missing something obvious ;) What I'm using this for is to setup static routes based on reachability ... long story as to why.. ip route xxx.xxx.xxx.0 255.255.255.240 xxx.xxx.xxx.116 track 1 Any clues? Thanks, Paul ___ 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] ME Switch Managment over Trunk Interfaces?
It's a juniper router. -Original Message- From: Marko Milivojevic [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2008 3:32 PM To: cp Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ME Switch Managment over Trunk Interfaces? On the other device, do you have a native vlan configured? What device is it? On Fri, Oct 31, 2008 at 19:16, cp [EMAIL PROTECTED] wrote: Thanks for replying. I'm trying to pass any(icmp at the moment) traffic from a vlan interface through the trunk port via /30. It's a /30 so no return route needed. Yes, I created vlan 106. Yes I shut / no shut vlan106 interface. Yes, the device on the other side accepts tagged frames. Other traffic such as non vlan interface traffic passes fine. There isn't an arp or mac-address table entry for the remote IP of the /30, which leaves me to believe traffic is being block by ME's overall uni/eni/nni port-type design. Anyone else have a similar experience? When I switch the port from trunk to access mode and only test the vlan 106 it works fine. -Chip . -Original Message- From: Marko Milivojevic [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2008 2:40 PM To: cp Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ME Switch Managment over Trunk Interfaces? On Fri, Oct 31, 2008 at 17:06, cp [EMAIL PROTECTED] wrote: I'm new to Cisco ME switches, so please bare with my basic question. I am having a difficult time trying to manage the device over trunk interface. It doesn't work. My management IP lives on a vlan interface. Below is my configuration. I tried vlan1 without luck too. Do I really have to burn a port for management? I'm probably missing something simple. Any assistance is appreciated. Could you be a little bit more specific as to what exactly does not work? Some questions: * Did you create VLAN 106? * Did you enable Vlan interface (no shut)? * Do you have a route back to your management station? * Is the device on the other end configured to accept tagged frames? -- Marko CCIE #18427 (SP) My network blog: http://cisco.markom.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/ ___ 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] Lightstream Alternative
2008/10/31 Sebastian Ganschow [EMAIL PROTECTED]: -Ursprüngliche Nachricht- Von: Mateusz B?aszczyk [mailto:[EMAIL PROTECTED] I am not sure but it seems to me that some fancy SPA card in c7600 would do the local switching, wouldn't it? I'm not sure. what i meant by this was mpls xconnect between atm ports... but I can't find anything about it on cisco... -- -mat ___ 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-nsp] Whats up with this?
Seems weird to me that they're counting down to veterans / remembrance day, I would hope the marketing dept considered that, but maybe not... ___ 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-nsp] Whats up with this?
I'm sure the only thing that Cisco Marketing considered as far as veterans day was concerned is whether they have it off or not and that's probably even a stretch.;) - Original Message - From: Simon Hamilton-Wilkes [EMAIL PROTECTED] To: cisco-nsp@puck.nether.net Sent: Friday, October 31, 2008 3:54 PM Subject: Re: [c-nsp] [cisco-nsp] Whats up with this? Seems weird to me that they're counting down to veterans / remembrance day, I would hope the marketing dept considered that, but maybe not... ___ 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] Whats up with this?
Looks like they've built a transporter. Most likely using the IETF protocol MoIP. Matter over IP. Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Louis Sent: Friday, October 31, 2008 6:04 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Whats up with this? http://www.cisco.com/cdc_content_elements/flash/netsol/sp/getready/index .html?POSITION=bannerCOUNTRY_SITE=usCAMPAIGN=GetReadyCREATIVE=Corner+ Banner+Ad+go/getreadyREFERRING_SITE=CISCO%2ECOM+INDEX Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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] OSPF fast hellos
And beware the showstopper in 12.2S and 12.4T where BFD causes an NMI reset. Doh! It haunted me for many moons before my stubborness prevailed. And a sharp Escalations Engineer at Cisco sleuthed it out and eventually generated bug ID CSCek75694 with a fix that is supposed to wind back into the mainline trains by EOY. ../C Yesterday Frank Bulk said: If you can get BFD support worked into the 3750ME, we wouldn't have to mess with OSPF fast hellos. =) Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodney Dunn Sent: Thursday, October 30, 2008 12:30 PM To: Ben Steele Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF fast hellos On Thu, Oct 30, 2008 at 08:06:36AM +1030, Ben Steele wrote: Because I couldn't see bfd support for 3750's, best it can do is UDLD, otherwise that would be my preferred method. Are you advising against fast hello's? No totally. Have you seen many issues with people using them? Yes. They have to be scheduled on the CPU as a process and that is more variable because IOS is run to completion, except for psuedo preemption added for BFD. Even that isn't 100% bullet proof but it's better than OSPF fast hellos from that perspective. -Original Message- From: Rodney Dunn [mailto:[EMAIL PROTECTED] Sent: Wednesday, 29 October 2008 11:41 PM To: Ben Steele Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF fast hellos Why don't you use BFD instead. It's designed with something called pseudo preemption from an OS scheduler perspective that helps reduce false positives and the fact that BFD frames are handled under interrupt and not process scheduled for rx/tx. Rodney On Wed, Oct 29, 2008 at 04:09:45PM +1030, Ben Steele wrote: Anyone currently using this in a fairly demanding environment? Ie 5-10Gbs+ Campus/DC model. Curious as to whether you've had any/many false dead peers with such a short interval, subsecond dead peer detection does sound very temping though. Cheers Ben ___ 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/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.4/1752 - Release Date: 28/10/2008 10:04 AM ___ 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/
