Re: [c-nsp] H-VPLS/P2MP style functionality with L2TPv3 inside VFI
James, I would look at something like the ASR1K for the head end if you want to L2TPv3. Tnx Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of James Bensley Sent: Thursday, October 2, 2014 07:28 To: cisco-nsp@puck.nether.net Subject: [c-nsp] H-VPLS/P2MP style functionality with L2TPv3 inside VFI Hi All, For reasons way beyond the scope of this mailing list (crazy sales people, insane customers, ridiculous marketing, promises of gold, the usual techies nightmare) I'm trying to lab up a hub and spoke L2 VPN scenario using L2TPv3. CPEs are ISR G2s such as 1941 and the PE/Hub is an ME3600. I'm not having much luck so I wondered if I'm chasing a ghost; Has anyone used L2TPv3 xconnects (due to lack of MPLS) into a VFI on an ME3600 to get this scenario to work? Perhaps you used something else that worked? Or do you think this simply can't be done? When mixing L2TPv3 with VFIs, is the logic present to do things like MAC learning, I've never tried this without MPLS and/or BGP. Something like; pseudowire-class l2tpv3-class encapsulation l2tpv3 interworking ethernet ip local interface looopback 0 l2 vfi TEST manual vpn id 100 bridge-domain 200 neighbor 1.1.1.1 pw-class l2tpv3-class neighbor 2.2.2.2 pw-class l2tpv3-class int gi0/2 switchport mode trunk switchport trunk allow vlan none service instance 200 ethernet uncapsulation untagged bridge-domain 200 int vlan200 no ip address 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/
Re: [c-nsp] Cisco IOS XR EEM
You may want to check the EEM Applet to TCL convertor that was written by Joe Clarke: http://www.marcuscom.com/convert_applet/ Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of M K Sent: Wednesday, September 3, 2014 04:01 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco IOS XR EEM Hi , I have the below EEM script and am trying to do it using IOS XR event manager applet SLA_OUT event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.2 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5 action 1.0 syslog msg Test action 1.1 cli command enable action 1.2 cli command configure terminal action 1.3 cli command ip route 0.0.0.0 0.0.0.0 192.168.13.3 action 1.4 syslog msg There is a problem on our Primary connection , move all the traffic to the Secondary Line event manager applet SLA_OK event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.2 get-type exact entry-op eq entry-val 2 exit-op eq exit-val 1 poll-interval 5 action 1.0 syslog msg OK action 1.1 cli command enable action 1.2 cli command configure terminal action 1.3 cli command no ip route 0.0.0.0 0.0.0.0 192.168.13.3 action 1.4 syslog msg Our Primary connection is functionin again , stop using the Secondary Line ___ cisco-nsp 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] LNS question asr 1002
You may actually want to look at summarizing this. The best practice would be to have a per-LNS pool (either locally managed or from RADIUS) and advertise the summary from the LNS up to the network. You may need to redistribute also connected routes for fixed IP services where a user may have a custom IP from the RADIUS. Not summarizing means that every connection (and disconnection) is a BGP update driving your CPU utilization across the BGP domain... Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Sent: Monday, August 18, 2014 09:23 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LNS question asr 1002 On 08/17/2014 08:24 PM, Edwardo Garcia wrote: Secondly, how does one handle running two LNS servers? How does the border router know which edge (LNS) to forward too for a particular IP? I do it with iBGP where my router is advertising individual /32's. Yes it makes the route tables longer but it works well in my environment. YMMV. Mike- ___ cisco-nsp 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] LNS question asr 1002
Actually, there is a solution for that... It's called ODAP and it allows your LNS to pull address pools from a server. So you can have smaller pools (like /25's or /24's) assigned from the server and announced as aggregates. Even a /25 is better than 128x/32's http://www.cisco.com/c/en/us/td/docs/ios/ios_xe/ipaddr/configuration/guide/xe_3s/iad_xe_3s_book/iad_dhcp_sod_apm_xe.html It has been a while since I played with it, but the concept should be mostly the same. Arie -Original Message- From: Youssef Bengelloun-Zahr [mailto:yous...@720.fr] Sent: Monday, August 18, 2014 10:17 To: Arie Vayner (avayner) Cc: Mike; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LNS question asr 1002 Hello Arie, I hear you and your arguments are perfectly understandable. The only downside I see with per-LNS pool is lack of redundancy in case of hardware failure. In previous companies I worked for, PPPoL2TP used to terminate randomly on a pool of LNS based on a radius Round Robin algorithm. Excellent for balancing sessions evenly (or not) but the one downside is that you have to re-announce /32s inside your BGP domain. If you RRs can handle it, then why not do it... I guess that this isn't a problem for small to medium sized ISPs, but that's a different song for big ones. Again, it'll all depends on your business case and pre-requisits. Best regards. Le 18 août 2014 à 18:50, Arie Vayner (avayner) avay...@cisco.com a écrit : You may actually want to look at summarizing this. The best practice would be to have a per-LNS pool (either locally managed or from RADIUS) and advertise the summary from the LNS up to the network. You may need to redistribute also connected routes for fixed IP services where a user may have a custom IP from the RADIUS. Not summarizing means that every connection (and disconnection) is a BGP update driving your CPU utilization across the BGP domain... Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Sent: Monday, August 18, 2014 09:23 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LNS question asr 1002 On 08/17/2014 08:24 PM, Edwardo Garcia wrote: Secondly, how does one handle running two LNS servers? How does the border router know which edge (LNS) to forward too for a particular IP? I do it with iBGP where my router is advertising individual /32's. Yes it makes the route tables longer but it works well in my environment. YMMV. Mike- ___ cisco-nsp 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] LNS question asr 1002
It is actually there on the 7200. I just looked for a newer config guide… http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/12-4t/dhcp-12-4t-book/config-dhcp-addr-pm.html From: Youssef Bengelloun-Zahr [mailto:yous...@720.fr] Sent: Monday, August 18, 2014 10:32 To: Arie Vayner (avayner) Cc: Mike; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LNS question asr 1002 Hello, Didn't know about this, I will definetly give it a look. Given it need IOS XE to run, I believe it needs an ASR platform to run (just like OP requested). I'm used to doing this the old way with 7200VXR series ;-) Thanks for the hint. Best regards. Y. 2014-08-18 19:22 GMT+02:00 Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com: Actually, there is a solution for that... It's called ODAP and it allows your LNS to pull address pools from a server. So you can have smaller pools (like /25's or /24's) assigned from the server and announced as aggregates. Even a /25 is better than 128x/32's http://www.cisco.com/c/en/us/td/docs/ios/ios_xe/ipaddr/configuration/guide/xe_3s/iad_xe_3s_book/iad_dhcp_sod_apm_xe.html It has been a while since I played with it, but the concept should be mostly the same. Arie -Original Message- From: Youssef Bengelloun-Zahr [mailto:yous...@720.frmailto:yous...@720.fr] Sent: Monday, August 18, 2014 10:17 To: Arie Vayner (avayner) Cc: Mike; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LNS question asr 1002 Hello Arie, I hear you and your arguments are perfectly understandable. The only downside I see with per-LNS pool is lack of redundancy in case of hardware failure. In previous companies I worked for, PPPoL2TP used to terminate randomly on a pool of LNS based on a radius Round Robin algorithm. Excellent for balancing sessions evenly (or not) but the one downside is that you have to re-announce /32s inside your BGP domain. If you RRs can handle it, then why not do it... I guess that this isn't a problem for small to medium sized ISPs, but that's a different song for big ones. Again, it'll all depends on your business case and pre-requisits. Best regards. Le 18 août 2014 à 18:50, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com a écrit : You may actually want to look at summarizing this. The best practice would be to have a per-LNS pool (either locally managed or from RADIUS) and advertise the summary from the LNS up to the network. You may need to redistribute also connected routes for fixed IP services where a user may have a custom IP from the RADIUS. Not summarizing means that every connection (and disconnection) is a BGP update driving your CPU utilization across the BGP domain... Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Sent: Monday, August 18, 2014 09:23 To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LNS question asr 1002 On 08/17/2014 08:24 PM, Edwardo Garcia wrote: Secondly, how does one handle running two LNS servers? How does the border router know which edge (LNS) to forward too for a particular IP? I do it with iBGP where my router is advertising individual /32's. Yes it makes the route tables longer but it works well in my environment. YMMV. Mike- ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto: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.netmailto:cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Youssef BENGELLOUN-ZAHR ___ cisco-nsp 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] PPPoE and PPtP Problems
Francisco, Create a new AAA authentication profile (instead of default use a custom name) and set it to local authentication. Apply that on the virtual-template you use for PPTP Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Francisco Lopez Posadas Sent: Monday, July 21, 2014 08:34 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PPPoE and PPtP Problems Hello, my debut with a question and see if you can help me. I currently have a Cisco 7206VXR where I have a Radius server configured for PPPoE. The problem is that I also used for PPTP and that's what I do not. I would like to access through PPTP out under local authentication only, not the radius. I have ver 12.4-24-T2 advance enterprise. I copied the current config in case I see something strange: upgrade fpd auto version 12.4 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname x ! boot-start-marker boot system disk2:c7200-adventerprisek9-mz.124-24.T2.bin boot-end-marker ! logging message-counter syslog logging snmp-authfail logging queue-limit 100 enable secret 5 * ! aaa new-model ! ! aaa authentication login default local aaa authentication ppp default group radius aaa authorization exec default local aaa authorization network default group radius aaa accounting delay-start aaa accounting update periodic 3 aaa accounting exec default action-type start-stop group radius ! aaa accounting network default action-type start-stop group radius ! aaa accounting network vpdn action-type start-stop group radius ! ! aaa nas port extended aaa server radius dynamic-author server-key 7 * auth-type any ! aaa session-id common ip source-route ip cef ! ! ! multilink bundle-name authenticated vpdn enable ! vpdn-group 1 ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 force-local-chap ! ! ! bba-group pppoe global virtual-template 2 ! ! interface Loopback0 no ip address ! ! interface Virtual-Template1 ip unnumbered GigabitEthernet0/1 ip virtual-reassembly peer default ip address pool vpn-pptp no keepalive ppp encrypt mppe 128 ppp authentication ms-chap pap chap ms-chap-v2 ! interface Virtual-Template2 mtu 1492 ip unnumbered GigabitEthernet0/1.xxx no ip redirects no ip unreachables no ip proxy-arp no snmp trap link-status peer default ip address dhcp-pool pruebas keepalive 4 ppp authentication chap pap ppp ipcp route default ppp multilink ! ip local pool vpn-pptp 10.13.0.9 10.13.0.14 ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 xxx no ip http server no ip http secure-server ! ! radius-server host xxx.xxx.xxx.xxx auth-port 1812 acct-port 1813 radius-server timeout 3 radius-server key 7 radius-server vsa send accounting radius-server vsa send authentication ! control-plane ! ! ! ! ! ! ! gatekeeper shutdown ! ! line con 0 password 7 stopbits 1 line aux 0 stopbits 1 line vty 0 4 password 7 transport input ssh ! End Thank´s in advance ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] PPPoE and PPtP Problems
Something like this: aaa authentication ppp LOCAL-PPP local aaa authorization network LOCAL-PPP local if-authenticated interface Virtual-Template1 no ip address ppp authentication pap chap LOCAL-PPP ppp authorization LOCAL-PPP Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arie Vayner (avayner) Sent: Monday, July 21, 2014 10:25 To: Francisco Lopez Posadas; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] PPPoE and PPtP Problems Francisco, Create a new AAA authentication profile (instead of default use a custom name) and set it to local authentication. Apply that on the virtual-template you use for PPTP Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Francisco Lopez Posadas Sent: Monday, July 21, 2014 08:34 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PPPoE and PPtP Problems Hello, my debut with a question and see if you can help me. I currently have a Cisco 7206VXR where I have a Radius server configured for PPPoE. The problem is that I also used for PPTP and that's what I do not. I would like to access through PPTP out under local authentication only, not the radius. I have ver 12.4-24-T2 advance enterprise. I copied the current config in case I see something strange: upgrade fpd auto version 12.4 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname x ! boot-start-marker boot system disk2:c7200-adventerprisek9-mz.124-24.T2.bin boot-end-marker ! logging message-counter syslog logging snmp-authfail logging queue-limit 100 enable secret 5 * ! aaa new-model ! ! aaa authentication login default local aaa authentication ppp default group radius aaa authorization exec default local aaa authorization network default group radius aaa accounting delay-start aaa accounting update periodic 3 aaa accounting exec default action-type start-stop group radius ! aaa accounting network default action-type start-stop group radius ! aaa accounting network vpdn action-type start-stop group radius ! ! aaa nas port extended aaa server radius dynamic-author server-key 7 * auth-type any ! aaa session-id common ip source-route ip cef ! ! ! multilink bundle-name authenticated vpdn enable ! vpdn-group 1 ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 force-local-chap ! ! ! bba-group pppoe global virtual-template 2 ! ! interface Loopback0 no ip address ! ! interface Virtual-Template1 ip unnumbered GigabitEthernet0/1 ip virtual-reassembly peer default ip address pool vpn-pptp no keepalive ppp encrypt mppe 128 ppp authentication ms-chap pap chap ms-chap-v2 ! interface Virtual-Template2 mtu 1492 ip unnumbered GigabitEthernet0/1.xxx no ip redirects no ip unreachables no ip proxy-arp no snmp trap link-status peer default ip address dhcp-pool pruebas keepalive 4 ppp authentication chap pap ppp ipcp route default ppp multilink ! ip local pool vpn-pptp 10.13.0.9 10.13.0.14 ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 xxx no ip http server no ip http secure-server ! ! radius-server host xxx.xxx.xxx.xxx auth-port 1812 acct-port 1813 radius-server timeout 3 radius-server key 7 radius-server vsa send accounting radius-server vsa send authentication ! control-plane ! ! ! ! ! ! ! gatekeeper shutdown ! ! line con 0 password 7 stopbits 1 line aux 0 stopbits 1 line vty 0 4 password 7 transport input ssh ! End Thank´s in advance ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] 3850 per VLAN shaping help...
Peter, Can you show how did you try to apply the QOS policy per VLAN? Basically, you should be able to apply a policy per SVI (i.e. interface VLAN) This is the QOS configuration guide for the Catalyst 3850: http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/qos/configuration_guide/b_qos_3se_3850_cg/b_qos_3se_3850_cg_chapter_011.html#topic_6903E3E73B5E4263B81CB726C9D8C51D Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz Sent: Tuesday, March 11, 2014 09:45 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 3850 per VLAN shaping help... I am attempting apply per VLAN shaping on the 3850 chassis and having various problems; 1: I have attempted creating policy-maps and applying them to the VLAN SVI. Config mode takes the service-policy commands, with no errors in the log, but a show run on the interface indicates that nothing was applied.. 2: I have tried creating a more complicated policy-map to handle all the vlans on a particular trunk, i.e.: class-map match-any TheFuelist match vlan 202 class-map match-any StephenEBlockCompany match vlan 201 class-map match-any Advoco match vlan 200 ! policy-map CentroShaping class StephenEBlockCompany shape average 2500 class Advoco shape average 1 class TheFuelist shape average 2500 class class-default shape average 5000 But upon applying these to the trunk port I get : Mar 11 08:23:58.363 PDT: Invalid queuing class-map!!! Queuing actions supported only with dscp/cos/qos-group/precedence based classification!!! The only examples I have found either say apply to the SVI (Which doesn't seem to work) or apply to routed sub interfaces instead of trunk ports. Any hints? Peter Kranz www.UnwiredLtd.com http://www.unwiredltd.com/ Desk: 510-868-1614 x100 Mobile: 510-207- pkr...@unwiredltd.com mailto:pkr...@unwiredltd.com ___ cisco-nsp 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] LDP based CSC VPN - ASR9k/IOS-XR 4.3.4
You should be able to implement this with BGP+Label http://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-7/mpls/configuration/guide/gc37v3.html#wp1168949 address-family ipv4 labeled-unicast Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos Chatzithomaoglou Sent: Monday, March 10, 2014 10:17 To: Arun Kumar; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LDP based CSC VPN - ASR9k/IOS-XR 4.3.4 I don't think there is LDP support in IOS-XR for CsC PE-CE. -- Tassos Arun Kumar wrote on 10/03/2014 15:43: Hi All, I am trying to configure CSC MPLS VPN on IOS-XR 4.3.4 on ASR 9K as PE. Currently the configuration is on NPE-G2 and NPE-G1 as PE routers. LDP is configured between PE and CE for label exchange and OSPF is the protocol between PE and CE. When I try to configure LDP between ASR9K and CPE, I am not getting LDP as the option between PE and CE, I am not getting any option of specifying LDP under the VRF. Even the IOS-XR MPLS config guide only talks about BGP based label exchange between PE and CE on IOS-XR. I would like to confirm, can LDP be configured under VRF in ASR9K as PE or BGP is the only option available? thanks in advance Arun ___ cisco-nsp 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] Upgrading to 40G
Pshem, You should most likely take a look at the Cisco ASR 9000 Series Modular Line Cards: http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/data_sheet_c78-663866.html You can use either the A9K-MPA-1x40GE or A9K-MPA-2x40GE modules which support the 40G QSFP optics: http://www.cisco.com/c/en/us/td/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_24900.html#77832 HTH Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pshem Kowalczyk Sent: Thursday, February 27, 2014 17:49 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Upgrading to 40G Hi, We just started planning to upgrade our 10G (and nx10G) links to 40G (on ASR9k). Quick scan through Cisco website revealed that there are no 40km optics available from Cisco. That threw a big spanner into the works as we have a bunch of links definitely over LR budgets. So the question is - how do you do 40G in metro areas? Deploy some sort of amplifiers? Go through DWDM or OTN devices? 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/
Re: [c-nsp] VPLS on GSR12k
Rob, VPLS should be support on GSR 12K routers with SIP-600 (engine 5...) It should actually have somewhat less restrictions than the engine 3 ISE modules... I do think (it has been a long time since I had to really touch it) that you need to run IOS-XR for that. Check this configuration guide for some details (there might be newer one available...): http://www.cisco.com/c/en/us/td/docs/routers/xr12000/software/xr12k_r4-1/lxvpn/configuration/guide/vc41xr12k/vc41vpls.html Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Robert Hass Sent: Thursday, February 20, 2014 12:27 To: cisco-nsp@puck.nether.net Subject: [c-nsp] VPLS on GSR12k Hi I have question regarding linecards which supports VPLS. Here is only one linecard (ISE 4x1G) supported as edge side for VPLS: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/vpls_qos.html Can I have edge side on SIP+SPA ? My GSR is only equipped with SIP-600 and SPA cards Rob ___ cisco-nsp 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 and RFC 6106 (RDNS in IPv6 RAs)
Chris, So we have support for advertising DNS server addresses in RA in the IOS T train since 15.4(1)T and S train (since 15.3(2)S). In the future there will also be additional support for DNS search lists. Tnx Arie -Original Message- From: Christopher Werny [mailto:cwe...@ernw.de] Sent: Monday, February 17, 2014 01:13 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: RE: Cisco and RFC 6106 (RDNS in IPv6 RAs) Hi Arie, thanks for the quick reply! Looking forward to your update. Cheers, Chris -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: Montag, 17. Februar 2014 01:41 To: Christopher Werny; cisco-nsp@puck.nether.net Subject: RE: Cisco and RFC 6106 (RDNS in IPv6 RAs) Chris, The new command is ipv6 nd ra dns server address [lifetime] This is the command reference entry: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp3800310030 It seems to be officially in IOS-XE, and I am double checking what the status is for IOS. Will update. HTH Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Christopher Werny Sent: Sunday, February 16, 2014 16:17 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco and RFC 6106 (RDNS in IPv6 RAs) Hi everyone, I haven't seen any official announcement that RDNS option in RAs is finally supported in Cisco IOS, and my google/fn-fu did not result in any success (but this could be a typical layer 8 problem ;)). However, I stumpeld over an Cisco IOS IPv6 Command Reference Guide which included the command ipv6 nd ra dns server that achieves what I am looking for, but I couldn't find any information on which Devices/IOS trains this command is supported. The Reference Guide can be found here: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp3800310030 Does anyone know on which trains/devices this command is supported? or have some general pointers in regards to RFC 6106 support in Cisco IOS? Thanks for your time ! Cheers, 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/ ___ cisco-nsp 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 and RFC 6106 (RDNS in IPv6 RAs)
Chris, The new command is ipv6 nd ra dns server address [lifetime] This is the command reference entry: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp3800310030 It seems to be officially in IOS-XE, and I am double checking what the status is for IOS. Will update. HTH Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Christopher Werny Sent: Sunday, February 16, 2014 16:17 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco and RFC 6106 (RDNS in IPv6 RAs) Hi everyone, I haven't seen any official announcement that RDNS option in RAs is finally supported in Cisco IOS, and my google/fn-fu did not result in any success (but this could be a typical layer 8 problem ;)). However, I stumpeld over an Cisco IOS IPv6 Command Reference Guide which included the command ipv6 nd ra dns server that achieves what I am looking for, but I couldn't find any information on which Devices/IOS trains this command is supported. The Reference Guide can be found here: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-book/ipv6-i3.html#wp3800310030 Does anyone know on which trains/devices this command is supported? or have some general pointers in regards to RFC 6106 support in Cisco IOS? Thanks for your time ! Cheers, 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/ ___ cisco-nsp 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: VPLS Attachment Circuit Resiliency options
Andrea, You may want to start here: http://www.cisco.com/en/US/partner/docs/switches/metro/me3600x_3800x/software/release/15.4_1_S/configuration/guide/swevc.html#wp1044168 HTH Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pasquino Andrea Sent: Tuesday, January 21, 2014 09:12 To: cisco-nsp@puck.nether.net Subject: [c-nsp] ME3600X: VPLS Attachment Circuit Resiliency options Hello, We have three sites: in each site two Customer Switches are attached to two ME3600x PE. The service between the three sites must be Layer2, and we don't want to mix L2protocols between PEs and customer switches. I know there are some solutions for 7600 (relay BPDU through dedicated PW, MC-LAG, etc...). Are there solutions now or in roadmap for ME3600x/ME3800X ? Best Regards Andrea ___ cisco-nsp 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] Difference between Cisco Q-in-Q and IEEE 802.1ad
Martin, From a quick check I could see support for both 802.1ad (0x88a8) and other custom S-tags (0x9100) on ASR9K. I can also see references on 7600 with ES+ modules. Some references: https://supportforums.cisco.com/docs/DOC-15556 http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.2/lxvpn/command/reference/b_lxvpn_cr42asr9k_chapter_01.html#wp1086679105 http://www.cisco.com/en/US/products/ps9853/products_tech_note09186a0080c1d17b.shtml HTH Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of sth...@nethelp.no Sent: Wednesday, January 1, 2014 9:24 PM To: m4rtn...@gmail.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Difference between Cisco Q-in-Q and IEEE 802.1ad I made a simple setup where Cisco Q-in-Q port(switchport mode dot1q-tunnel) was facing a laptop. Laptop was sending out frames with 802.1q tag(VID was 10) and Cisco Q-in-Q port pushed another 802.1q field. Final frame can be seen here: http://www.cloudshark.org/captures/ae485b68e9ed Based on this Cisco Q-in-Q frame, the only difference between IEEE 802.1ad frame and Cisco Q-in-Q frame is that former has 0x88a8 as an TPID value for S-tag? I made a small illustration for this: Correct, it's 0x88a8 vs 0x8100 for the S-tag. In addition, are there Cisco switches out there which use 0x88a8 as a TPID value of S-tag by default? Don't know of any. Last but not least, which devices use 0x9100 as a TPID value for S-tags? According to drawing in Wikipedia IEEE 802.1ad article, some do: Juniper E-series (ERX) routers use 0x9100 by default. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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 add-path with MPBGP/VPNv4
Add-path is a relatively new implementation so would only appear in the newer IOS versions... As this is an MPLS VPN environment there is an easy fix... You can use different RD values for the different default routes (on the VRFs originating the defaults). This would trick the RR to advertise both routes (because the different RD values make them different VPNv4 prefixes). Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andrew K. Sent: Thursday, December 5, 2013 10:09 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] BGP add-path with MPBGP/VPNv4 I have a VRF configuration with MP-BGP/MPLS. In vrf A there are two default gateways being advertised to the route-reflectors. Half of the PE devices in VRF A need to send traffic out one gateway and the other half out the other, but the route-reflectors are only sending one best route to the PE. Digging up info on add-path, it appears to have very limited support, I can not find support for it using the feature set navigator for anything other then the ASR1000, 7600, 3900 and IOS XR. Is this feature supported by the 7200? Can it be used in a VPNv4/VRF environment? Should I just be doing BGP Multipath Load Sharing instead and use a route-map to set the weight of the default route for each PE device? Thanks in advance for your time. Andrew. ___ cisco-nsp 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] shaping 128 mbps - asr9k
You should be policing it... not shaping. Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Tuesday, November 12, 2013 12:58 PM To: Oliver Boehmer (oboehmer); cisco-nsp@puck.nether.net Subject: Re: [c-nsp] shaping 128 mbps - asr9k (here's the uncommitted (failing) config... basically I want to shape inbound UDP to 600 mbps. please show me how to accomplish that.) RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#show config policy-map from-internet-parent class class-default service-policy from-internet-child shape average 1 gbps ! end-policy-map ! interface GigabitEthernet0/0/0/5 service-policy input from-internet-parent ! end RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#commi % Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed' from this session to view the errors RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#show config failed !! SEMANTIC ERRORS: This configuration was rejected by !! the system due to semantic errors. The individual !! errors with each failed configuration command can be !! found below. interface GigabitEthernet0/0/0/5 service-policy input from-internet-parent !!% 'prm_ezhal' detected the 'warning' condition 'Cannot support child/flat shape rate 128Mbps' ! end RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#do sh run class-map class-map match-all udp-attack match protocol udp end-class-map ! -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: Tuesday, November 12, 2013 2:23 PM To: Aaron; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] shaping 128 mbps - asr9k Anyone know how to accomplish shaping traffic at a rate greater than 128 mbps ? When I apply the policy-map/class-map to an interface it fails with this message. 'Cannot support child/flat shape rate 128Mbps' can you please share the configuration you are trying to apply, including policy-maps and where you want to apply this? 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/ ___ cisco-nsp 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] Menu in Cisco
Take a look at EMM - Embedded Menu Manager (not to confuse with EEM) http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_emm_ps6441_TSD_Products_Configuration_Guide_Chapter.html Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ali Sumsam Sent: Sunday, November 3, 2013 18:02 PM To: cisco-nsp NSP Subject: [c-nsp] Menu in Cisco Hello, I am working on a Cisco 3750X switch and have noticed that the menu command isn't available with IOS versions 12.2 as well as 15.2 I am trying to set up a few simple commands as Menu options. Is there any other simple way to do it, with the Menu command not being available? *Ali Sumsam * *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco - Brocade - IBM ___ cisco-nsp 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] Bridging over PPP
Mike, I am still not sure what your complete solution looks like... Any chance you could give us a bit more info? A diagram would be really nice. Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Sent: Sunday, September 1, 2013 10:58 AM Cc: 'Cisco-nsp' Subject: Re: [c-nsp] Bridging over PPP On 09/01/2013 05:55 AM, Ross Halliday wrote: Just throwing this out here, but why are you bridging PPPoE customers which supposedly 'terminate' on the 7201? Why not L2TP LAC/LNS? With your 7201 acting as a LAC you can push the tunnels anywhere IP will go. Bridging IMHO is a nasty thing that should only be used where strictly necessary. The issue is that I would only have a multilink ppp bundle over T1's connecting the 7201 to the pop where the pppoe customers are. I don't see how I could connect the pppoe subscribers, with multilink ppp in the middle, to the 7201 and expect it to work. If you have an idea how this might fly please let me know. I think gert (thanks) had the right idea with mpls, likely too much trouble however. Mike- ___ cisco-nsp 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] Geeting problem on Cisco Processor Engine: NPE-G1
The traceback errors you are getting decode to issues allocating memory while the router is booting. My guess would be this is a very old device (NPE-G1 was announced End of Sale in 2011)... They are still supported by Cisco (Last day of support is Feb 2017) You most likely have a hardware failure either on the NPE itself or some of the memory DIMMs... If you have support contract, RMA it... Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Md. Jahangir Hossain Sent: Sunday, September 1, 2013 23:54 PM To: cisco Subject: [c-nsp] Geeting problem on Cisco Processor Engine: NPE-G1 Dear all: I am facing some about Cisco Processor Engine: NPE-G1 which was plug into Cisco 7206VXR . Due some issue i unplug the NPE-G1 card and insert this engine to another Cisco 7204VXR router at same time i am getting problem while booing the 7204VXR router and results 7204VXR not come up in normal stage . Platform: 7204VXR / 7206VXR Processor Engine: NPE-G1 Flash: 64MB I got bellow summary message also attached the details log message for better understanding.it would be nice can any one suggest me how to resolved this matter. *** System received a Bus Error exception *** signal= 0xa, code= 0x1c, context= 0x6101b6b4 PC = 0x60688fe4, SP = 0x61074c30, RA = 0x60688fe4 Cause Reg = 0x401c, Status Reg = 0x34008003 System Bootstrap, Version 12.2(8r)B, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 2002 by cisco Systems, Inc. System Bootstrap, Version 12.2(8r)B, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 2002 by cisco Systems, Inc. C7200 platform with 1048576 Kbytes of main memory === Flushing messages () === Buffered messages: Queued messages: No warm reboot Storage *** System received a Cache Parity Exception *** signal= 0x14, code= 0x3c80, context= 0x64287524 PC = 0xa100, SP = 0x646110e0, RA = 0x61d8e9a8 Cause Reg = 0x4000, Status Reg = 0x3400c107 System Bootstrap, Version 12.2(8r)B, RELEASE SOFTWARE (fc1) TAC Support: http://www.cisco.com/tac Copyright (c) 2002 by cisco Systems, Inc. C7200 platform with 1048576 Kbytes of main memory Thanks for nice co-operation. regards // Jahangir ___ cisco-nsp 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] Bridging over PPP
Can you please provide a bit more info... Where are the bonded T1s coming from? How are they terminated? A more complete topology with device types would help to provide the best solution... Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mike Sent: Saturday, August 31, 2013 14:21 PM To: 'Cisco-nsp' Subject: [c-nsp] Bridging over PPP Hi, I have a location that has several PPPoE customers, which are terminating on my 7201 router. I have a somewhat unreliable ethernet link connecting these users to the router which I have decided to replace with a link formed of bonded T1's. The question is can I somehow create an ethernet bridge over bonded T1's (ppp multilink) or must I use a VPN to tunnel the ethernet traffic thru? I am happy with and have an ethernet bridging over vpn solution, it's just peformance and the fact of needing another box at the far end site close to the users which is ugly and undesirable. Any suggestions appreciated. Mike- ___ cisco-nsp 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] BGP re-announcement question
Pete, I wrote that I am not sure your customer would always want you to send traffic down their link because there are scenarios where customers would buy backup links which they expect not to get traffic on unless some other primary link goes down... So making the firm assumption might be wrong in all cases, and this is why the ability to control it (via communities as the easiest option or calls to the NOS as a worst case scenario) is critical. I do agree that setting the local-pref for customers to higher than default is a good practice and should be implemented. Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pete Templin Sent: Thursday, August 1, 2013 6:02 AM To: Adam Greene Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP re-announcement question On 7/29/13 4:06 PM, Arie Vayner (avayner) wrote: The best route is through your upstream (I guess), so you are not advertising it back... You could increase the local-pref for routes you receive from your customers as compared to routes you receive from your upstreams. In this way you would always prefer the local path to your customer (not sure they would like you to do that...) +1 on this. They are your customer, so it's safe to presume that they want you to carry their traffic (they send you a check every month in exchange for this service), and in turn you (might) send a check elsewhere to continue the process. It's not an easy thing to roll out en masse, but I'd argue that it needs to be done. I normally use 400 for customer routes, 300 for routes from peers (I've been known to use transit providers as peers; accept only their routes and their customer routes, and advertise out with no-export or their own 'peer' community), 200 for routes from transits. One benefit is that an unconfigured router with LP=100 won't get any traffic, so it'll make the lack of proper configuration obvious. As others suggested, a community to override this might be appreciated by your customers, if they have enough clue to use it. Be warned that since everyone else (or at least everyone else upstream of you) does this same sort of preference, so if they request a low LP in your network, they're going to want a low LP in subsequent networks until they get to the peered-only networks. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR 9922 IOS-XR 4.3.1
Can you please sniff/debug the whole RSVP setup process? We had a really old issue, which seems kind of similar (this one was with an Alcatel box) - CSCsb94418 MPLS-TE Tailend does not reflect Path MTU into max unit BSymptom:/B The max unit in the FLOWSPEC of an RSVP RESV message sent by an MPLS TE tailend is hardcoded to 500 bytes. When creating a RESV message, an MPLS TE tailend should use the Path MTU value received in the ADSPEC of the PATH message as the value of max unit in the FLOWSPEC of the RESV message. BConditions:/B This happens on a MPLS TE tailend running IOS XR. BWorkaround:/B There is no workaround. Tnx Arie -Original Message- From: Harvey [mailto:harveyyo...@gmail.com] Sent: Tuesday, July 30, 2013 21:27 PM To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR 9922 IOS-XR 4.3.1 Hello, The other side is a brocade. I confirmed via sniffing the transmitted rsvp packets from the ASR are set with mtu 500. Any idea where it's getting this from and how it can be changed ? Cheers, Harvey Young On Jul 30, 2013, at 8:45 PM, Arie Vayner (avayner) avay...@cisco.com wrote: Harvey, Can you please tell me what's on the other side? Tnx Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Harvey Young Sent: Tuesday, July 30, 2013 18:18 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASR 9922 IOS-XR 4.3.1 Hello Experts, Question: How is the T Spec MTU set on the ASR? I am running into a wall, the ASR sends T Spec mtu of 500 for an RSVP LSP. However, 500 is not set anywhere. I have the following MTU set: (Including snip bits from configuration, see below) Essentially the setup is an RSVP-TE LSP and a L2PW utilizing the LSP. The remote end is sending 9198, however since the ASR is sending 500, 500 the lower mtu is negotiated and used. cisco-nsp@puck.nether.netHundredGigE0/1/0/0 is Up, ipv4 protocol is Up Vrf is default (vrfid 0x6000) Internet address is 13.1.1.1/24 MTU is 9212 (9198 is available to IP) RP/0/RP0/CPU0:ios#show running-config interface Tue Jul 30 18:02:22.481 UTC interface Loopback1 ipv4 address 1.1.1.1 255.255.255.255 ! interface tunnel-te1 ipv4 unnumbered Loopback1 mpls mtu 9198 ! destination 7.7.7.7 path-option 1 dynamic ! interface HundredGigE0/1/0/0 mtu 9212 ipv4 address 13.1.1.1 255.255.255.0 mpls mtu 9198 ! interface HundredGigE0/1/0/1.1 l2transport encapsulation dot1q 1 second-dot1q 1 mtu 1528 ! RP/0/RP0/CPU0:ios#show running-config l2vpn Tue Jul 30 18:04:05.107 UTC l2vpn router-id 1.1.1.1 pw-class 1 encapsulation mpls protocol ldp preferred-path interface tunnel-te 1 ! ! xconnect group 1 p2p 1 interface HundredGigE0/1/0/1.1 neighbor ipv4 7.7.7.7 pw-id 1 pw-class 1 ! mpls traffic-eng interface tunnel-te1 ! interface HundredGigE0/1/0/0 ! attribute-set path-option 1 ! ! mpls ldp neighbor 7.7.7.7 targeted ! rsvp interface Loopback1 ! interface tunnel-te1 bandwidth percentage 100 ! interface HundredGigE0/1/0/0 ! ! Trace from remote system: Recv PATH From:1.1.1.1, To:7.7.7.7 TTL:255, Checksum:0x25f1, Flags:0x1 Session- EndPt:7.7.7.7, TunnId:1, ExtTunnId:1.1.1.1 SessAttr - Name:ios_t1 SetupPri:7, HoldPri:7, Flags:0x4 RSVPHop- Ctype:1, Addr:13.1.1.1, LIH:100663488 TimeValue - RefreshPeriod:45 SendTempl - Sender:1.1.1.1, LspId:12 SendTSpec - Ctype:QOS, CDR:0.000 bps, PBS:8.000 Kbps, PDR:0.000 bps MPU:40, *MTU:500* -- LabelReq - IfType:General, L3ProtID:2048 ERO- IPv4Prefix 13.1.1.2/32, Strict IPv4Prefix 7.7.7.7/32, Strict AdSpec - General BreakBit:0, NumISHops:1, PathBwEstimate:0 MinPathLatency:0, CompPathMTU:9198 Controlled BreakBit:0 ___ cisco-nsp 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] ASR 9922 IOS-XR 4.3.1
Harvey, Can you please tell me what's on the other side? Tnx Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Harvey Young Sent: Tuesday, July 30, 2013 18:18 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASR 9922 IOS-XR 4.3.1 Hello Experts, Question: How is the T Spec MTU set on the ASR? I am running into a wall, the ASR sends T Spec mtu of 500 for an RSVP LSP. However, 500 is not set anywhere. I have the following MTU set: (Including snip bits from configuration, see below) Essentially the setup is an RSVP-TE LSP and a L2PW utilizing the LSP. The remote end is sending 9198, however since the ASR is sending 500, 500 the lower mtu is negotiated and used. cisco-nsp@puck.nether.netHundredGigE0/1/0/0 is Up, ipv4 protocol is Up Vrf is default (vrfid 0x6000) Internet address is 13.1.1.1/24 MTU is 9212 (9198 is available to IP) RP/0/RP0/CPU0:ios#show running-config interface Tue Jul 30 18:02:22.481 UTC interface Loopback1 ipv4 address 1.1.1.1 255.255.255.255 ! interface tunnel-te1 ipv4 unnumbered Loopback1 mpls mtu 9198 ! destination 7.7.7.7 path-option 1 dynamic ! interface HundredGigE0/1/0/0 mtu 9212 ipv4 address 13.1.1.1 255.255.255.0 mpls mtu 9198 ! interface HundredGigE0/1/0/1.1 l2transport encapsulation dot1q 1 second-dot1q 1 mtu 1528 ! RP/0/RP0/CPU0:ios#show running-config l2vpn Tue Jul 30 18:04:05.107 UTC l2vpn router-id 1.1.1.1 pw-class 1 encapsulation mpls protocol ldp preferred-path interface tunnel-te 1 ! ! xconnect group 1 p2p 1 interface HundredGigE0/1/0/1.1 neighbor ipv4 7.7.7.7 pw-id 1 pw-class 1 ! mpls traffic-eng interface tunnel-te1 ! interface HundredGigE0/1/0/0 ! attribute-set path-option 1 ! ! mpls ldp neighbor 7.7.7.7 targeted ! rsvp interface Loopback1 ! interface tunnel-te1 bandwidth percentage 100 ! interface HundredGigE0/1/0/0 ! ! Trace from remote system: Recv PATH From:1.1.1.1, To:7.7.7.7 TTL:255, Checksum:0x25f1, Flags:0x1 Session- EndPt:7.7.7.7, TunnId:1, ExtTunnId:1.1.1.1 SessAttr - Name:ios_t1 SetupPri:7, HoldPri:7, Flags:0x4 RSVPHop- Ctype:1, Addr:13.1.1.1, LIH:100663488 TimeValue - RefreshPeriod:45 SendTempl - Sender:1.1.1.1, LspId:12 SendTSpec - Ctype:QOS, CDR:0.000 bps, PBS:8.000 Kbps, PDR:0.000 bps MPU:40, *MTU:500* -- LabelReq - IfType:General, L3ProtID:2048 ERO- IPv4Prefix 13.1.1.2/32, Strict IPv4Prefix 7.7.7.7/32, Strict AdSpec - General BreakBit:0, NumISHops:1, PathBwEstimate:0 MinPathLatency:0, CompPathMTU:9198 Controlled BreakBit:0 ___ cisco-nsp 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] BGP re-announcement question
The best route is through your upstream (I guess), so you are not advertising it back... You could increase the local-pref for routes you receive from your customers as compared to routes you receive from your upstreams. In this way you would always prefer the local path to your customer (not sure they would like you to do that...) You could also allow them to control it from their end by implementing a set of communities they can signal to you to change the way local-pref is applied on your end of the link. Something like this: http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801475b2.shtml http://onesc.net/communities/as7018/ HTH Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Adam Greene Sent: Monday, July 29, 2013 15:53 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] BGP re-announcement question Hi! We are receiving a heavily prepended route announcement from a customer and are trying to re-announce it to our upstream provider, without success. We learn the route on router A via eBGP. Router A announces the route to Router B via iBGP. Router B is then supposed to announce it to Router C, our upstream provider, via eBGP, but it is not. Here is what Router B is seeing: 7206VXR#sh ip bgp 198.11.15.0 BGP routing table entry for 198.11.15.0/24, version 262804866 Paths: (2 available, best #2, table Default-IP-Routing-Table) 27241 27241 27241 27241 27241 27241, (received used) 204.8.83.14 (metric 1) from 172.18.18.20 (172.18.18.20) Origin IGP, metric 300, localpref 100, valid, internal 12271 7843 3356 46887 27241, (received used) 24.29.112.25 from 24.29.112.25 (69.193.224.79) Origin IGP, localpref 100, valid, external, best Community: 7843:2161 7843:2303 7843:2313 As you can see, the eBGP route Router B is receiving from Router C (upstream) is considered the best route. Is that why we are not reannouncing it back upstream? Prefix-lists and route-maps have all been checked, including regular expressions; we allow out ^27241(_27241)*$ and a sh ip bgp regexp ^27241(_27241)*$ provides this output: Network Next HopMetric LocPrf Weight Path * i198.11.15.0 204.8.83.14300100 0 27241 27241 27241 27241 27241 27241 i I do wonder a bit about the metric 300 (I think my customer might be trying to weight things) but I'm not sure that's coming into play here or not. This was working fine recently, with no changes on our end, but the customer was announcing without any prepends, and I'm not sure if the origin was ? before, or i like it is now. Thanks, Adam ___ cisco-nsp 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] Flow based RED
I am not sure microflow policing is what is needed here... RED or WRED is supported on GSR and CRS. It is very widely deployed. UDP does not react well to WRED, and you get most of the benefit for TCP based flows, which would slow down on a single drop, while UDP would not react... Sometimes it would just be worse... It would retransmit. Try to split the classes in such a way that your bursty UDP traffic hits a tail drop policy. It does not have to be a separate class, but could be just a different WRED profile with the min/max thresholds being equal (or very close, which is virtually a tail drop policy). Look at QOS-Group based WRED. QOS-Group is a local property you can assign different flow types (using an MQC policy on ingress) even if they use the same DSCP/Prec markings. This would be difficult on an MPLS P node, as it only sees the MPLS labels... Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Hilliard Sent: Thursday, June 6, 2013 4:10 AM To: Dhamija Amit Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Flow based RED On 06/06/2013 09:41, Dhamija Amit wrote: Could you please help me out if flow based RED is supported in CRS GSR Platform , it seems currently we don't have any mechanism to limit the UDP burst when we have WRED (with both TCP UDP in same queue) and only TCP reacts when buffer is full. I think flow based RED could be a good solution if we are mixing TCP UDP together. microflow policing is only available on PFC3/PFC4 based platforms, as far as I'm aware. 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] Switchport trunk allowed issues
Something like this should do the trick: event manager applet ALLOWED-VLAN event cli pattern switchport trunk allowed vlan +[0-9]+.* mode interface enter action 001 puts ERROR: switchport trunk allowed vlan is not allowed. Use Add/Remove action 002 set _exit_status 0 The regex on the cli pattern catches only the switchport trunk allowed vlan with numbers directly after the vlan keyword (skipping 1+ spaces). If you try the add/remove/none options the regexp would not match. I didn't test it too much, so please do before deploying in production. Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of amir agha Sent: Wednesday, April 17, 2013 04:08 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Switchport trunk allowed issues Hi I am writing a EEM using Cisco ios cli, can anyone have valuable suggestion about how to materialize it. Following is the topic Using following command on switch i.e switchport trunk allowed vlan add/remove/all/except/none range However, if one forgets to include the add/remove/all/except/none keyword, the command defaults to replace: switchport trunk allowed vlan range the VLAN that has already been placed on vlan deleted and result in downtime I would like to disable the use of: switchport trunk allowed vlan range, and replace it with a custom EEM command like: 1. switchport trunk allowed vlan none. 2. switchport trunk allowed vlan add add range 3. switchport trunk allowed vlan add remove range This would correct a dangerous IOS syntax. Looking forward Ami Norway ___ cisco-nsp 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] Routed Pseudowire
Antonis, What kind of HW do you have on your 7600? You need ES20/ES+ on the interface facing the ME3600 to be able to terminate a PW on a L3 interface. Arie -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonis Vosdoganis Sent: Monday, April 15, 2013 05:49 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Routed Pseudowire Hi We are trying to establish ip connectivity a host and an SVI HOST(192.168.33.2/24)-ME3600--7609(SVI:192.168.33.1/24) ME3600 vlan 250 name RPW interface GigabitEthernet0/23 switchport trunk allowed vlan none switchport mode trunk service instance 250 ethernet encapsulation untagged bridge-domain 250 interface Vlan250 no ip address xconnect 172.16.0.0 250 encapsulation mpls 7609 vlan 250 name RPW interface Vlan250 ip address 192.168.33.2 255.255.255.0 xconnect 172.18.0.17 250 encapsulation mpls Keep in mind 7609 has only one core facing L3 interface. From mpls l2 detailed 7609 VC statistics: transit packet totals: receive 29, send 0 transit byte totals: receive 4252, send 0 transit packet drops: receive 0, seq error 0, send 0 3600 VC statistics: transit packet totals: receive 0, send 31 transit byte totals: receive 0, send 4496 transit packet drops: receive 0, seq error 0, send 0 Packet recieved from 3600 no packets send from 7609. Any ideas? I have read that this is a working scenario. Regards ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Using EoMPLS instead of end to end VLAN
Port based EoMPLS would not allow you to terminate the PW on a L3 interface on the 7600 for IP and BGP... It can be done if you have UNI facing ES20/ES+ modules on the 7600. ASR9K can do it too. It is called Routed Pseudowire/L3 Pseudowire/SVI based Pseudowire. Some references: https://supportforums.cisco.com/thread/2120926 http://ccie-in-3-months.blogspot.com/2009/06/eompls-on-7600-pfc-based-svi-based.html Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld Sent: Wednesday, April 10, 2013 10:56 To: Antonis Vosdoganis Cc: cisco-nsp@puck.nether.net NSP Subject: Re: [c-nsp] Using EoMPLS instead of end to end VLAN You can do port-based EoMPLS quite easily. ME3600: http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/release/12.2_52_ey/configuration/guide/swmpls.html 7600: http://www.cisco.com/en/US/docs/routers/7600/ios/15S/configuration/guide/pfc3mpls.html On 2013-04-10, at 1:14 PM, Antonis Vosdoganis avo...@gmail.com wrote: We have a BGP session with a carrier delivered on ME3600-A. Because ME3600 is not able to carry bgp table we have create vlan 100 and we and made the gigabit port access to vlan 100. 7609 -- ME3600-B - ME3600-A --- BGP SESSION ME3600-A vlan 100 name BGP_PEERING interface GigabitEthernet0/1 description BGP_PEERING switchport access vlan 100 ME3600-A and ME3600-B are interconnected with a trunk port. ME3600-B vlan 100 name BGP_PEERING ME3600-B and 7609 are also interconnected with a trunk port CISCO 7609-S vlan 100 name BGP_PEERING interface Vlan100 description BGP_PEERING ip address XXX.XXX.XXX.XXX 255.255.255.248 In all trunk ports we are using mpls enabled SVIs. So the vlan 100 travels all the way from ME3600-A to 7609 and the bgp session is running on 7609. I am trying to say is it possible to replace the vlan with EoMPLS and how? Best Regards Antonis. ___ cisco-nsp 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] Performance issue on link
+1. Sometimes the shaper does not match with the rate limiting the service provider uses on the link. Reduce the shaper to substantially lower value (35M would be a good start, but maybe even 30M just to make sure). If you see performance go up and work correctly at the shaped rate, start increasing the shaper until you hit the value that reduces performance. You shaper rate has to be lower than the service policy the service provider is enforcing to avoid traffic drops on the circuit. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mikael Abrahamsson Sent: Monday, April 01, 2013 20:38 To: CiscoNSP List Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Performance issue on link On Tue, 2 Apr 2013, CiscoNSP List wrote: class-map match-any MATCH_ANY match any policy-map 40MB_SHAPE class MATCH_ANY shape average 41943040 Try lowering this to 35 megabit/s to make sure you avoid the policer your provider has in place. When you do the tcp testing, do a packet capture on the servers and look for packet loss. Wireshark has excellent TCP analysis tools that can show you exactly what's going on, if the problem is maxed out TCP windows or if it's caused by TCP saw-toothing due to packet loss. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp 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] Performance issue on link
You need to shape your traffic to 40Mbps (or most likely slightly less than that). TCP bursts and your provider drops the traffic, which causes the TCP window to shrink. Your switches cannot shape, so you would have to do it on the routers. Basically, a classic sub-rate link problem: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp61026 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of CiscoNSP List Sent: Monday, April 01, 2013 15:51 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Performance issue on link Hi, We have a 40Mb link between 2 POPs - Latency ~65m/sec (No packet-loss) POP A Is a 7301 and 2960POP B is a 7200 and 4948 40Mb link is connected to the two switches (L2), and then a trunk link to both routers for all L3. Have a Linux server connected to both switches, and achieve the following performance: IPERF (UDP) POP A - POP B - 38.5Mb/secPOP B - POP A - 38.5Mb/sec IPERF (TCP) POP A - POP B - ~20Mb/secPOP B - POP A - ~12Mb/sec FTP POP A - POP B - ~38Mb/secPOP B - POP A - ~16Mb/sec WGET POP A - POP B - ~30Mb/sec POP B - POP A - ~16Mb/sec Any suggestions on why I am seeing poor performance with TCP transfers? (Especially POP B - POP A direction) - I've tried adjusting the window size in IPERF but it actually made the results worse? Thanks in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] Performance issue on link
Yes, you should be shaping on egress. Why are you policing on ingress?! Arie Sent via my mobile phone. Original message From: CiscoNSP List cisconsp_l...@hotmail.com Date: To: Arie Vayner (avayner) avay...@cisco.com,cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Performance issue on link Thanks Arie - I already have the following policy-maps on each router: policy-map 40MBPS class class-default police 41943040 5242880 conform-action transmit exceed-action drop Then on the L3 Ints between the POP's service-policy input 40MBPS service-policy output 40MBPS Should I be shaping rather than policing? From: avay...@cisco.com To: cisconsp_l...@hotmail.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Performance issue on link Date: Mon, 1 Apr 2013 23:20:34 + You need to shape your traffic to 40Mbps (or most likely slightly less than that). TCP bursts and your provider drops the traffic, which causes the TCP window to shrink. Your switches cannot shape, so you would have to do it on the routers. Basically, a classic sub-rate link problem: http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp61026 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of CiscoNSP List Sent: Monday, April 01, 2013 15:51 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Performance issue on link Hi, We have a 40Mb link between 2 POPs - Latency ~65m/sec (No packet-loss) POP A Is a 7301 and 2960POP B is a 7200 and 4948 40Mb link is connected to the two switches (L2), and then a trunk link to both routers for all L3. Have a Linux server connected to both switches, and achieve the following performance: IPERF (UDP) POP A - POP B - 38.5Mb/secPOP B - POP A - 38.5Mb/sec IPERF (TCP) POP A - POP B - ~20Mb/secPOP B - POP A - ~12Mb/sec FTP POP A - POP B - ~38Mb/secPOP B - POP A - ~16Mb/sec WGET POP A - POP B - ~30Mb/sec POP B - POP A - ~16Mb/sec Any suggestions on why I am seeing poor performance with TCP transfers? (Especially POP B - POP A direction) - I've tried adjusting the window size in IPERF but it actually made the results worse? Thanks in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] VPLS PE Redundancy with Supervisor Engine 2T
Steffann, What pay of VPLS doesn't work? Do you see the PW's coming up? LDP? MAC learning? If you share some configs and show command outputs, maybe we can figure it out... Arie Original message From: Sander Steffann san...@steffann.nl Date: To: Andrew Miehs and...@2sheds.de Cc: cisco-nsp cisco-nsp@puck.nether.net Subject: Re: [c-nsp] VPLS PE Redundancy with Supervisor Engine 2T Hi, Sorry - too early in the morning - ignore my last post - thought you were referring to VSS on Sup2T - didnt see the VPLS. :( Yeah, the VSS is no problem. VSL links on the Sup2t and it was up and running in minutes. The VPLS code is the buggy part it seems :-( Cheers, Sander ___ cisco-nsp 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] DDoS help please
I think the easiest way would be to actually create a new ACL on the router, and then change the user's RADIUS profile to use that ACL... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Tuesday, December 11, 2012 12:48 To: Mike Cc: 'Cisco-nsp' Subject: Re: [c-nsp] DDoS help please Hi, On Tue, Dec 11, 2012 at 11:19:08AM -0800, Mike wrote: 53 except to/from my servers. I don't want to cut/paste and create a new access list for this customer, I just want to be able to add some additional rules on top of the default filter set. Surely there has to be a way to do this? Not easily, as IOS only supports a single ingress and a single egress ACL per interface, and you can't include other ACLs. You might trick this by using an *ingress* ACL on the LAN port of your 7201 to drop that particular traffic, or by using QoS to policy these packets down to 1kbit/s... (you can have QoS policies in addition to an egress ACL). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de ___ cisco-nsp 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] LAC for PPPoE with multiple links to LNS
Please see inline. Arie -Original Message- From: Warwick Duncan [mailto:warw...@frogfoot.com] Sent: Wednesday, November 28, 2012 12:46 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LAC for PPPoE with multiple links to LNS Hi Arie On Wed, Nov 28, 2012 at 08:06:31PM +, Arie Vayner (avayner) wrote: The main issue would be that a single L2TP tunnel would hash to a single uplink, and would never load share across different uplinks. So if I understand correctly, the load sharing between LAC and LNS is simply a question of multipath IP routing and nothing to do with PPP? [Arie Vayner (avayner)] The LAC-LNS leg is based on L2TP tunneling, so you need to make sure you have multiple tunnels, and they are load shared using the regular IP multipath solutions. Just remember many PPP sessions can be tunneled on the same L2TP tunnel... Also, multiple tunnels between the same IP pairs still look as the same flow on the IP layer... I think this could be a good reference: http://www.cisco.com/en/US/tech/tk801/tk703/technologies_tech_note09186a008021fd87.shtml What you most likely would have to do is to have multiple IP addresses on the LAC and LNS (loopbacks...), and route them through different links. The LAC can loadshare the sessions between different L2TP tunnels... We only get a single (L3 provider) IP address per layer 3 link so I'm guessing we would have to build something like a GRE tunnel per link and do some OSPF to distribute routes for loopback addresses in our own (probably RFC1918) IP space. It's not ideal but I've certainly done plenty of far uglier hack jobs. [Arie Vayner (avayner)] Not sure why you would need GRE... If you have multiple links, each link would have its own IPs... What you need are now multiple loopbacks on the LNS (and most likely the LAC), and manage your traffic load sharing by routing the L2TP tunnels using the loopback endpoints. Thanks for the help. Regards Warwick Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Warwick Duncan Sent: Wednesday, November 28, 2012 11:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] LAC for PPPoE with multiple links to LNS Hi We're planning a network of a couple of thousand remote sites connecting with PPP to a central router (we're thinking a Cisco ASR 1002-X). For most sites we can get ethernet to the central router and can use PPPoE but for several hundred we have to go via a third party's layer 3 network, where the layout could be as follows: Site 1 -- -- layer 3 upstream -\ Site 2 -- Aggregation point (LAC) -- layer 3 upstream -- ASR (LNS) Site 3 -- -- layer 3 upstream -/ i.e. we connect a handful of sites (between 2 and 20) with ethernet to a central point at which we buy multiple layer 3 upstream links, all from the same provider, to give the required bandwidth. For reasons beyond our control, a single link can't provide adequate bandwidth for even a single site. The obvious starting point, unless we're missing something, is to put an L2TP LAC at the aggregation point and tunnel the PPP to the central ASR, which we configure as an LNS. This achieves our goal of having a PPP session between the ASR and each site. How do we elegantly aggregate the multiple layer 3 links between LAC and LNS into a single logical bundle? If it can't be elegant, what's the least ugly way to do it? I don't think multilink PPP is applicable in this scenario (it would be between Site N and LAC, had the multiple links been there) but I'd happily be proved wrong. It would be nice to guard against equipment failure at the aggregation point. Is there a way to put up 2 LAC's with the upstream links split between them, yet still provide any single site with the full aggregated bandwidth of all upstream links? Lastly, would something like a 3640 be an adequate LAC for, say, 12Mbps upstream (6 x 2Mbps serial links)? Are there any gotchas with doing MPLS over PPP on an ASR 1002-X? Thanks for reading this far... Regards Warwick -- Warwick Duncan Frogfoot Networks ISP http://www.frogfoot.com/ +27.21.448.7225 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Warwick Duncan Frogfoot Networks ISP http://www.frogfoot.com/ +27.21.448.7225 ___ cisco-nsp 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] LAC for PPPoE with multiple links to LNS
The main issue would be that a single L2TP tunnel would hash to a single uplink, and would never load share across different uplinks. What you most likely would have to do is to have multiple IP addresses on the LAC and LNS (loopbacks...), and route them through different links. The LAC can loadshare the sessions between different L2TP tunnels... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Warwick Duncan Sent: Wednesday, November 28, 2012 11:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] LAC for PPPoE with multiple links to LNS Hi We're planning a network of a couple of thousand remote sites connecting with PPP to a central router (we're thinking a Cisco ASR 1002-X). For most sites we can get ethernet to the central router and can use PPPoE but for several hundred we have to go via a third party's layer 3 network, where the layout could be as follows: Site 1 -- -- layer 3 upstream -\ Site 2 -- Aggregation point (LAC) -- layer 3 upstream -- ASR (LNS) Site 3 -- -- layer 3 upstream -/ i.e. we connect a handful of sites (between 2 and 20) with ethernet to a central point at which we buy multiple layer 3 upstream links, all from the same provider, to give the required bandwidth. For reasons beyond our control, a single link can't provide adequate bandwidth for even a single site. The obvious starting point, unless we're missing something, is to put an L2TP LAC at the aggregation point and tunnel the PPP to the central ASR, which we configure as an LNS. This achieves our goal of having a PPP session between the ASR and each site. How do we elegantly aggregate the multiple layer 3 links between LAC and LNS into a single logical bundle? If it can't be elegant, what's the least ugly way to do it? I don't think multilink PPP is applicable in this scenario (it would be between Site N and LAC, had the multiple links been there) but I'd happily be proved wrong. It would be nice to guard against equipment failure at the aggregation point. Is there a way to put up 2 LAC's with the upstream links split between them, yet still provide any single site with the full aggregated bandwidth of all upstream links? Lastly, would something like a 3640 be an adequate LAC for, say, 12Mbps upstream (6 x 2Mbps serial links)? Are there any gotchas with doing MPLS over PPP on an ASR 1002-X? Thanks for reading this far... Regards Warwick -- Warwick Duncan Frogfoot Networks ISP http://www.frogfoot.com/ +27.21.448.7225 ___ cisco-nsp 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] 15.1SY draft-rosen MVPN
The command should be under the IPv4 address family... Router(config)#vrf definition test Router(config-vrf)#address-family ipv4 Router(config-vrf-af)#md Router(config-vrf-af)#mdt ? dataMDT data trees default The default group log-reuse Event logging for data MDT reuse overlay MDT Overlay Protocol preference MDT preference (default pim mldp) Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Monday, November 19, 2012 14:50 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 15.1SY draft-rosen MVPN It's late and I'm tired, so maybe I'm missing something, but after a reload into 15.1SY, our testing sup270 failed to take the mdt commands under VRFs: mdt default 239.254.1.2 ^ % Invalid input detected at '^' marker. The VRFs are all new format vrf definition if that matters, but an old-style ip vrf object doesn't take the command either. There's a bunch of stuff in the config guide about mLDP-based MVPNs and some new l3vpn encap command stuff: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/15.1SY/config_guide/sup720/ipv4_multicast_vpn.html Any ideas anyone? Bug? Cheers, Phil ___ cisco-nsp 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] PBR on sup720
Basically, any 7600/6500 with Sup720 would be able to do PBR in hardware as long as you follow the feature restrictions (see links below). Older releases may have older issues, but the more recent software versions should be fine. The below issue that was fixed in SRD for 7600 was fixed in SXI for 6500. Arie From: Xu Hu [mailto:jstuxuhu0...@gmail.com] Sent: Sunday, November 04, 2012 00:55 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net; Paul Magee Subject: Re: [c-nsp] PBR on sup720 Hi Arie, i heard there should depend on which ios version and which kind of configirations u use will impact the action about hw or software switching. On Nov 1, 2012 12:56 AM, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com wrote: Yes, same concept. Better run on SXI or later to avoid issues with punting to the RP if the next-hop is down... Another option is to use something like that: track 1 interface GigabitEthernet3/1 line-protocol delay up 15 ! track 2 interface GigabitEthernet3/2 line-protocol delay up 15 ! route-map test2 permit 10 match ip address 100 set ip next-hop verify-availability 10.2.3.3 10 track 1 set ip next-hop verify-availability 10.2.2.3 20 track 2 Arie -Original Message- From: Paul Magee [mailto:pma...@williamhill.co.ukmailto:pma...@williamhill.co.uk] Sent: Wednesday, October 31, 2012 09:13 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Hi Arie, Does this also apply to the SX version? Thanks, Paul -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.commailto:avay...@cisco.com] Sent: 31 October 2012 15:59 To: Paul Magee; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments
Re: [c-nsp] PBR on sup720
Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments. William Hill PLC, its subsidiaries and affiliated companies may monitor e-mail traffic data and also the content of e-mails for effective operation of the e-mail system, or for security, purpose! s. * ___ cisco-nsp 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] PBR on sup720
Yes, same concept. Better run on SXI or later to avoid issues with punting to the RP if the next-hop is down... Another option is to use something like that: track 1 interface GigabitEthernet3/1 line-protocol delay up 15 ! track 2 interface GigabitEthernet3/2 line-protocol delay up 15 ! route-map test2 permit 10 match ip address 100 set ip next-hop verify-availability 10.2.3.3 10 track 1 set ip next-hop verify-availability 10.2.2.3 20 track 2 Arie -Original Message- From: Paul Magee [mailto:pma...@williamhill.co.uk] Sent: Wednesday, October 31, 2012 09:13 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Hi Arie, Does this also apply to the SX version? Thanks, Paul -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: 31 October 2012 15:59 To: Paul Magee; cisco-nsp@puck.nether.net Subject: RE: PBR on sup720 Paul, Nop... All packets are handled in HW assuming your actions are supported... Performance should be the same as regular routing as long as it's done in HW and you do not exceed TCAM resources. In some older IOS versions there were issues with what happens when the next hop is not available... Packets were punted to the RP. This is not the case after SRD (I think). Check out: http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/cef.html http://www.cisco.com/en/US/partner/docs/routers/7600/ios/12.2SR/configuration/guide/layer3.html#wp1027016 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Magee Sent: Wednesday, October 31, 2012 08:40 To: cisco-nsp@puck.nether.net Subject: [c-nsp] PBR on sup720 Hello, Does anyone have any experience of using policy based routing with vrf-lite on a Sup 720? I gather that the first packet is handled in software and from that point on the route exists in the cef table. Is that a big performance hit? What sort of throughput/number of connections can I expect to be able to handle before everything comes crashing to its knees? Do Cisco have any figures on this hidden away anywhere? Thanks, Paul --- -- * Confidentiality: The contents of this e-mail and any attachments transmitted with it are intended to be confidential to the intended recipient; and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. This e-mail is sent by a William Hill PLC group company. The William Hill group companies include, among others, William Hill PLC (registered number 4212563), William Hill Organization Limited (registered number 278208), William Hill US HoldCo Inc, WHG (International) Limited (registered number 99191) and WHG Trading Limited (registered number 101439). Each of William Hill PLC, William Hill Organization Limited is registered in England and Wales and has its registered office at Greenside Hou! se, 50 Station Road, Wood Green, London N22 7TP. William Hill U.S. HoldCo, Inc. is 160 Greentree Drive, Suite 101, Dover 19904, Kent, Delaware, United States of America. Each of WHG (International) Limited and WHG Trading Limited is registered in Gibraltar and has its registered office at 6/1 Waterport Place, Gibraltar. Unless specifically indicated otherwise, the contents of this e-mail are subject to contract; and are not an official statement, and do not necessarily represent the views, of William Hill PLC, its subsidiaries or affiliated companies. Please note that neither William Hill PLC, nor its subsidiaries and affiliated companies can accept any responsibility for any viruses contained within this e-mail and it is your responsibility to scan any emails and their attachments. William Hill PLC, its subsidiaries and affiliated companies may monitor e-mail traffic data and also the content of e-mails for effective operation of the e-mail system, or for security, purpose! s. * ___ cisco-nsp 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] Half duplex VRF
Half Duplex VRF can also be supported on regular interfaces. Note the downstream option: http://www.cisco.com/en/US/docs/ios-xml/ios/mpls/command/mp-e1.html#GUID-004281BD-F140-4EA1-BD00-30179140C189t Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil Sent: Tuesday, October 23, 2012 04:52 To: vinzoda.hit...@gmail.com; g...@ax.tc Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Half duplex VRF I have read that the hub and spoke VRF only works with virtual templates ? And , it's supposed to be configured with AAA server right ? Thanks BR, Mohammad Date: Fri, 12 Oct 2012 15:15:55 +0530 From: vinzoda.hit...@gmail.com To: g...@ax.tc CC: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Half duplex VRF Hi Gerald, I have tested this and worked like charm.. thanks for sharing the working configuration. Best Regards Hitesh On Fri, Oct 12, 2012 at 9:02 AM, Hitesh Vinzoda vinzoda.hit...@gmail.comwrote: Hi Gerald, Thanks for your inputs. Will try this configuration and let you know how it goes..! Cheers Hitesh On Thu, Oct 11, 2012 at 9:50 PM, Gerald Krause g...@ax.tc wrote: Hi Hitesh, just to let you know how our working config looks like. We had some problems in the beginning with Half duplex VRF on earlier IOS versions. Now we're running 122-33.SRE on a NPE-G2 and it works as expected. Traffic from site1 to site2 (both terminated via L2TP/PPP on the same LNS) will be directed (egress) to port GE0/3.148 towards the firewall 10.99.16.254 and then back (ingress) on port GE0/3.149 if the firewall permit the traffic. LNS CONFIG == LNS1#sh run vrf CUSTVRF-DOWN Building configuration... Current configuration : 603 bytes ip vrf CUSTVRF-DOWN rd 100:2 route-target export 100:2 route-target import 100:2 ! ! interface GigabitEthernet0/3.149 encapsulation dot1Q 149 ip vrf forwarding CUSTVRF-DOWN ip address 10.99.16.227 255.255.255.240 ! router bgp 1 ! address-family ipv4 vrf CUSTVRF-DOWN no synchronization redistribute connected redistribute static exit-address-family ! end LNS1#sh run vrf CUSTVRF-UP Building configuration... Current configuration : 816 bytes ip vrf CUSTVRF-UP rd 100:3 route-target export 100:3 route-target import 100:1 ! ! interface GigabitEthernet0/3.148 encapsulation dot1Q 148 ip vrf forwarding CUSTVRF-UP ip address 10.99.16.243 255.255.255.240 ! interface Loopback102 description CUSTVRF ip vrf forwarding CUSTVRF-UP ip address 10.99.17.254 255.255.255.255 ! router bgp 1 ! address-family ipv4 vrf CUSTVRF-UP no synchronization redistribute connected redistribute static default-information originate exit-address-family ! ip route vrf CUSTVRF-UP 0.0.0.0 0.0.0.0 10.99.16.254 end RADIUS ACCOUNTS (freeRadius) === cust-vrfsite1 Password == Cisco-AVPair += ip:ip-unnumbered=Loopback102 Cisco-AVPair += ip:addr=10.99.17.68 Cisco-AVPair += ip:vrf-id=CUSTVRF-UP downstream CUSTVRF-DOWN Cisco-AVPair += ip:route=10.98.8.0 255.255.255.0 cust-vrfsite2 Password == Cisco-AVPair += ip:ip-unnumbered=Loopback102 Cisco-AVPair += ip:addr=10.99.17.69 Cisco-AVPair += ip:vrf-id=CUSTVRF-UP downstream CUSTVRF-DOWN Cisco-AVPair += ip:route=10.98.9.0 255.255.255.0 Gerald Am 11.10.2012 07:45, schrieb Hitesh Vinzoda: Hi Arie, This is already in place and the virtual-access interfaces belongs to this vrf and so do their PPP host router. This routes are not visible in upstream vrt U which is great but these routes do appear in Downstream vrf D so that is the reason they route locally and doesnt go towards hub CE. The illustrations that i have seen before have CE sites connected on different PE routers whereas in my case the CE routers are connected to same PE and hence we want to avoid local routing on the LNS. Please let me know your thoughts over this. Thanks Hitesh On Wed, Oct 10, 2012 at 11:27 PM, Arie Vayner (avayner) avay...@cisco.comwrote: So basically your PPP connections are in the global routing table... What is the profile you are downloading from RADIUS (debug radius) for them? ** ** You most likely should be downloading the ip vrf forwarding U downstream D command using the RADIUS attribute lcp:interface-config=ip vrf forwarding U downstream D... http://www.cisco.com/en/US/docs/ios/12_3/feature/guide/ghdpvrf.html#wp1099907 ** ** Arie ** ** *From:* Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.com] *Sent:* Wednesday, October 10, 2012 00:44 *To:* Arie Vayner (avayner) *Cc:* Cisco Mailing list *Subject:* Re: [c-nsp] Half duplex VRF
Re: [c-nsp] Half duplex VRF
So basically your PPP connections are in the global routing table... What is the profile you are downloading from RADIUS (debug radius) for them? You most likely should be downloading the ip vrf forwarding U downstream D command using the RADIUS attribute lcp:interface-config=ip vrf forwarding U downstream D... http://www.cisco.com/en/US/docs/ios/12_3/feature/guide/ghdpvrf.html#wp1099907 Arie From: Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.com] Sent: Wednesday, October 10, 2012 00:44 To: Arie Vayner (avayner) Cc: Cisco Mailing list Subject: Re: [c-nsp] Half duplex VRF Hi Arie, Below is the desired excerpt. We can't see the VRF config being applied to the interfaces but its visible in show ip int virtual-access. I have tried two different way in RADIUS attributes but the results are the same. LNS#show ppp all Interface/ID OPEN+ Nego* Fail- StagePeer AddressPeer Name - --- Vi4 LCP+ CHAP+ IPCP+ LocalT 192.168.254.200 \ sp...@cerberusnetworks.co.ukmailto:sp...@cerberusnetworks.co.uk Vi3 LCP+ CHAP+ IPCP+ LocalT 192.168.254.100 \ m...@cerberusnetworks.co.ukmailto:m...@cerberusnetworks.co.uk LNS#show run int vir LNS#show run int virtual-acc LNS#show run int virtual-access 3 Building configuration... Current configuration : 78 bytes ! interface Virtual-Access3 ip mtu 1492 ip verify unicast reverse-path end LNS#show run int virtual-access 4 Building configuration... Current configuration : 78 bytes ! interface Virtual-Access4 ip mtu 1492 ip verify unicast reverse-path end = LNS#show ip int virtual-access 3 Virtual-Access3 is up, line protocol is up Interface is unnumbered. Using address of Loopback2 (2.2.2.1) Broadcast address is 255.255.255.255 Peer address is 192.168.254.100 MTU is 1492 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF switching turbo vector IP CEF turbo switching turbo vector VPN Routing/Forwarding U Downstream VPN Routing/Forwarding D Associated unicast routing topologies: ipv4 topologies in downstream VRF D : Topology base, operation state is UP ipv4 topologies in upstream(forwarding) VRF U: Topology base, operation state is UP === Thanks Hitesh On Tue, Oct 9, 2012 at 9:52 PM, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com wrote: Hitesh, how does your virtual-access look like for the spokes? Can you please share the show run interface virtual-access xx for the spokes? Tnx Arie From: Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.commailto:vinzoda.hit...@gmail.com] Sent: Tuesday, October 09, 2012 09:05 To: Arie Vayner (avayner) Cc: Cisco Mailing list Subject: Re: [c-nsp] Half duplex VRF Hi Arie, I have attached topology, .Net file and configs of related devices. R8 and R9 are simulating spokes whereas Internet-RTR is simulating Hub. Cheers Hitesh On Tue, Oct 9, 2012 at 8:37 PM, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com wrote: Hitesh, can you maybe share some of your configs? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hitesh Vinzoda Sent: Tuesday, October 09, 2012 07:04 To: Cisco Mailing list Subject: [c-nsp] Half duplex VRF I am trying to setup half duplex vrf to save vrf's on the LNS. Does anyone has working configuration for spokes and Hub connected on the same PE router i.e. LNS. So far i able to export-import the routes but the traces from one spoke to other goes directly via LNS instead of via Hub. Please advise. TIA Hitesh ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto: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] Half duplex VRF
Hitesh, can you maybe share some of your configs? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hitesh Vinzoda Sent: Tuesday, October 09, 2012 07:04 To: Cisco Mailing list Subject: [c-nsp] Half duplex VRF I am trying to setup half duplex vrf to save vrf's on the LNS. Does anyone has working configuration for spokes and Hub connected on the same PE router i.e. LNS. So far i able to export-import the routes but the traces from one spoke to other goes directly via LNS instead of via Hub. Please advise. TIA Hitesh ___ cisco-nsp 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] Half duplex VRF
Hitesh, how does your virtual-access look like for the spokes? Can you please share the show run interface virtual-access xx for the spokes? Tnx Arie From: Hitesh Vinzoda [mailto:vinzoda.hit...@gmail.com] Sent: Tuesday, October 09, 2012 09:05 To: Arie Vayner (avayner) Cc: Cisco Mailing list Subject: Re: [c-nsp] Half duplex VRF Hi Arie, I have attached topology, .Net file and configs of related devices. R8 and R9 are simulating spokes whereas Internet-RTR is simulating Hub. Cheers Hitesh On Tue, Oct 9, 2012 at 8:37 PM, Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com wrote: Hitesh, can you maybe share some of your configs? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hitesh Vinzoda Sent: Tuesday, October 09, 2012 07:04 To: Cisco Mailing list Subject: [c-nsp] Half duplex VRF I am trying to setup half duplex vrf to save vrf's on the LNS. Does anyone has working configuration for spokes and Hub connected on the same PE router i.e. LNS. So far i able to export-import the routes but the traces from one spoke to other goes directly via LNS instead of via Hub. Please advise. TIA Hitesh ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto: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] layer 3 switch vs router....
Scott, The main issue with layer 3 switches is that they are built for LAN environments. The MetroE circuit is most likely a sub-rate link (physical rate is 1GE, downstream SP rate limits to 1Gbps). It means that on your egress port to the MetroE link you need to perform H-QOS, with egress shaping and a child QOS policy for the different traffic classes. Regular LAN switches usually do not support egress shaping. The exception would be the different Metro switches like the ME3600 or ME3800, which could be a good option in your case. Other differences between routers and switches are related to feature support... switches are usually hardware based, and if a feature is not supported in the hardware ASICs, you would not be able to really use it (it might work, but not scale). Examples could be things like IPSec (even though many switches now have 802.1ae MACsec), scaled up routing table sizes etc. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Scott Voll Sent: Wednesday, October 03, 2012 08:25 To: cisco-nsp@puck.nether.net Subject: [c-nsp] layer 3 switch vs router Can anyone fill in the blanks for me? We currently have MetroE connections to all our remote sites. we use a 3845 at the core and 38xx or 28xx to all the remote sites. Current connections are 200mb. Remote sites are Voice Routers, and do FW / IPSec VPN backup to the Core in case of WAN failure. If I move my remote site Routers back, and put a Layer 3 switch in front to do the routing (wire speed) what will I lose? Do I lose QoS flexiblity? I should still be able to do my backup VPN with the current Router as it only has about a 20mb backup link and will still be a routing peer. Is there anything else I might loose by moving to a Layer 3 switch rather than a 2951? Any suggestions as to a Layer 3 switch to use? 3750x? I only need 48 1 gig ports. 49xx? Other thoughts? TIA Scott ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS Tutorial or Guide?
Seth, You could try the Configuration Guides... MPLS Config Guide Home: http://www.cisco.com/en/US/partner/docs/ios-xml/ios/mpls/config_library/15-1mt/mp-15-1mt-library.html General MPLS: http://www.cisco.com/en/US/partner/docs/ios-xml/ios/mp_basic/configuration/15-1mt/mp-mpls-overview.html Layer 2 VPN (as you mentioned xconnects) http://www.cisco.com/en/US/partner/docs/ios-xml/ios/mp_l2_vpns/configuration/15-1mt/mp-l2-vpns-15-1mt-book.html I would still recommend reading the book... At least the basic stuff. You may turn it on, but things would seem weird if you do not really understand what's going on in the background... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Seth Mattinen Sent: Monday, September 17, 2012 10:47 To: cisco-nsp@puck.nether.net Subject: [c-nsp] MPLS Tutorial or Guide? Does anyone have a good intro or beginner's guide to MPLS that they like? Something succinct and focused that's not a 500 page my-first-Cisco book. The situation I'm thinking is putting someone in front of some routers and switches in a lab setting and saying take these and set them up to do MPLS and create some xconnects for simulated customers with the assumption that they already have Cisco experience and can build a non-MPLS network, but who is new to MPLS alone. ~Seth ___ cisco-nsp 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] l2tpv3
Aaron, You should be able to deploy L2TPv3 with the smaller ISR routers... The 800 series support it (not sure what software feature set is needed...) Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Thursday, August 30, 2012 08:27 To: cisco-nsp@puck.nether.net Subject: [c-nsp] l2tpv3 What is the smallest/cheapest cisco router that supports L2TPv3? I work at an isp and have small/medium sized businesses that occasionally want transparent lan connectivity between their sites (which are connected via FTTH, DSL, Cable Modem). Is L2TPv3 tunneling the way to go for something like that ? I don't really want to set up all kinds of qinq or mpls l2vpn's in my core if I can avoid it. Also, tunneling endpoints at the customer premise seems that the dslam/olt/cmts would not have to be wise at all about the tunneling architecture. Lemme know your thoughts/suggestions please Aaron ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS over GRE/IPSEC
Well, ASR1K can do MPLSoGREoIPSec Encryption is done in HW on a dedicated resource, so it does not impact performance (but has its own capacity per ESP module type, which is way above 1Gbps on any of the models) The QOS marking would be based on precedence (only 3 bits), as the original IP DSCP is applied to the 3 MPLS EXP bits, and then copied to the external IP header... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andrew Miehs Sent: Wednesday, August 08, 2012 04:36 To: Gert Doering Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS over GRE/IPSEC Sent from a mobile device On 08/08/2012, at 21:11, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Aug 08, 2012 at 01:50:21PM +0300, Aivars wrote: Alright, sorry. Missed the part about 1G. In that case I agree, that the smallest ASR1k will be needed. Can the ASR1k *do* this, as in it is implemented, officially supported, and documented to work? I have had an ASR1001 running mpls over gre working. It wasn't encrypted however - and at the time we were only pushing about 50mbits per sec without an issue. On a new site I would probably do this with sup2t in the 6500s. Will ask at my old company how tge ASRs are doing Andrew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS over GRE/IPSEC
I would recommend looking at the lower end ASR1Ks for that... Maybe ASR1001... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Tuesday, August 07, 2012 04:24 To: cisco-nsp@puck.nether.net Subject: [c-nsp] MPLS over GRE/IPSEC What is the smallest Cisco device that can do 1Gbit/sec of MPLS over GRE over IPSEC? On the LAN side, the device will need to do VLANS, IPv4 IPv4, HSRP, multicast and possibly some basic QoS for VoIP prioritisation. On the WAN side, the device will need to tunnel MPLS L3VPN over GRE, then IPSec-protect the GRE traffic. Obviously it will need BGP/LDP. Physical interfaces will need to be 2x gigE, and the device will actually need to forward 1gig or very close to it. The background here is that we have some remote sites we want to bring back into our MPLS L3VPN. We can obtain an IP connection with large MTU more cheaply than we can obtain an ethernet circuit, and we've been asked to price up some options. Personally I think this architecture would be needlessly complex and likely more expensive, but I need to know what kit would be needed before I can price it up. If anyone has any more general comments (e.g. don't do it for reason X) I'd be interested to hear them. Cheers, Phil ___ cisco-nsp 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] show ip cache flow is slow
Hank, I think it is related to CSCtc38611 need performance enhancements to 'show ip cache flow' on ASR1k Symptom: show ip cache flow and show ip cache flow | include WORD may take a very long time to run Conditions: Several thousand flows being learned Workaround: Use show ip cache x.x.x.x flow to see specific flows Basically, ASR1000 is a distributed platform, and the cache info is stored on ESP (forwarding path). It means that every time you issue this command it would have to transfer the whole table to the RP... If you use the | include option, it still has to transfer the whole file, and then apply the regexp on the text... If you want to do multiple searches on a large table, the best solution would most likely be to copy the output to a file, and then use that file... If you want to monitor a specific flow, using the specific command above works faster, as it does not transfer the whole file... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Hank Nussbacher Sent: Sunday, July 01, 2012 07:47 To: cisco-nsp@puck.nether.net Subject: [c-nsp] show ip cache flow is slow Ever since we switched to ASR1004 running XE15.1(2)S1, we have seen that the output of show ip cache flow stalls and is super slow to complete. We have a few interfaces with ip flow ingress defined. What can be causing this slowness? Any recommendations of commands to speed up the output? Thanks! -Hank ___ cisco-nsp 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] 7600 w/ WS-SUP720-3B IOS 15.x
15.1s should be fine. Sent from my HTC One™ X - Reply message - From: Xu Hu jstuxuhu0...@gmail.com To: N. Max Pierson nmaxpier...@gmail.com Cc: Cisco Mailing list cisco-nsp@puck.nether.net Subject: [c-nsp] 7600 w/ WS-SUP720-3B IOS 15.x Date: Wed, Jun 27, 2012 21:01 Actually we will use 15.1s for the feature support of OSPFv3 between PE CE next month. If you don't need any new special features, maybe SRE5 is a better choose, you know the 15.1s released in the March, should be some unknown bugs. HTH Xu Hu On 28 Jun, 2012, at 6:48, N. Max Pierson nmaxpier...@gmail.com wrote: Hi List, Anyone out there running 7600 with 15.x code train in production?? We have a pair of 7609's in one of our data centers acting as a WAN aggregation block and seem to have hit a bug that's affecting some BGP functionality and would like to upgrade IOS. We're currently running SRC1 which is a little dated and would like to see about going to 15.x, but wanted to ping a few people on the list to see if there were any issues known with making this big of a jump in code or if there were any horror stories running 15.x on this platform. 15.1 is what we were looking at, but not opposed to 15.2 if there's no real concerns. Features list: BGP (acting as RR's) EIGRP WCCP Netflow Minimal QoS Nothing exotic, but this particular bug (which we have not gotten anything back from TAC yet) is a PITA and I know that the response is probably going to be an upgrade. Regards, Max ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 Etherchannel Workaround for 7600 15.2 (Configuration Concerns)
Xu Hu, I am not sure which restriction you are mentioning here... I am not aware of such a restriction... Could you explain a bit better your setup? I guess your ES+ is facing your customers with EVCs (UNI), and not sure what you have on the core facing side. Maybe if you share some of the configuration showing the relevant piece, and explain where you want to have IPv6 enabled, I could try and help... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Xu Hu Sent: Tuesday, June 26, 2012 21:09 To: cisco-nsp@puck.nether.net; 许虎 Subject: [c-nsp] IPv6 Etherchannel Workaround for 7600 15.2 (Configuration Concerns) Hi Experts, Since IPv6 Etherchannel cannot support for Cisco IOS so far, one of the solution is using the GRE tunnel sending traffic through port-channel, hence using the bandwidth. My IPv6 new deployment is dual-stack, since my IPv4 Etherchannel have many sub-interface configuration and also the EVC configuration (Using ES+ line card for Port-channel), now i am wondering how to configure such parts when IPv6 is deploying. Using sub-interface under Tunnel? For the IPv6 Etherchannel workaround, can check below website from Cisco community: https://supportforums.cisco.com/docs/DOC-24915 Will appreciate for any comments about this. Best regards, Hu Xu ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IPv6 Etherchannel Workaround for 7600 15.2 (Configuration Concerns)
I am actually not sure why you say Etherchannel cannot support IPv6… I do not really get your config… You have an EVC (service instance) 1292 facing the customer connection, and the service here is “bridge-domain 1292”. We see the SVI (int vlan 1292) configured with an IPv4 service, so if you need to give your customer an IPv6 service, you would just have to configure IPv6 on the same SVI… What I do not understand is the “interface Port-channel1.1603” part. Is this for another customer without EVC? Basically, I do not see a reason why you should not be able to add IPv6 configuration on the same subinterface… Thanks Arie From: Xu Hu [mailto:jstuxuhu0...@gmail.com] Sent: Tuesday, June 26, 2012 21:45 To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IPv6 Etherchannel Workaround for 7600 15.2 (Configuration Concerns) Hi Arie, Thanks for your quick response, below is part of my configuration for IPv4. interface Port-channel1 no ip address no ip redirects no ip proxy-arp service instance 1292 ethernet encapsulation dot1q 1292 rewrite ingress tag pop 1 symmetric bridge-domain 1292 interface Vlan1292 ip address 10.252.99.67 255.255.255.240 no ip redirects no ip proxy-arp standby 2 ip 10.252.99.65 standby 2 preempt standby 2 track 1 decrement 20 For this part, perhaps i need to explain. Usually the EVC is configured faced the customer side, but my customer also configure between the core router for HSRP heartbeat. If IPv6 cannot support EtherChannel, how i transform such configuration? Can help to recommend? interface Port-channel1.1603 encapsulation dot1Q 1603 ip vrf forwarding ip address 10.254.9.10 255.255.255.252 no ip redirects no ip proxy-arp ip ospf hello-interval 1 ip ospf priority 255 ip ospf retransmit-interval 3 ! This part is for the sub-interface under EtherChannel, i am wondering in the IPv6 situation should i configure the sub-interface under Tunnel? Will appreciate for your help. Best Regards, Hu Xu 2012/6/27 Arie Vayner (avayner) avay...@cisco.commailto:avay...@cisco.com Xu Hu, I am not sure which restriction you are mentioning here... I am not aware of such a restriction... Could you explain a bit better your setup? I guess your ES+ is facing your customers with EVCs (UNI), and not sure what you have on the core facing side. Maybe if you share some of the configuration showing the relevant piece, and explain where you want to have IPv6 enabled, I could try and help... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Xu Hu Sent: Tuesday, June 26, 2012 21:09 To: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net; 许虎 Subject: [c-nsp] IPv6 Etherchannel Workaround for 7600 15.2 (Configuration Concerns) Hi Experts, Since IPv6 Etherchannel cannot support for Cisco IOS so far, one of the solution is using the GRE tunnel sending traffic through port-channel, hence using the bandwidth. My IPv6 new deployment is dual-stack, since my IPv4 Etherchannel have many sub-interface configuration and also the EVC configuration (Using ES+ line card for Port-channel), now i am wondering how to configure such parts when IPv6 is deploying. Using sub-interface under Tunnel? For the IPv6 Etherchannel workaround, can check below website from Cisco community: https://supportforums.cisco.com/docs/DOC-24915 Will appreciate for any comments about this. Best regards, Hu Xu ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto: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] m-vpn
Usually, the starting point would be here: http://www.cisco.com/cisco/web/psa/default.html?mode=prod The specific page you are looking for is here: http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r 4.1/multicast/configuration/guide/mc41mcst.html#wp2631058 http://www.cisco.com/en/US/partner/docs/routers/asr9000/software/asr9k_r 4.1/multicast/configuration/guide/mc41mcst.html#wp2631629 (This is for ASR9K...) Arie -Original Message- From: Aaron [mailto:aar...@gvtc.com] Sent: Tuesday, May 29, 2012 08:19 To: Arie Vayner (avayner); cisco-nsp@puck.nether.net Subject: RE: [c-nsp] m-vpn Thanks Arie, I'm trying to accomplish in ios xr 4.1.2 - got link for that ? -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: Tuesday, May 29, 2012 10:15 AM To: Aaron; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] m-vpn Aaron, The MDT BGP address family syntax is relatively new, so might not have been around when the book was released... For a more recent source of information, I would suggest: http://www.cisco.com/en/US/partner/docs/ios-xml/ios/ipmulti_mvpn/configu ration/15-2mt/imc-mvpn-15-2mt-book.html Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Aaron Sent: Tuesday, May 29, 2012 07:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] m-vpn Hi all, I've read through Chapter 7 of MPLS and VPN Architectures Volume II regarding Multicast VPN. I never saw any mention of enabling the ipv4 mdt address family under bgp. Is this ipv4 mdt af something altogether different than what is spoken of in the book ? .or did I totally miss something in that chapter about the ipv4 mdt af being implicitly enable somehow. I'm just trying to accomplish mcast over my mpls L3VPN. This will be for my high capacity mcast for catv for all my catv subscribers. 2-3 gbps sustained 24x7. A couple different pe/ce will xmit and a couple different pe/ce will rcv. I'd prefer to use ssm cause I don't wanna mess with rp's and sup-optimal routing to and from rp and single point of failure on rp (so I don't wanna mess with redundant rp either if I can simply do ssm) Aaron ___ cisco-nsp 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] VFI LDP transport signaled down (ME3600x)
Ihsan,
On which IOS version are you?
This should work on 15.2S
Arie
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ihsan Junaidi
Ibrahim
Sent: Wednesday, May 09, 2012 07:37
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] VFI LDP transport signaled down (ME3600x)
Hi all,
My topology as follows:
PE1--P1--P2--P3--P4--P5--PE2
PE1 lo0 - 200.28.0.15 (15.2(2)S) loader 12.2(52r)EY1
PE2 lo0 - 200.28.0.120 (15.2(2)S) loader 12.2(52r)EY2
Are there specific nuances for an LDP signaled transport for EoMPLS and
VPLS in the Whales platform?
An xconnect from PE1 to PE2 is signaled successfully however a VPLS
instance based on BGP autodiscovery (manual VPLS works) is unable to
bring up the LDP l2transport signal although the VFI is signaled up.
EoMPLS
es-103-glsfb#sh xconnect peer 200.28.0.120 vc 5070
Legend:XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=DownAD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2
S2
--+-+--+
-+--
UP pri ac Gi0/19:1(Ethernet) UP mpls 200.28.0.120:5070
UP
es-103-glsfb#sh mpls l2transport vc 5070 detail Local interface: Gi0/19
up, line protocol up, Ethernet:1 up
Destination address: 200.28.0.120, VC ID: 5070, VC status: up
Output interface: Te0/2, imposed label stack {298 16}
Preferred path: not configured
Default path: active
Next hop: 200.28.2.242
Create time: 02:10:43, last status change time: 02:08:57
Signaling protocol: LDP, peer 200.28.0.120:0 up
Targeted Hello: 200.28.0.15(LDP Id) - 200.28.0.120, LDP is UP
Status TLV support (local/remote) : enabled/supported
LDP route watch : disabled
Label/status state machine: established, LruRru
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not sent
Last BFD peer monitor status rcvd: No fault
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLVstatus rcvd: No fault
Last remote LDP ADJstatus rcvd: No fault
MPLS VC labels: local 17, remote 16
Group ID: local 0, remote 0
MTU: local 9178, remote 9178
Remote interface description:
Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
Dataplane:
SSM segment/switch IDs: 45083/8194 (used), PWID: 2
VC statistics:
transit packet totals: receive 24, send 21
transit byte totals: receive 2064, send 1344
transit packet drops: receive 0, seq error 0, send 0
VPLS
es-103-glsfb#sh vfi
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: ME002555, state: up, type: multipoint signaling: LDP
VPN ID: 116, VPLS-ID: 9930:116
RD: 9930:116, RT: 9930:116
Bridge-Domain 116 attachment circuits:
Vlan116
Neighbors connected via pseudowires:
Peer Address VC IDDiscovered Router IDS
200.28.9.146 116 200.28.0.120Y
es-103-glsfb#sh mpls l2transport vc 116 detail Local interface: VFI
ME002555 vfi up
Interworking type is Ethernet
Destination address: 200.28.0.120, VC ID: 116, VC status: down
Last error: Local access circuit is not ready for label advertise
Next hop PE address: 200.28.9.146
Output interface: none, imposed label stack {}
Preferred path: not configured
Default path: no route
No adjacency
Create time: 02:07:55, last status change time: 02:07:55
Signaling protocol: LDP, peer unknown
Targeted Hello: 200.28.0.15(LDP Id) - 200.28.9.146, LDP is DOWN, no
binding
Status TLV support (local/remote) : enabled/None (no remote
binding)
LDP route watch : disabled
Label/status state machine: local standby, AC-ready,
LnuRnd
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not sent
Last BFD peer monitor status rcvd: No fault
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: Not sent
Last local LDP TLV status sent: None
Last remote LDP TLVstatus rcvd: None (no remote binding)
Last remote LDP ADJstatus rcvd: None (no remote binding)
MPLS VC labels: local 23, remote unassigned
AGI: type 1, len 8, 000A 26CA 0074
Local AII: type 1, len 4, DF1C 000F (200.28.0.15)
Remote AII: type 1, len 4, DF1C 0078 (200.28.0.120)
Group ID: local n/a, remote unknown
MTU: local 9178, remote unknown
Remote interface description:
Sequencing: receive disabled, send disabled
Control Word: On (configured: autosense)
Dataplane:
SSM segment/switch IDs: 0/0 (used), PWID: 14
VC statistics:
Re: [c-nsp] 7206 LNS/L2TP using HSRP
Better use discrete IP addresses. Loopbacks are mostly recommended. On your LAC you can specify multiple IPs (that can come from RADIUS...). This would allow you to load share, running your LNSs in Act/Act mode... Look here: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800a43e9.shtml#wp1002265 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of ar Sent: Thursday, May 03, 2012 00:37 To: cisco-nsp Subject: [c-nsp] 7206 LNS/L2TP using HSRP Guys, I'm planning to terminate L2TP to LNS using HSRP. So there will be LNS redundancy. Is this possible? I've read that terminating L2TP to the HSRP address has some issues. Or better to use multiple initiate-to commands on the LAC? Any other options for fail-over/redundancy? thanks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 7206 LNS/L2TP using HSRP
With HSRP, every time you do a failover, all sessions would drop, and have to be reestablished. Using the redundancy model, you can have graceful recovery and switchover if you want to control it. For example, if you had a failure, and one LNS went down, all sessions would reestablish on the 2nd one (that is the same as in HSRP), but now when the other box comes up it does not drop all the sessions again and switches them back. Only new sessions would be sent to the recovered LNS, and you can move the other sessions during a maintenance window... Actually, I would just suggest running them in active/active mode. This way you actually know they are both up and running and do not have to worry about making sure the backup is ready... Arie From: ar [mailto:ar_...@yahoo.com] Sent: Thursday, May 03, 2012 07:27 To: Arie Vayner (avayner); cisco-nsp Subject: Re: [c-nsp] 7206 LNS/L2TP using HSRP Thanks Arie. Any disadvantage of using HSRP compared to multiple initiate-to commands on the LAC? I want HSRP due to the reason i can control who is the active and standby LNS. LNS is mine, while LAC is on the access provider side. thanks From: Arie Vayner (avayner) avay...@cisco.com To: ar ar_...@yahoo.com; cisco-nsp cisco-nsp@puck.nether.net Sent: Thursday, May 3, 2012 7:09 PM Subject: RE: [c-nsp] 7206 LNS/L2TP using HSRP Better use discrete IP addresses. Loopbacks are mostly recommended. On your LAC you can specify multiple IPs (that can come from RADIUS...). This would allow you to load share, running your LNSs in Act/Act mode... Look here: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper0918 6a00800a43e9.shtml#wp1002265 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of ar Sent: Thursday, May 03, 2012 00:37 To: cisco-nsp Subject: [c-nsp] 7206 LNS/L2TP using HSRP Guys, I'm planning to terminate L2TP to LNS using HSRP. So there will be LNS redundancy. Is this possible? I've read that terminating L2TP to the HSRP address has some issues. Or better to use multiple initiate-to commands on the LAC? Any other options for fail-over/redundancy? thanks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco Crashinfo file
Most likely the best option would be to open a TAC case. Some of the info in there requires internal tools (for example decoding software tracebacks) Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of bha Qaqish Sent: Tuesday, May 01, 2012 00:25 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco Crashinfo file Dear Am having router with crashinfo file . I opened the file and its big. How can I analyze the file , and is there any software for it BR Bha Qaqish ___ cisco-nsp 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] ASR-1K problem with old PPPoE clients.
Ariel, Did you try to capture some sniffer traces of the PPPoE packets for working and non-working clients? This could give us some hint... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ariel Weher Sent: Monday, April 23, 2012 10:23 To: cisco-nsp@puck.nether.net Subject: [c-nsp] ASR-1K problem with old PPPoE clients. Hi folks! I'm facing some problems with our brand new asr 1002's. We're having some issues with the clients being migrated from the old 7200-NPEG1 to the new BRAS with the following symptoms: The client (mostly old OSes like W2K and very old linux like debian potato) connects successfully, got an IP address and all of the PPP parameters, there is no traffic between the user and the net. Other users connects to the same BRAS without problems. This is a brief of our probes while using icmp to test the client reachability: BRAS - Client [OK] BRAS - Client (Source interface other than Loopback) [OK] Client - BRAS (Any interface) [FAIL] Client - any IP [FAIL] Any other host in the network - Client [FAIL] The routes exists in the tables of all of our routers and Any host of the net - BRAS (Any local interface) [OK] The configs are very basic, like asr-config ip name-server 8.8.8.8 ip name-server 8.8.4.4 ! bba-group pppoe PPPoE virtual-template 1 sessions per-mac limit 1 sessions per-vlan limit 16000 sessions per-mac throttle 3 30 120 sessions auto cleanup ! interface Loopback0 description Services ip address 200.3.M.N 255.255.255.255 ip ospf 1 area 0 ! interface Loopback110 description OSPF Sum 190.X.Y.0/24 ip address 190.X.Y.1 255.255.255.255 ip ospf 1 area 400 ! ! Multiple (50+) VLAN subif's like this ! interface GigabitEthernet0/0/2.60 description PPPoEoVLAN 60 encapsulation dot1Q 60 pppoe enable group PPPoE ! interface Virtual-Template1 ip unnumbered Loopback0 peer default ip address pool PPPoE-POOL ppp authentication pap ! router ospf 1 router-id 200.3.M.N log-adjacency-changes detail auto-cost reference-bandwidth 1 area 400 range 190.X.Y.0 255.255.255.0 ! ip local pool PPPoE-POOL 190.X.Y.2 190.X.Y.254 /asr config And the show version: Cisco IOS Software, IOS-XE Software (PPC_LINUX_IOSD-ADVENTERPRISEK9-M), Version 15.1(2)S, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2011 by Cisco Systems, Inc. Compiled Thu 24-Mar-11 23:29 by mcpre There are several clients connected to the router and a very little part of them doesn't get the service. sh pppoe sum PTA : Locally terminated sessions FWDED: Forwarded sessions TRANS: All other sessions (in transient state) TOTAL PTA FWDED TRANS TOTAL42214220 0 1 GigabitEthernet0/0/2 42214220 0 1 The TAC has no responses to give about this problem, and it's happening in all of our new ASR. If you have any experience about an incident like this, please drop me a few lines. AFAIK there is no distinction about the L2 equipment serving the customers. If I pass the whole VLAN to our old BRAS all of the clients works fine in the 7200 with the same config. All of your suggestions are welcome. Thanks for your time. Regards. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IP helper-address source from loopback?
Jay, Take a look here... I think this should do the trick. http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_dhcps ervidlink_mcp.html#wp1058967 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jay Hennigan Sent: Tuesday, March 20, 2012 07:37 To: cisco-nsp@puck.nether.net Subject: [c-nsp] IP helper-address source from loopback? We have a setup where an external global DHCP server is used to assign pools within a few VRFs on 7206VXR, IOS 12.4. Interface configuration looks like this: interface Port-channel1.3004 description Test encapsulation dot1Q 3004 ip vrf forwarding net21 ip address 10.21.97.126 255.255.255.192 ip helper-address global w.x.y.z We're using option 82 to communicate the vrf subnet information and it all works well. The problem that I'm trying to solve is to use a loopback as the global source interface from which the DHCP requests originate. With the above configuration the router uses the closest egress interface to the DHCP server. This is quite usable but I'd prefer it originate on a loopback for cleanliness and redundancy. IOS has tweaks to manipulate the source address of telnet, RADIUS, ftp, tftp, rcmd, and the like but I don't see an obvious way to specify the source of the DHCP relay packets. I'm considering attempting a local route-map as a possible solution but that seems like a pretty big hammer for a small tweak if it works at all. Any suggestions from the assorted Cisco wizards? -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp 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] PPPOE pass through Cisco Routers
Hi, You most likely need to look into Layer 2 VPN options... Either over MPLS (EoMPLS/ATOM/VPLS) or over IP using L2TPv3. Be careful with MTU... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Cipriano Montero, Infostock Sent: Tuesday, March 20, 2012 14:07 To: cisco-nsp@puck.nether.net Cc: Juan Luis Hoyo Herbello Subject: [c-nsp] PPPOE pass through Cisco Routers As an environment as Wireless ISP, we are trying to deliver PPPOE connections to our clients, in a routed network. So, our first problem is to pass through PPPoE protocol over one or several cisco routers. Could somebody help us with this task? Thanks very much in advance. Gracias y saludos, Cipriano Montero ___ cisco-nsp 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] About a post made from user l...@cisco.com
Hi, Well, OTV is there to mostly allow L2 interconnections across an IP cloud, while FabricPath is mostly designed to scale up the L2 domain in a really large L2 environment (often in the same location). Mind you, this is a very simplistic view of both technologies, which would most likely require a couple of hours to cover completely... For Layer 2 DCI there are quite a few other solutions you may look at. The differences are around scale, capacity (bandwidth/number of vlans/hosts etc), convergence speeds, available infrastructure (IP, MPLS etc), and some other factors. Some references: http://www.cisco.com/en/US/netsol/ns975/index.html http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_p aper_c11_493718.html http://blogs.cisco.com/datacenter/introduction-to-%E2%80%9Ccisco-datacen ter-interconnect-dci%E2%80%9D/ Also, I would recommend this Cisco Press book: http://www.ciscopress.com/bookstore/product.asp?isbn=1587059924 Layer 2 DCI is most likely something you want to discuss with your account team, as there are quite a few pit falls as well as quite a few different design alternatives. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nargos Ftw Sent: Monday, March 12, 2012 19:26 To: cisco-nsp@puck.nether.net Subject: [c-nsp] About a post made from user l...@cisco.com Hello. Hope you read it. I was on google looking for information about differences between OTV and Fabricpath and found this post of yours: http://www.gossamer-threads.com/lists/cisco/nsp/134263?do=post_view_thre aded#134263 In that post, you mention that: OTV is a technology that allows us to extend L2 across any L3 (IP) infrastructure. Cisco Fabric Path is in essence the ability to run L2 networks without spanning tree and all links active. I have 2 datacenters and must extend 2 VLANs. So i tought Wow, thats OTV for sure. Then, after researching a little i found that Fabricpath would do the job too. All i need is interconnect 2 DCs with DWDM and 2 VLANs must be extended. Fabricpath is cheaper than OTV. I feel dumb, but i cant see the difference between them. Both maps L2 address dynamically. Both uses routing logic. I know that cisco recommends OTV in this case, but Fabricpath would work fine. *What should i do and could you please show me the differences between OTV and Fabricpath?* All i see on cisco webpage are presales webpages and configuration guides. Thank you so much. ___ cisco-nsp 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 EFA progress
Hi, You need to request this from the TAC engineer BEFORE you start the RMA process. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of ?? Sent: Thursday, February 23, 2012 13:00 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco EFA progress Hey Guys, Is anyone know the EFA progress of Cisco RMA? The customer need us to do the analysis, they need the EFA report. Thanks and Regards, Hu Xu ___ cisco-nsp 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] 7200 LNS - QOS/shaper on interface facing LAC
Can you please share the complete config you are trying to apply? Tnx Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of ar Sent: Monday, February 20, 2012 14:29 To: cisco-nsp Subject: [c-nsp] 7200 LNS - QOS/shaper on interface facing LAC Hi. I've posted this topic before. But just to update I have 7200 acting as LNS. I have multiple QOS for the subscribers via Radius. One GE interface of the 7200 LNS is facing to LAC. I am trying to attach a QOS/shaper policy on this GE interface. I am getting an error of: user-defined classes with queueing features are not allowed in a service-policy at sub-interface/pvc in conjunction with session based queueing policy My guess is: It seems individual LNS QOS for subscribers cant really go with LAC QOS on the same LNS router. I hope someone can confirm this (config-subif)#service-policy output VIAIP-LAC-8M user-defined classes with queueing features are not allowed in a service-policy at sub-interface/pvc in conjunction with session based queueing policy ___ cisco-nsp 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] DHCP Isolation
I would suggest you look at Private VLANs (PVLANs). Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rich Trinkle Sent: Thursday, February 16, 2012 23:28 To: cisco-nsp@puck.nether.net Subject: [c-nsp] DHCP Isolation I have a DHCP pool setup on a 7206 and then trunk that vlan to a 3750 that feeds out to multiple sites/pc's. For those pc's that are not sitting behind a router at the remote location, they are able to do a network scan and pick up all other devices that are on this same subnet (DHCP pool) that are also directly plugged in with no router. My question is this. How do I create isolation in that DHCP subnet/vlan so no one device and see another device within the same pool? Thank you in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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 layer 2 local switching: EVC to SVI
Tassos, I do not think so, as the SVI would be the local switching/mac learning resource in this case... On 7600 any service which requires L2 switching (and/or L3 routing) requires an SVI. Even if you configure a layer 3 sub-interface, an internal SVI is allocated... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos Chatzithomaoglou Sent: Saturday, February 04, 2012 10:36 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 7600 layer 2 local switching: EVC to SVI Similar to this case, is there a way (or any future plans) to connect an EVC directly to a VFI? Currently i'm using EVC = SVI = VFI, but i would like to avoid the intermediate step, something that ASR9k can already do. -- Tassos Jason Lixfeld wrote on 3/2/2012 23:24: Ah-so. This worked like a charm. Thanks Arie (and other off-list replies that eluded to the same thing). On 2012-02-03, at 2:45 PM, Arie Vayner (avayner) wrote: Jason, The local connect option (connect ... CLI) is used to connect 2 EVCs together, without a shared SVI between them. This is basically the local alternative of a p2p xconnect. If you want to use local switching, through an SVI (mac learning etc, but allows also using non-EVC access ports), you just use the bridge-domain VLAN-ID command inside both EVCs. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld Sent: Friday, February 03, 2012 20:37 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7600 layer 2 local switching: EVC to SVI I'm planning to upgrade a 7600/Sup720 from 12.2(33)SRC4 to 12.2(33)SRE5 and in the process migrate some carrier connections to EVCs which will require layer 2 local switching to connect the locally significant VLAN ID of the EFP to the global VLAN. The command set between SRC and SRE seems to differ somewhat and I'm having a hard time getting EVC to SVI based local switching working. On another 7600, I'm running an engineering build of SRE that was provided to me by my SE to test a commit for an outstanding bug. I was hoping this other device and engineering build would be adequate to use as an SRE test bed. The engineering build seems to be based on the Advanced Enterprise Services feature set, not the Advanced IP Services feature set that we will actually be using. I'm trying to lab up the EVC to SVI local switching config, but it's giving me problems and I'm not sure if it's the engineering build that is causing me grief or if what I want to do just won't work. As you can imagine, I'd like to try and get this all proved out ahead of time so there are no gotchas during the upgrade. The issue I'm running into in the engineering build is that the parser is expecting a service instance identifier after the VLAN identifier, which doesn't jive; can't make an EFP on an SVI: 7600#sh run int g7/0/0 Building configuration... Current configuration : 238 bytes ! interface GigabitEthernet7/0/0 description NNI Testing Port mtu 9216 no ip address speed 1000 mls qos trust dscp no cdp enable service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric ! end 7600#sh run int vlan 100 Building configuration... Current configuration : 40 bytes ! interface Vlan100 no ip address end 7600#conf t Enter configuration commands, one per line. End with CNTL/Z. 7600(config)#connect test gi7/0/0 100 vlan 100 ? 1-4294967295 Service Instance Identifier 7600(config)# The SRC parser seems to think different: 7600#sh run int g7/0/17 Building configuration... Current configuration : 227 bytes ! interface GigabitEthernet7/0/17 description NNI Testing Port mtu 9216 no ip address mls qos trust dscp no cdp enable service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric ! end 7600#sh run int vlan 100 Building configuration... Current configuration : 40 bytes ! interface Vlan100 no ip address end 7600#conf t Enter configuration commands, one per line. End with CNTL/Z. 7600(config)#connect test gi7/0/17 100 vlan 100 ? 1-4294967295 Service Instance Identifier interworkingConfigure Interworking Type for this connection 7600(config)#connect test gi7/0/17 100 vlan 100 interworking ethernet 7600(config-connection)# Anyone know if production SRE5 Advanced IP Services is similar to what works in SRC? Thanks in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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 layer 2 local switching: EVC to SVI
Jason, The local connect option (connect ... CLI) is used to connect 2 EVCs together, without a shared SVI between them. This is basically the local alternative of a p2p xconnect. If you want to use local switching, through an SVI (mac learning etc, but allows also using non-EVC access ports), you just use the bridge-domain VLAN-ID command inside both EVCs. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld Sent: Friday, February 03, 2012 20:37 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7600 layer 2 local switching: EVC to SVI I'm planning to upgrade a 7600/Sup720 from 12.2(33)SRC4 to 12.2(33)SRE5 and in the process migrate some carrier connections to EVCs which will require layer 2 local switching to connect the locally significant VLAN ID of the EFP to the global VLAN. The command set between SRC and SRE seems to differ somewhat and I'm having a hard time getting EVC to SVI based local switching working. On another 7600, I'm running an engineering build of SRE that was provided to me by my SE to test a commit for an outstanding bug. I was hoping this other device and engineering build would be adequate to use as an SRE test bed. The engineering build seems to be based on the Advanced Enterprise Services feature set, not the Advanced IP Services feature set that we will actually be using. I'm trying to lab up the EVC to SVI local switching config, but it's giving me problems and I'm not sure if it's the engineering build that is causing me grief or if what I want to do just won't work. As you can imagine, I'd like to try and get this all proved out ahead of time so there are no gotchas during the upgrade. The issue I'm running into in the engineering build is that the parser is expecting a service instance identifier after the VLAN identifier, which doesn't jive; can't make an EFP on an SVI: 7600#sh run int g7/0/0 Building configuration... Current configuration : 238 bytes ! interface GigabitEthernet7/0/0 description NNI Testing Port mtu 9216 no ip address speed 1000 mls qos trust dscp no cdp enable service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric ! end 7600#sh run int vlan 100 Building configuration... Current configuration : 40 bytes ! interface Vlan100 no ip address end 7600#conf t Enter configuration commands, one per line. End with CNTL/Z. 7600(config)#connect test gi7/0/0 100 vlan 100 ? 1-4294967295 Service Instance Identifier 7600(config)# The SRC parser seems to think different: 7600#sh run int g7/0/17 Building configuration... Current configuration : 227 bytes ! interface GigabitEthernet7/0/17 description NNI Testing Port mtu 9216 no ip address mls qos trust dscp no cdp enable service instance 100 ethernet encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric ! end 7600#sh run int vlan 100 Building configuration... Current configuration : 40 bytes ! interface Vlan100 no ip address end 7600#conf t Enter configuration commands, one per line. End with CNTL/Z. 7600(config)#connect test gi7/0/17 100 vlan 100 ? 1-4294967295 Service Instance Identifier interworkingConfigure Interworking Type for this connection 7600(config)#connect test gi7/0/17 100 vlan 100 interworking ethernet 7600(config-connection)# Anyone know if production SRE5 Advanced IP Services is similar to what works in SRC? Thanks in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] forced path MPLS tunnel question
Gert, Maybe another approach could be to use the IP SLA LSP ping option... Seems to be supported since SXH: http://www.cisco.com/en/US/docs/ios-xml/ios/ipsla/command/sla_s2.html#GU ID-91306735-FA32-4AF8-B8EF-61FD667CD15B Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Tuesday, January 17, 2012 12:05 To: cisco-nsp@puck.nether.net Subject: [c-nsp] forced path MPLS tunnel question Hi, I'm currently considering options to better monitor the MPLS bits of our network - specifically, make sure that MPLS *forwarding* works, without having to rely on end systems noticing EoMPLS links going black hole or L3 VRFs going down. One of the reasons for MPLS forwarding to break could be ethernet circuit bought from $3rd_party, their equipment failing to properly forward all different ethernet types - IPv4 works, MPLS fails - happened to a colleague recently, which got me thinking... The way I thought this could be done is to setup a MPLS tunnel with a static path, crossing all major links (this is a small network, so the tunnel just needs to go through 6 routers or so to visit all backbone MPLS links), and then send ping probes down that tunnel. MPLS forwarding breaks - ping breaks - operator goes investigating. Now, the documentation that I found ties this to tunnel mode mpls traffic-eng and *this* seems to require OSPF or ISIS being used as an IGP - which we don't have, right now. (Platform is 6500/Sup720, IOS 12.2SXH/SXI) So, Question #1: - is there a way to setup a static MPLS tunnel/LSP take *this* link and then *that* link and then go *there* without OSPF or ISIS? Question #2: - what is happening behind the scenes to make static(!) paths require OSPF / ISIS? I can understand that auto-te needs the necessary metrics, but basic MPLS works fine with just BGP/LDP/EIGRP... (And yes, I could move everything over to OSPF, it's just that I want to understand the reasons for it) thanks, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.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] ADSL-PORTAL service
The by-the-book method would be to use ISG: http://www.cisco.com/en/US/partner/docs/ios-xml/ios/isg/configuration/15-2s/isg-15-2s-book.html Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of john travolta Sent: Saturday, January 14, 2012 14:11 To: cisco-nsp@puck.nether.net Subject: [c-nsp] ADSL-PORTAL service Hi all, We want to provide a portal service for our broadband users (PPPOE), where they can check their balance, recharge their account and etc. we are using a cisco 7201 as BRAS, it is required that a user with no credit still be able to access this portal, right now the users are authenticated by a AAA server and the IP allocation is done by the AAA too, the problem is when the user has no credit will not be authenticated, will not get an IP address and will not be able to access the portal. what are the existing case scenarios to accomplish this. Yours, John ___ cisco-nsp 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] Reply:RE: why vpls need some special line cards tosupport
There are 3 options to configure EoMPLS on 6500/7600: - Port mode: xconnect is configured directly on the port - Sub-interface mode: xconnect is configured on a subinterface (gig0/0.100), using dot1q VLAN to match traffic - SVI (interface vlan): xconnect is configured on SVI The first 2 options do not require special HW, and do not perform MAC learning (they do consume an internal VLAN, and the VLAN used for the sub-interface is globally used on the device) The SVI option requires a WAN card (SIP/ES) on the core facing side, and it would perform local MAC learning, as the SVI can be attached to multiple local interfaces. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Wednesday, January 11, 2012 16:18 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Reply:RE: why vpls need some special line cards tosupport On 11/01/12 13:56, ying-xiang wrote: Hi Arie, EoMPLS dosen't need to perform MAC learning or MAC look up for forwarding packets.so EoMPLS function can be implement even without a advanced egress line card.is that right?! Yes, exactly right. ___ cisco-nsp 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] why vpls need some special line cards to support
In VPLS, we need to be able to perform two actions: - L2 forwarding based on MAC (consider there could be local switching, need to perform MAC learning, flooding etc) - Label imposition Older PFC (forwarding engine on 6500/7600) cannot perform both actions in the same hardware, so another resource is required. PFC would perform the L2 forwarding functions (like a regular L2 switch would do), and the egress linecard would perform the label imposition. Regular LAN linecards do not have forwarding capacity on them (even if they have a DFC), and would require a more advanced line card. These are the different SIP modules or more recently ES20 and ES+ modules (now also supported on 6500...) On 6500, SUP2T can also do VPLS natively, because the new PFC (PFC4) can do all the processing on its own. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of ying-xiang Sent: Monday, January 09, 2012 17:27 To: cisco-nsp@puck.nether.net Subject: [c-nsp] why vpls need some special line cards to support i have been confused by this question for a long time and i have been looking up some stuff from CCO.but still can not find the answer.what's the difference between when a router need to handle encapsulation of L3VPN and L2vpn?anyone who could give the point? ___ cisco-nsp 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] shaping outbound
Pete, You are correct in general, but in many (most) cases Internet applications are TCP based, and policing them would make the TCP adjust the actual rate. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pete Templin Sent: Sunday, December 25, 2011 15:24 To: Dan Letkeman Cc: cisco-nsp Subject: Re: [c-nsp] shaping outbound On 12/24/11 2:49 PM, Dan Letkeman wrote: I'm confused as to when and where it is possible to shape traffic. I have a 50Mbps internet connection from our ISP and I would like to shape some of the download traffic using our 2821. Any idea on how to go about this? Or Am I stuck with buying a ridiculously expensive packet shaper or something of the sorts? You might be stuck. In the grand scheme of things, it's too late: you should shape as the traffic enters the bottleneck, and/or police certain classes as desired. Once the traffic arrives on your router, the congestion has occurred, and there's not much to be done about it. UDP/ICMP won't learn from shaping, so they can still overtake the internet link if you were to shape outbound to the LAN. That's where the packet shaper appliance would potentially do better: it can throttle the upload traffic to influence the download traffic responses. pt ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] shaping outbound
Dan, If I read your request correctly, you are not an ISP, but just want to manage your site's ISP connection... Right? If this is true, you most likely do not want to police your class-default... You should most likely police any specific class with traffic that is known to overload the link (for example downloads, YouTube, etc) but let the other kinds of traffic be able to burst to the full line speed (assuming they are not overloading it constantly). If your link is 50M (like you state), and you apply the below policy, on average, your link would never get to over 30Mbps... BTW, if you have abusive UDP applications (very rare in normal Internet environments) than it's too late to police, even though it is not completely useless, as the final effect would be that the specific UDP based application, which in reality needs (let's say) 20Mbps, but you allow it only 10Mbps, would starve for bandwidth, and the users would not get the actual thing to work properly. So if they are your users (for example if you are the IT person at the same company), you would eventually get a call ;-) Arie -Original Message- From: Dan Letkeman [mailto:danletke...@gmail.com] Sent: Saturday, December 24, 2011 23:35 To: Arie Vayner (avayner) Cc: cisco-nsp Subject: Re: [c-nsp] shaping outbound Ok, so my solution would look something like this: class-map match-any application match protocol http policy-map inbound class application police 1000 100 class class-default police 2000 200 interface g0/1 service-policy input inbound And this would police http traffic to 10mbps and all other traffic to 20mbps. Are there any recommendations on the police command to limit the about of drops I get from doing this? I do have an ASA5520 in front of this router, is there any way of utilizing that to shape the traffic? Thanks, Dan. On Sat, Dec 24, 2011 at 3:06 PM, Arie Vayner (avayner) avay...@cisco.com wrote: Dan, On the ingress direction, you can apply a policer on specific classes, and limit the rate. As you are most likely talking about TCP based applications, policing them would make the applications regulate their download rate. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dan Letkeman Sent: Saturday, December 24, 2011 22:49 To: cisco-nsp Subject: [c-nsp] shaping outbound Hello, I'm confused as to when and where it is possible to shape traffic. I have a 50Mbps internet connection from our ISP and I would like to shape some of the download traffic using our 2821. Here is what I have setup: lan users - g0/0 - 2821 - g0/1 --internet Currently I have no way of limiting someone from using up the entire pipe. My thought was to add a policy-map in the outbound direction on the G0/0 interface and shape based on NBAR protocols or something like that. Apparently this is not the correct way to do thisIf I apply a policy-map in the outbound direction on G0/1 this helps nothing because it only shapes the upload traffic which is minimal at peak times. Any idea on how to go about this? Or Am I stuck with buying a ridiculously expensive packet shaper or something of the sorts? Thanks, Dan. ___ cisco-nsp 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] shaping outbound
Dan, On the ingress direction, you can apply a policer on specific classes, and limit the rate. As you are most likely talking about TCP based applications, policing them would make the applications regulate their download rate. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dan Letkeman Sent: Saturday, December 24, 2011 22:49 To: cisco-nsp Subject: [c-nsp] shaping outbound Hello, I'm confused as to when and where it is possible to shape traffic. I have a 50Mbps internet connection from our ISP and I would like to shape some of the download traffic using our 2821. Here is what I have setup: lan users - g0/0 - 2821 - g0/1 --internet Currently I have no way of limiting someone from using up the entire pipe. My thought was to add a policy-map in the outbound direction on the G0/0 interface and shape based on NBAR protocols or something like that. Apparently this is not the correct way to do thisIf I apply a policy-map in the outbound direction on G0/1 this helps nothing because it only shapes the upload traffic which is minimal at peak times. Any idea on how to go about this? Or Am I stuck with buying a ridiculously expensive packet shaper or something of the sorts? Thanks, Dan. ___ cisco-nsp 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] Packet Shaper
Jay, You may also want to look at NBAR and NBAR2 capabilities on the ASR1K. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rubens Kuhl Sent: Thursday, December 15, 2011 22:43 To: Jay Nakamura Cc: cisco-nsp Subject: Re: [c-nsp] Packet Shaper On Thu, Dec 15, 2011 at 5:57 PM, Jay Nakamura zeusda...@gmail.com wrote: Does Cisco make any dedicated packet shaper? Does anyone recommend any other vendors for 100~200mbps bandwidth and deep packet inspection? Cisco SCE. For other vendors look at Sandvine, Arbor, Procera, Ipoque. Or build your own open-source DPI gateway, 100~200 Mbps is something that a good PC can handle. Rubens ___ cisco-nsp 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 ME3600X and Bridge-Domain Routing config question
Reuben, On the ME3600X you cannot have the same VLAN used as an SVI for Layer 3 bridge-domain on a service-instance, and at the same time also applied as a regular allowed VLAN on a trunk or as the VLAN of an access port. Check that VLAN780 is not allowed anywhere on the system (trunks and access ports), and it is only used as bridge-domain on a single service-instance EFP. These restrictions are documented here (section name is Bridge Domain Routing): http://www.cisco.com/en/US/partner/docs/switches/metro/me3600x_3800x/sof tware/release/12.2_52_ey/configuration/guide/swevc.html#wp1058131 You are most likely hitting these restrictions: *There can be only one EFP in the bridge domain. (applies for routes bridge-domains) *You cannot have any Layer 2 switchports in the VLAN (bridge domain) used for routing. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Reuben Farrelly Sent: Monday, November 14, 2011 11:37 To: c-nsp Subject: [c-nsp] Cisco ME3600X and Bridge-Domain Routing config question I've recently started to explore the more interesting features of the ME3600X platform and one of the things I have been looking at is starting to provision customers using EVC type configuration, so I can do vlan tag remapping and other nice things in the coming months. Previously I've been just using SVI's and trunk ports - which has worked reasonably well, but has some limitations in terms of scalability and features. At the moment I'm starting off small and looking to set up just one brand new access ethernet service for a customer for now to test out the concept and familiarise myself with the configuration before I look to deploy this across the board. [NB: The service was meant to be ordered as a trunk but was incorrectly provisioned and I've been told to get it working ASAP, so for the meantime I'm stuck with it being an access port, but it is almost certain it will become a trunk service in the future and I have other trunk ports I can deploy with]. However I'm clearly missing something here, as the switch just won't let me apply the config. The old configuration which works is: interface GigabitEthernet0/15 description CUSTOMER - X port-type nni switchport access vlan 780 spanning-tree portfast ! interface Vlan780 description CUSTOMER - X vrf forwarding CUSTOMER-VRF bandwidth 3 ip address XXX.XXX.96.69 255.255.255.252 no ip proxy-arp end This is all good. Now here is what I was proposing as the equivalent EVC config: interface GigabitEthernet0/15 description CUSTOMER - X port-type nni switchport trunk allowed vlan none switchport mode trunk service instance 780 ethernet encapsulation untagged bridge-domain 780 ! interface Vlan780 description CUSTOMER - X bandwidth 3 ip address XXX.XXX.96.69 255.255.255.252 no ip proxy-arp end The interface config applies fine, but the SVI refuses to take an IP address: sw1.qld(config-if)# ip address XXX.XXX.96.69 255.255.255.252 %IP address cannot be configured on bridge domain 780 EFP Switchports or EFPs sw1.qld(config-if)# Ok, so let's go to the documentation, clearly I must be doing something wrong. http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/re lease/12.2_52_ey/configuration/guide/swevc.pdf This is an example of configuring bridge-domain routing with a single tag EFP: Switch (config)# interface gigabitethernet0/2 Switch (config)# switchport mode trunk Switch (config)# switchport trunk allowed vlan none Switch (config-if)# service instance 1 Ethernet Switch (config-if-srv)# encapsulation dot1q 10 Switch (config-if-srv)# rewrite ingress tag pop 1 symmetric Switch (config-if-srv)# bridge-domain 100 Switch (config)# interface vlan 100 Switch (config-if)# ip address 20.1.1.1 255.255.255.255 -- Hmm, not that different to what I was trying, but let's try the example from the documentation - changing Gig0/2 to Gi0/5 as Gi0/2 is used on my switch: sw1.qld(config)#default interface gig0/5 Interface GigabitEthernet0/5 set to default configuration sw1.qld(config)#interface gigabitethernet0/5 sw1.qld(config-if)#switchport mode trunk sw1.qld(config-if)#switchport trunk allowed vlan none sw1.qld(config-if)#service instance 1 Ethernet sw1.qld(config-if-srv)#encapsulation dot1q 10 sw1.qld(config-if-srv)# rewrite ingress tag pop 1 symmetric sw1.qld(config-if-srv)# bridge-domain 100 sw1.qld(config-if-srv)#interface vlan 100 sw1.qld(config-if)#ip address 20.1.1.1 255.255.255.255 %IP address cannot be configured on bridge domain 100 EFP Switchports or EFPs sw1.qld(config-if)# Ok now I'm confused. The documentation example doesn't work either. I'm not too sure where to look next. What exactly am I doing wrong? I'm running 12.2(52)EY3a on the switches and I cannot upgrade to 15.1(2)EY as the units will not link up ports with hardcoded speed and duplex (CSCtr83418) and also won't switch
Re: [c-nsp] show installed memory and usage
Rolf, Try: 7600-1#remote command switch show memory HeadTotal(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 10070994 631968348 228349532 403618816 339854020 364588984 I/O 3C006710886443819664232892002307110823267580 7600-1#remote command ? module Remote command execution module standby-rp Remote command execution standby-rp standby-sp Remote command execution standby-sp switch Remote command execution switch Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rolf Hanßen Sent: Monday, November 14, 2011 10:46 To: cisco-nsp@puck.nether.net Subject: [c-nsp] show installed memory and usage Hello list, according what I read on a Sup720 I have: -Switch processor DRAM -Route processor DRAM -Switch processor bootdisk -Route processor bootdisk I now want to find out what is installed and what is used (at least for the DRAM). with dir I get the SP bootdisk I think: Directory of sup-bootdisk:/ ... 512024576 bytes total (303824896 bytes free) sh version gives me: cisco CISCO7609-S (R7000) processor (revision 1.0) with 983008K/65536K bytes of memory. sh mem shows: HeadTotal(b) Used(b) Free(b) Lowest(b) Largest(b) Processor 47352690 885676400 581839952 30383644878906924 302877164 I/O80067108864157931805131568451315684 51313980 Are those values the RP memory or the SP memory ? How can I find out the values for the other memory not shown here? How do I see the memory installed in 2nd sup720 (in case it is not in a mode which requires same sizes as active card) ? attach the slot and sh mem ? kind regards Rolf Hanßen ___ cisco-nsp 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 ME3600X and Bridge-Domain Routing config question
+1 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of sth...@nethelp.no Sent: Monday, November 14, 2011 12:54 To: reuben-cisco-...@reub.net Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco ME3600X and Bridge-Domain Routing config question Hrm, it's going to be fun to retrospectively restrict trunk ports on both ends all through the network to get around this. Maybe EVC's just isn't going to work for me afterall. Having explicit allowed vlan lists on trunk port is a good idea in any case. Open trunks which is the Cisco default is IMHO a recipe for disaster in the long run... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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 ME3600X and Bridge-Domain Routing config question
I just got a confirmation from the BU, and the restrictions were reduced with 15.1(2)EY, as it now supports IRB for unicast. So now the restrictions for 15.1(2)EY are: *You must configure SVIs for bridge-domain routing. *The bridge domain must be in the range of 1 to 4094 to match the supported VLAN range. *You can use bridge domain routing with only native packets. *MPLS is not supported. So basically if you upgrade, it should work. Arie -Original Message- From: Reuben Farrelly [mailto:reuben-cisco-...@reub.net] Sent: Monday, November 14, 2011 12:42 To: Arie Vayner (avayner) Cc: c-nsp Subject: Re: [c-nsp] Cisco ME3600X and Bridge-Domain Routing config question On 14/11/2011 9:32 PM, Arie Vayner (avayner) wrote: Reuben, On the ME3600X you cannot have the same VLAN used as an SVI for Layer 3 bridge-domain on a service-instance, and at the same time also applied as a regular allowed VLAN on a trunk or as the VLAN of an access port. Check that VLAN780 is not allowed anywhere on the system (trunks and access ports), and it is only used as bridge-domain on a single service-instance EFP. That'll be it. VLAN 780 is not set on any access ports or used anywhere else, but there are a few trunk ports on that switch and some others which have no restrictions on which VLANs can pass (eg switch-switch within the same POP and rack which are trusted) such as: interface GigabitEthernet0/23 description NETWORK - Link to sw2.qld Gi0/23 port-type nni switchport mode trunk mtu 1546 storm-control broadcast level 2.50 1.50 storm-control action trap end Hrm, it's going to be fun to retrospectively restrict trunk ports on both ends all through the network to get around this. Maybe EVC's just isn't going to work for me afterall. Thanks for the help Arie. Much appreciated. Reuben ___ cisco-nsp 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] Strange trunk behavior
How is your port on the ME3400 configured? Is it an NNI port or UNI? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ghassan.khalil Sent: Sunday, October 30, 2011 19:59 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Strange trunk behavior Dears, I have 3400-me connected to a 2960 switch with interface vlan on each of them. When configuring the link as access port on vlan 891 the interface vlan can reach each other. But when configuring the link as trunk port with allowed vlan 891 the interface vlan stays up-up but the interface vlan can not ping each other. Did anyone face this kind of problems with 3400-me or 2960 ? ___ cisco-nsp 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 CSS to Log URLs
You could try these: logging subsystem flowmgr level debug-7 logging subsystem flowagent level debug-7 Be very careful with this, as it is a low-level debug mode, and would most likely have substantial performance impact. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Yahoo! Sent: Monday, October 17, 2011 20:10 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco CSS to Log URLs Dear Experts, We have CSS (Cisco load-balancers) and as you may know these boxes are end of life and no longer supported by Cisco. My Question is how to get URL logs out of this box. I have changed logging up to level 6 and still cannot get URLs on my Splunk. I can't find the right logging command! ___ cisco-nsp 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] Policing VLANs on a trunk
You most likely need vlan based PFC QOS: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con figuration/guide/qos.html#wp1726124 The general idea is that you apply mls qos vlan-based on the trunk, and then apply the per-vlan policy on the SVI interface (even if it does not have any IP config). Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Graham Beneke Sent: Monday, October 17, 2011 09:51 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Policing VLANs on a trunk I have been doing some reading and googling and I've ended up more confused than where I started... Can someone point me to a good reference doc (specifically for the 6500 platform)? We have a Metro Ethernet service from a local provider and we are running a dot1q trunk over it. What I'm trying to do is to rate-limit the two VLANs on the trunk so that neither one can consume the full capacity of the circuit. The VLANs don't terminate on a local SVI so I suspect that this may not actually work. -- Graham Beneke ___ cisco-nsp 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] 802.1ah documentation
Try these: http://www.cisco.com/en/US/docs/ios-xml/ios/cether/configuration/15-1s/c e-mac-evc-pbb.html http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.1/lxvp n/configuration/guide/lesc41pbb.html (I just searched for 802.1ah on cisco.com...) Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Vitkovsky, Adam Sent: Monday, October 17, 2011 16:14 To: cisco-nsp@puck.nether.net Subject: [c-nsp] 802.1ah documentation Hi, I somehow failed to find some decent documentation on how does the Provider Backbone bridges work Can you please point me to some documentation or books please? I'm mostly interested in how is the mac routing accomplished Also I'd be interested to see how may of you are actually using it in production in favor of VPLS or in access-layer of H-VPLS Thank you adam ___ cisco-nsp 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] Policing VLANs on a trunk
Actually, this is a common requirement... Imagine you get multiple customer circuits from a 3rd party provider or a lower aggregation layer bundled on a trunk, each on their own VLAN, and the NPE device is your 1st policy enforcement point to make sure the customer does not use more than what they are buying... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of chris stand Sent: Monday, October 17, 2011 16:31 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Policing VLANs on a trunk 5. Policing VLANs on a trunk (Graham Beneke) I have been doing some reading and googling and I've ended up more confused than where I started... Can someone point me to a good reference doc (specifically for the 6500 platform)? We have a Metro Ethernet service from a local provider and we are running a dot1q trunk over it. What I'm trying to do is to rate-limit the two VLANs on the trunk so that neither one can consume the full capacity of the circuit. The VLANs don't terminate on a local SVI so I suspect that this may not actually work. -- Graham Beneke You don't say why you wish to do this so can I ask why you would care ? If there is capacity on a pipe let it it filled up in the sequence packets arrive. Now if there is some sort of QOS requirements for voice perhaps ... ?? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] MPLS - IPsec tunnel between a PE and CE
Nduati, ISC is just the management solution. You can still provision the same functionality using manual configuration... You should be able to put create an encrypted GRE tunnel (in the global routing table), and then put the tunnel in the VRF (just put the ip vrf forwarding config on the tunnel interface). Be careful with hardware based platforms (such as 6500/7600) as they do not support IPSec in hardware (unless using the right service module). Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Wakwa Nduati Sent: Saturday, October 15, 2011 20:56 To: cisco-nsp@puck.nether.net Subject: [c-nsp] MPLS - IPsec tunnel between a PE and CE Hi, I run an mpls network. Recently a customer acquired an office where my L2 network was not present and had to connect to another ISP. He would like this branch to join in the MPLS cloud. On digging around in cisco I read that this is possible using ISC. * http://www.cisco.com/en/US/docs/net_mgmt/ip_solution_center/3.0/mpls/use r/guide/6_iscqsg.html#wp1045706 * Site-to-Site IPsec Tunnels: One-Box Solution Unfortunately I do not have ISC and this sounds like the right solution for my client. Any pointers, leads, examples much appreciated on how to work this on both the PE and CE router. Regards Nduati. ___ cisco-nsp 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] EoMPLS on a pair of 7201's
Another option would be to go with 12.2(33)SRE (latest) or even a more recent 15.1S release (15.1S is what comes after SRE... It's just a renumbering that happened about a year ago...) Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Amir Chaudhri Sent: Friday, October 14, 2011 12:28 To: e...@edgeoc.net; cisco-nsp-boun...@puck.nether.net; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] EoMPLS on a pair of 7201's Thanks All, I think my Issue is the IOS I am running, (c7200p-ipbase-mz.124-4.XD10.bin) as it doesn¹t support any of the MPLS commands, I did a search on the Cisco Feature Navigator and it points to this IOS version (c7200p-adventerprisek9_sna-mz.151-4.M.bin) would this one do it? Do you need to print out this email? Be green - keep it on the screen! P CONFIDENTIALITY NOTICE The contents of this email and any attachments to it are confidential and are intended solely for the individual(s) and/or organisation(s) to whom this email is addressed. If you are not the intended recipient of this email any use, disclosure, forwarding, printing or copying of this email and any attachments to it by you may be unlawful. If you have received this email in error please notify us immediately by email to postmas...@ascertiva.com Ascertiva Group Warwick House Houghton Hall Park Houghton Regis Dunstable LU5 5ZX Registered Office: Warwick House, Houghton Hall Park, Houghton Regis, Dunstable, LU5 5ZX. Registered in England No. 02513162. Web Site: www.ascertiva.com This e-mail has been scanned for all viruses by Star.(O) The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ cisco-nsp 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] EoMPLS on a pair of 7201's
Amir, It should work. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Amir Chaudhri Sent: Thursday, October 13, 2011 17:48 To: cisco-nsp@puck.nether.net Subject: [c-nsp] EoMPLS on a pair of 7201's has anyone ever successfully got EoMPLS working between a pair of 7201s Commands Im trying to use are below. mpls label protocol ldp interface GigabitEthernetX/X description Link to GR mtu xxx no ip address xconnect [IP Address] 100 encapsulation mpls End Thanks in advance... Amir Chaudhri | Systems Administrator | Ascertiva Group Ltd Warwick House | Houghton Hall Park | Houghton Regis | Dunstable | LU5 5ZX Office: 01582 556137 | Fax: 01582 539090 | Mobile: 07931 846677 Email: amir.chaud...@ascertiva.commailto:amir.chaud...@ascertiva.com | web: www.ascertiva.comhttp://www.ascertiva.com/ Do you need to print out this email? Be green - keep it on the screen! P CONFIDENTIALITY NOTICE The contents of this email and any attachments to it are confidential and are intended solely for the individual(s) and/or organisation(s) to whom this email is addressed. If you are not the intended recipient of this email any use, disclosure, forwarding, printing or copying of this email and any attachments to it by you may be unlawful. If you have received this email in error please notify us immediately by email to postmas...@ascertiva.com Ascertiva Group Warwick House Houghton Hall Park Houghton Regis Dunstable LU5 5ZX Registered Office: Warwick House, Houghton Hall Park, Houghton Regis, Dunstable, LU5 5ZX. Registered in England No. 02513162. Web Site: www.ascertiva.com This e-mail has been scanned for all viruses by Star.(O) The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ cisco-nsp 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] EoMPLS ?s
Jason, There is no fragmentation in MPLS. Either you can forward the packet, or it is dropped. You need to either have a larger MTU on the core (usually the way it is implemented today), or reduce MTU at both sides. As this is a L2 link, you can't use things like MSS adjust etc... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason LeBlanc Sent: Wednesday, October 12, 2011 20:53 To: cisco-nsp@puck.nether.net Subject: [c-nsp] EoMPLS ?s We're considering using EoMPLS port mode to bridge two datacenters together temporarily for a move using sup720-3BXL on both ends with 6724 blades, probably 2 or 4 gig links, possibly 10g if I can get them to buy the HW. The question I have primarily is with regard to MTU. I have heard there are issues with ensuring both sides match, not much concern there. But the network between the two facilities may be lower than the 1518 bytes, causing fragmentation. I know this gets punted to the RP, and is going to be a problem. Is there any work around? Thanks, Jason ___ cisco-nsp 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] Fwd: calculate Overhead
Vijay, There was no attachment. A few leading questions: - What kind of a problem are you seeing? A very common issue would be an MTU problem. - How do you get this link delivered to you? As an Ethernet port? Are you implementing egress shaping? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of vijay gore Sent: Tuesday, October 11, 2011 10:19 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Fwd: calculate Overhead -- Forwarded message -- From: vijay gore vijaygor...@gmail.com Date: Tue, Oct 11, 2011 at 12:03 PM Subject: Re: [c-nsp] calculate Overhead To: Mikael Abrahamsson swm...@swm.pp.se actually i had given link from my 'A' to 'B' Location A is my DC and B is my DR location, now oracle team is facing the issue on this link, and as per oracle team issue in my network, but i have not found any issue in my network, now i want to show them absulate bandwidth and cusumption on that perticular link, A to B bahave like LAN. the link is given on Xconnect L2TP. on vlan. plz find the attached network diagram for your ref On Tue, Oct 11, 2011 at 11:43 AM, Mikael Abrahamsson swm...@swm.pp.sewrote: On Tue, 11 Oct 2011, vijay gore wrote: It's P2P link, connected on Xconnect -- Ethernet link, it's having 4mbps bandwidth.. Again, not enough information. How is the speed limited to 4 megabit/s ? By means of traversing 2xE1 using MPLSoPPP or MPLSoHDLC, or by means of a shaper or policer? You should also specify what it is you're tring to accomplish, why do you need to know the overhead? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ cisco-nsp 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] pppoe - different speed DSL customers
Can you define separated? Basically, you can have a user policy (per user or user group) on your AAA server (RADIUS) with different policies such as QOS, IP Assignment, VRF selection and many other options... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of K bharathan Sent: Wednesday, October 05, 2011 09:01 To: cisco-nsp@puck.nether.net Subject: [c-nsp] pppoe - different speed DSL customers can dsl customers be seperated based on speed in cisco PPPoe thanks for any clues on this regards ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] pppoe-link
I am not completely sure about the PPPoE model you have as you mention 2 different things: - L2TP - VPLS If you get a L2 circuit (VPLS) with no IP configured on it, and you terminate PPPoE sessions on your router, then this is not L2TP, but regular PPPoE. PPPoE is a L2 protocol which runs directly over Ethernet and does not require an IP layer (the customer does not get an IP address before the PPP layer assigns it). With L2TP you would have an IP based tunnel from the SP, while they terminate the PPPoE session, and they would tunnel it to your LNS. In that case the LAC (SP BRAS) has to have IP connectivity to your LNS device. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of K bharathan Sent: Sunday, October 02, 2011 11:40 To: cisco-nsp@puck.nether.net Subject: [c-nsp] pppoe-link | upstream ISP || Fibre Link |--| downstream ISP | (gw rt) | Fibre link (1 line) is divided into 3 VLANS 1 vlan for internet bandwidth (wan ip from upstream ISP 1 vlan for DSL bandwidth (wan ip from upstream ISP) 1 vlan (l2tp link) for PPPOE from their VPLS network; no wan ips on this; the link terminates at downstream ISP gw router problem: there is no wan ip on the PPPoe link how a PPPoe server can be answering the DSL client; how can this particular link can be connected to the downstream ISP network; anybody has got any ideas ? thanks ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS XR RPL
Nick, I think you can find the following example very similar to what you want to achieve: http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.1/rout ing/configuration/guide/routing_cg41asr9k_chapter7.html#ref_1093449 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce Sent: Thursday, September 22, 2011 13:48 To: cisco-nsp@puck.nether.net Subject: [c-nsp] IOS XR RPL Hi, I'm trying to write a route-policy that will prepend a customers' announcement when they send a certain community. The prepend should be their own AS number rather than our AS. I know how to do this is Junos but could anyone point me in the right direction for IOS XR? Thanks Nick -- 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. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept 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/
Re: [c-nsp] MPLS VPN with PE over GRE tunnels
On 6500 if you want to use MPLS over GRE, you would need to have your core facing links (through which the GRE packets are sent/received) on a SIP400 card... Alternatively, SUP2T can support this natively. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_p aper_c11-652042.html#wp9000959 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Tuesday, September 20, 2011 10:55 To: Ross Halliday Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS VPN with PE over GRE tunnels Hi, On Mon, Sep 19, 2011 at 07:18:19PM -0400, Ross Halliday wrote: Currently our network has one switch that is at the hub of our transition to MPLS as we cut various devices over and wait for maintenance windows. It has: This switch would be a 6500 with all these protocols being enabled, and the problem spot is packet comes in MPLS-encapsulated and needs to leave GRE-encapsulated (or return path)? Any help or suggestions would be very appreciated! There was something about the 6500 architecture that certain combinations of ingress and egress need packets to go through the forwarding plane twice, and you need to enable packet recirculation for it to do that. The command I could find for that is mls mpls tunnel-recir, but you might want to verify with the docs whether this is what you want. Cisco(config)#mls mpls ? ... tunnel-recir Recirculate Tunnel packets gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.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] MPLS VPN with PE over GRE tunnels
Sorry for double posting... This seems to be a good reference: http://www.cisco.com/en/US/prod/collateral/routers/ps9343/Deploying_and_ Configuring_MPLS_Virtual_Private_Networks_In_IP_Tunnel_Environment.pdf Arie -Original Message- From: Arie Vayner (avayner) Sent: Tuesday, September 20, 2011 17:18 To: 'Gert Doering'; Ross Halliday Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] MPLS VPN with PE over GRE tunnels On 6500 if you want to use MPLS over GRE, you would need to have your core facing links (through which the GRE packets are sent/received) on a SIP400 card... Alternatively, SUP2T can support this natively. http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_p aper_c11-652042.html#wp9000959 Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Tuesday, September 20, 2011 10:55 To: Ross Halliday Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MPLS VPN with PE over GRE tunnels Hi, On Mon, Sep 19, 2011 at 07:18:19PM -0400, Ross Halliday wrote: Currently our network has one switch that is at the hub of our transition to MPLS as we cut various devices over and wait for maintenance windows. It has: This switch would be a 6500 with all these protocols being enabled, and the problem spot is packet comes in MPLS-encapsulated and needs to leave GRE-encapsulated (or return path)? Any help or suggestions would be very appreciated! There was something about the 6500 architecture that certain combinations of ingress and egress need packets to go through the forwarding plane twice, and you need to enable packet recirculation for it to do that. The command I could find for that is mls mpls tunnel-recir, but you might want to verify with the docs whether this is what you want. Cisco(config)#mls mpls ? ... tunnel-recir Recirculate Tunnel packets gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.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] access a specific vty pool on IOS-XR
Tassos, You should be able to control this using an ACL if the selection is based on the source of the session. line template nms access-class ingress nms_host ! line template default access-class ingress deny_nms_host ! vty-pool telnet 5 6 line-template telnet vty-pool default 0 4 line-template default Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tassos Chatzithomaoglou Sent: Monday, September 05, 2011 10:22 To: cisco-nsp Subject: [c-nsp] access a specific vty pool on IOS-XR Hi, Does anyone know how i can access a specific vty pool on IOS-XR? i.e. in the following config, how do i access (through telnet) lines 90-99? vty-pool default 0 10 vty-pool INBAND-VTY-POOL 90 99 line-template INBAND-LINE-TEMPLATE On IOS platforms i was adding 2xxx to the line number or using the rotary command (3xxx), but i'm not able to do the same thing on IOS-XR. -- Tassos ___ cisco-nsp 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?
Just to explain, as I got an offline comment... I am proposing 2 different solutions: - ASR1K can be used for IPSec termination - A load balancer can be used to scale the solution and use multiple IP Sec servers. Other IP Sec servers types (ASA etc) can be used... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arie Vayner (avayner) Sent: Sunday, September 04, 2011 14:39 To: Florian Bauhaus; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] How to terminate 100.000 IPsec VPN clients? Another option could be an ASR1K which can do quite a lot of IPSec. I would most likely have looked into using a load balancer to load share between multiple servers, and just add more IPSec nodes as the scale would require... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Florian Bauhaus Sent: Friday, September 02, 2011 16:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] How to terminate 100.000 IPsec VPN clients? 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/ ___ cisco-nsp 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] Traffic shaping on a GE interface
George, Yes, you should be using egress shaping on such a link, and this is the by-the-book solution. In many cases what you would also want to do is apply a child policy with the actual QOS classes. I have a feeling you are hitting an issue with the precision of the shaper, versus the ability of the EoSDH service to transfer all the data... In some L2 services (usually ethernet based metroE), the policy applied by the service provider uses ingress policers, and depending on the vendor/platform/configuration it may count the whole L2 byte count or in some cases only the L3 content of the frame... Another type of layer 2 service (which sounds like what you have) is EoSDH, where the SP would map NxSTM1 to a GigE port... You need to remember that STM1 in SDH is not really a 155Mbps link... This number includes overheads, and in reality would pass ~149Mbps, and this most likely is not the real number either, as it would include all the other ethernet service-related overheads (such as preamble, inter-packet gaps, CRC etc), so the real rate would be even lower. Shapers usually (at least by default, on most platforms) use the L3 byte count... This can cause a difference in the way you count the traffic rate, and the best practice I usually recommend in such cases would be to start reducing the shaper rate and find a rate at which the drops stop... I would suggest you play with the shaper , tuning it down to something like 250Mbps, see if you still have drops, and then start increasing it... Note that the L2/L3 difference is also impacted with your traffic profile (packets per second, packet length), as the overhead would be larger if your average packet size is smaller. This means that you most likely want to tune the shaper slightly lower than the highest non-drop rate to accommodate for unexpected traffic pattern changes... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of George Manousakis Sent: Sunday, September 04, 2011 13:58 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Traffic shaping on a GE interface I am facing a problem in a network and I would like some suggestions in order to solve it (and to understand it as well)!! The case is that I use GE interfaces on cisco devices as wan links but on the other side there are elements providing EoSDH services. Those elements do not operate as Ethernet routers and switches regarding (at least) the way that they buffer packets, resulting drops. For example, I have a wan link of 300Mpbs and at both ends the interfaces are Optical GE on cisco routers (7200 or ASR). Because of the multiplexing done on the wan link provider the CIR on the GE port is only 300mbps, so whenever cisco is bursting traffic (which seems perfectly normal since the clock rate on the interface dictates 1Gbps rate), the other side is dropping packets. I tried using traffic shaping (300mbps with default values for buckets Be and Bc) on the outside flow on both cisco interfaces but the result is the same. Maybe the dropping rate is reduced, but there are still packet drops. These drops are appearing only on the provider equipment, on both ports. How can I configure the MCQ in order to suppress the transmission rate on the wan capability??? I want to transmit no more that 300mbps under any condition! Using traffic shaping should solve that problem but because of the unpredictable characteristics of the traffic on the wan bursts may occur that are above 300Mbps. I have to comment that that the average traffic on the interface is less than 200mbps. The problem is caused (I assume) by the bursts in the fragments of a second that GE can support but EoSDH cannot allow. Thanks in advance. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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?
Another option could be an ASR1K which can do quite a lot of IPSec. I would most likely have looked into using a load balancer to load share between multiple servers, and just add more IPSec nodes as the scale would require... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Florian Bauhaus Sent: Friday, September 02, 2011 16:55 To: cisco-nsp@puck.nether.net Subject: [c-nsp] How to terminate 100.000 IPsec VPN clients? 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/ ___ cisco-nsp 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] L2TP cisco 2800 client -- juniper ERX310 server
I think this is what you are looking for: http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtvoltun. html -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Joe Abley Sent: Wednesday, August 31, 2011 23:50 To: cisco-nsp@puck.nether.net Subject: [c-nsp] L2TP cisco 2800 client -- juniper ERX310 server Hi all, Does anybody happen to have a canned cisco configuration for building an L2TP tunnel between a cisco client and a Juniper ERX310, particularly where the outgoing interface on the cisco has ip address dhcp? Cisco in question is r1#show ver Cisco IOS Software, 2800 Software (C2800NM-ADVIPSERVICESK9-M), Version 12.4(24)T5, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2011 by Cisco Systems, Inc. Compiled Fri 04-Mar-11 03:52 by prod_rel_team ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1) r1 uptime is 1 week, 5 days, 23 hours, 57 minutes System returned to ROM by bus error at PC 0x4224CB60, address 0xB0D0B0D at 20:42:01 GMT Thu Aug 18 2011 System restarted at 20:44:05 GMT Thu Aug 18 2011 System image file is flash:c2800nm-advipservicesk9-mz.124-24.T5.bin This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption. Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately. A summary of U.S. laws governing Cisco cryptographic products may be found at: http://www.cisco.com/wwl/export/crypto/tool/stqrg.html If you require further assistance please contact us by sending email to exp...@cisco.com. Cisco 2821 (revision 53.51) with 1036288K/12288K bytes of memory. Processor board ID FHK1136F3SP 2 Gigabit Ethernet interfaces 2 ATM interfaces 1 Virtual Private Network (VPN) Module DRAM configuration is 64 bits wide with parity enabled. 239K bytes of non-volatile configuration memory. 62720K bytes of ATA CompactFlash (Read/Write) Configuration register is 0x2102 r1# Joe ___ cisco-nsp 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 6500/SUP720-3B EtherChannel Sample ?
If a member port's config is not synced it is unbundled from the bundle, and may be put in errdisable state. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rolf Hanßen Sent: Sunday, September 04, 2011 17:19 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cisco 6500/SUP720-3B EtherChannel Sample ? Hi, I just thought about how to add an interface to a running channel and I am wondering about the config after adding a port. If you have an existing channel and use channel-group ... on a clean interface to add it the config of the physical interface is not extendet with the config of the channel (for example the switchport trunk allowed vlan ... line). But If you change the config of the channel the config of the member ports is updated automatically. What happens if a have 2 ports in the channel with different allowed vlans ? Is the physical interface config ignored (and the channel interface vlans are valid on all members) or does this really work and a vlan only configured on one port of the channel is handled like a vlan on a non-channel port ? kind regards Rolf add command 'channel-group 5 mode on' to interface. This creates port-channel interface configuration below from one 7609 SUP720 interface Port-channel5 description xxx link switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1-253,255-283,285-288,291-306,308-337,339-355 switchport trunk allowed vlan add 357-372,375,376,380-382,384-388,390-531 switchport trunk allowed vlan add 534-603,607-610,612-691,693-703,705-899 switchport trunk allowed vlan add 901-973,975-1156,1158-1207,1209-1252 switchport trunk allowed vlan add 1254-1268,1270,1271,1274-1276,1278-1296 switchport trunk allowed vlan add 1298-1356,1358-1383,1385-1422,1424-1513 switchport trunk allowed vlan add 1515-1524,1526-1604,1606,1608-1628,1630 switchport trunk allowed vlan add 1632-1968,1971-1979,1981-2099,2101-2204 switchport trunk allowed vlan add 2206-2899,2901-3472,3474,3476-3478,3480-4094 switchport mode trunk switchport nonegotiate mtu 2200 load-interval 30 mls qos trust cos interface TenGigabitEthernet7/1 description xxx portchannel 5 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1-253,255-283,285-288,291-306,308-337,339-355 switchport trunk allowed vlan add 357-372,375,376,380-382,384-388,390-531 switchport trunk allowed vlan add 534-603,607-610,612-691,693-703,705-899 switchport trunk allowed vlan add 901-973,975-1156,1158-1207,1209-1252 switchport trunk allowed vlan add 1254-1268,1270,1271,1274-1276,1278-1296 switchport trunk allowed vlan add 1298-1356,1358-1383,1385-1422,1424-1513 switchport trunk allowed vlan add 1515-1524,1526-1604,1606,1608-1628,1630 switchport trunk allowed vlan add 1632-1968,1971-1979,1981-2099,2101-2204 switchport trunk allowed vlan add 2206-2899,2901-3472,3474,3476-3478,3480-4094 switchport mode trunk switchport nonegotiate mtu 2200 load-interval 30 mls qos trust cos channel-group 5 mode on interface TenGigabitEthernet7/3 description xxx portchannel 5 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 1-253,255-283,285-288,291-306,308-337,339-355 switchport trunk allowed vlan add 357-372,375,376,380-382,384-388,390-531 switchport trunk allowed vlan add 534-603,607-610,612-691,693-703,705-899 switchport trunk allowed vlan add 901-973,975-1156,1158-1207,1209-1252 switchport trunk allowed vlan add 1254-1268,1270,1271,1274-1276,1278-1296 switchport trunk allowed vlan add 1298-1356,1358-1383,1385-1422,1424-1513 switchport trunk allowed vlan add 1515-1524,1526-1604,1606,1608-1628,1630 switchport trunk allowed vlan add 1632-1968,1971-1979,1981-2099,2101-2204 switchport trunk allowed vlan add 2206-2899,2901-3472,3474,3476-3478,3480-4094 switchport mode trunk switchport nonegotiate mtu 2200 load-interval 30 mls qos trust cos channel-group 5 mode on site#sh etherchannel 5 detail Group state = L2 Ports: 2 Maxports = 8 Port-channels: 1 Max Port-channels = 1 Protocol:- Minimum Links: 0 Ports in the group: --- Port: Te7/1 Port state= Up Mstr In-Bndl Channel group = 5 Mode = On Gcchange = - Port-channel = Po5 GC = - Pseudo port-channel = Po5 Port index= 0 Load = 0x55 Protocol =- Mode = LACP Age of the port in the current state: 160d:04h:22m:01s Port: Te7/3 Port state= Up Mstr In-Bndl Channel group = 5 Mode = On Gcchange = - Port-channel = Po5 GC = - Pseudo port-channel = Po5 Port index= 1 Load = 0xAA Protocol =- Mode = LACP
