Re: [c-nsp] "MPLS in the SDN Era" New book
I wouldn’t disagree Nick Ryce Fluency Communications (Commsworld Ltd T/A) T: +44 (0) 330 121 1000 www.fluency.net.uk <http://www.fluency.net.uk/> n...@fluency.net.uk <mailto:char...@fluency.net.uk> On 27/01/2016, 19:12, "cisco-nsp on behalf of Aaron" <cisco-nsp-boun...@puck.nether.net on behalf of aar...@gvtc.com> wrote: >Thanks > >...i guess Ivan's "MPLS Bible 1.0" would be his MPLS and VPN Architectures Vol >1 and 2... true ? > >Aaron > >-Original Message- >From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of david >roy >Sent: Monday, January 25, 2016 5:30 AM >To: cisco-nsp@puck.nether.net >Subject: [c-nsp] "MPLS in the SDN Era" New book > >Hello > > > >I just wanted to share with all of you that the new "MPLS in the SDN Era" >book is already shipping. I know well the two authors and the book, and I can >certainly recommend it. > > > >This book's focus is interoperability. Its 900+ pages cover a wide range of >MPLS technologies, illustrated with real interoperable scenarios that combine >Junos and IOS XR devices. > > > >"In case you’re wondering how one could integrate the traditional >protocol-focused world of MPLS with the new software-defined world, you came >to the right place. This book has the potential to become the MPLS Bible 2.0." > > > >Ivan Pepelnjak, iNetwork Architect, www.ipSpace.net > > > >Here is the list of chapters, which you can find in more detail (together with >the full table of contents) in O'Reilly sampler: > > > >Chapter 1, Introduction to MPLS and SDN > >Chapter 2, The Four MPLS Builders : LDP, RSVP-TE, IGP (IS-IS, OSPF) SPRING, >and BGP > >Chapter 3, Layer 3 Unicast MPLS Services (6PE, L3VPN) > >Chapter 4, Internet Multicast Over MPLS > >Chapter 5, Multicast VPN > >Chapter 6, Point-to-Point Layer 2 VPNs > >Chapter 7, Virtual Private LAN Service (VPLS) > >Chapter 8, Ethernet VPN (EVPN), featuring EVPN MPLS, EVPN VXLAN, PBB-EVPN > >Chapter 9, Inter-Domain MPLS Services > >Chapter 10, Underlay and Overlay Architectures > >Chapter 11, Network Virtualization Overlays, featuring OpenContrail > >Chapter 12, Network Function Virtualization (NFV) > >Chapter 13, Introduction to Traffic Engineering > >Chapter 14, TE Bandwidth Reservations > >Chapter 15, Centralized Traffic Engineering, featuring Northstar > >Chapter 16, Scaling MPLS Transport and Seamless MPLS > >Chapter 17, Scaling MPLS Services > >Chapter 18, Transit Fast Restoration Based, featuring LFA, RLFA, TI-LFA, >TI-FRR, and MRT > >Chapter 19, Transit Fast Restoration Based on the RSVP-TE > >Chapter 20, FIB Optimization for Fast Restoration > >Chapter 21, Egress Service Fast Restoration > > > >Regards > >David > > > > > >*David Roy * > >*IP/MPLS NOC engineer - Orange France* > >SkypeID : davidroy.35 > >*JNCIE x3 (SP #703 ; ENT #305 ; SEC #144)* >___ >cisco-nsp 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] NTP DDoS
You can check for open ntp servers within your AS with the following:- http://openntpproject.org/searchby-asn.cgi?search_asn=56595 Swap 56595 for your ASN :) Nick On 13 Feb 2014, at 02:12, SilverTip257 silvertip...@gmail.com wrote: On Wed, Feb 12, 2014 at 2:36 PM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote: Something I can point customers to for testing their own set ups. ;) What I was trying to say is that openntp project URL is something I can point customers at and they should understand. Some of my customers are dense. Sadly, a few of them try to tell me that information I give them doesn't work. But when they say hey, here's my credentials, why don't you fix it for me? ... I come to find (yes, I'm a nice guy) that everything I sent them was spot on (as I expected). Copy+paste is over-rated. o_O On a Linux or mac ntpdc -c monlist xxx.xxx.xxx.xxx Yep. And loopinfo and iostats commands. nmap has a ntp-monlist script that is helpful (combined with the grep-able output option). I'm about due for running another ntp-monlist scan ... [when DNS amplification attacks were real bad a few months ago, we told a customer to disable DNS recursion ... he instead shut off bind/named for that day and turned it back on some time later]. If you get a reply (which will consist of a list of IP addresses that have sync'd with the daemon) then the server has a non optimal config. ... and if it's already been found by others they will all be listed. .. You might even see openntp project and team cymru servers listed ;) Alan -- ---~~.~~--- Mike // SilverTip257 // ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 ___ cisco-nsp 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] Possible split horizon issue with bgp signalled vpls
Just a note to say that after the upgrade we are back in business :) Nick On 20 Nov 2013, at 04:44, Pete Lumbis alum...@gmail.commailto:alum...@gmail.com wrote: Any idea why Switch 3 has remote label 28 instead of 48? Do you know if the issue is unidirectional or bidirectional? That is, can Sw2 send to Sw3 but Sw3 can't send back? On Mon, Nov 18, 2013 at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi, I’m tearing my hair out with this one and can’t figure out how to resolve it. I have 3 switches that have a BGP signalled VPLS with customer routers hanging off the end of all 3 ( one switch has 2 cpe ) All have the RD 56595:4 and RT 56595:4 All pseudo wires are up between the switches with config snippets below:- Switch 1 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 3, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 903 attachment circuits: Vlan903 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100033 46.226.0.9 2 402 39 Y pseudowire100037 46.226.0.14 1 401 49 Y This switch has 1 cpe with any vlan tags stripped and can ping all devices on the other switches Switch 2 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 1, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 11 attachment circuits: Vlan11 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100015 46.226.0.12 3 49 401 Y pseudowire100018 46.226.0.9 2 48 37 Y This switch has 2 cpe’s with any vlan tags stripped. They can ping each other and the device connected to switch 1 but cannot ping device on switch 3 Switch 3 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 2, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 4 attachment circuits: Vlan4 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100028 46.226.0.12 3 39 402 Y pseudowire100027 46.226.0.14 1 37 28 Y This switch has 1 cpe device connected with any vlan tags stripped and can only ping the device on switch 1 Each switch can see all the correct mac addresses. It sounds like split horizon but I assumed this was only to do with the local switch? All devices are running 15.3(3)S Any help much appreciated. Nick ___ 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] Possible split horizon issue with bgp signalled vpls
Hi Jason, CSCuh05321 says it is fixed in the S1 release so would that not mean that it is also in S1a? Nick On 19 Nov 2013, at 03:50, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Just be mindful of CSCuh05321 if you are going to try S1a. If you think you might hit that, I'd suggest moving to static vpls and skip that release until it's fixed. Also, with S1a, look at CSCtl54835 and verify or else your isis adjacencies will break. Sent from my iPhone On Nov 18, 2013, at 10:08 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Just found 1 switch on 15.3(2)S so may be worth a punt and upgrade Nick On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi, I’m tearing my hair out with this one and can’t figure out how to resolve it. I have 3 switches that have a BGP signalled VPLS with customer routers hanging off the end of all 3 ( one switch has 2 cpe ) All have the RD 56595:4 and RT 56595:4 All pseudo wires are up between the switches with config snippets below:- Switch 1 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 3, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 903 attachment circuits: Vlan903 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100033 46.226.0.9 2 402 39 Y pseudowire100037 46.226.0.14 1 401 49 Y This switch has 1 cpe with any vlan tags stripped and can ping all devices on the other switches Switch 2 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 1, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 11 attachment circuits: Vlan11 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100015 46.226.0.12 3 49 401 Y pseudowire100018 46.226.0.9 2 48 37 Y This switch has 2 cpe’s with any vlan tags stripped. They can ping each other and the device connected to switch 1 but cannot ping device on switch 3 Switch 3 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 2, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 4 attachment circuits: Vlan4 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100028 46.226.0.12 3 39 402 Y pseudowire100027 46.226.0.14 1 37 28 Y This switch has 1 cpe device connected with any vlan tags stripped and can only ping the device on switch 1 Each switch can see all the correct mac addresses. It sounds like split horizon but I assumed this was only to do with the local switch? All devices are running 15.3(3)S Any help much appreciated. Nick ___ 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/
[c-nsp] Possible split horizon issue with bgp signalled vpls
Hi, I’m tearing my hair out with this one and can’t figure out how to resolve it. I have 3 switches that have a BGP signalled VPLS with customer routers hanging off the end of all 3 ( one switch has 2 cpe ) All have the RD 56595:4 and RT 56595:4 All pseudo wires are up between the switches with config snippets below:- Switch 1 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 3, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 903 attachment circuits: Vlan903 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100033 46.226.0.9 2 402 39 Y pseudowire100037 46.226.0.14 1 401 49 Y This switch has 1 cpe with any vlan tags stripped and can ping all devices on the other switches Switch 2 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 1, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 11 attachment circuits: Vlan11 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100015 46.226.0.12 3 49 401 Y pseudowire100018 46.226.0.9 2 48 37 Y This switch has 2 cpe’s with any vlan tags stripped. They can ping each other and the device connected to switch 1 but cannot ping device on switch 3 Switch 3 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 2, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 4 attachment circuits: Vlan4 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100028 46.226.0.12 3 39 402 Y pseudowire100027 46.226.0.14 1 37 28 Y This switch has 1 cpe device connected with any vlan tags stripped and can only ping the device on switch 1 Each switch can see all the correct mac addresses. It sounds like split horizon but I assumed this was only to do with the local switch? All devices are running 15.3(3)S Any help much appreciated. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Possible split horizon issue with bgp signalled vpls
Hi Pshem, output below switch 1 Local intf Local circuit Dest addressVC ID Status - -- --- -- -- VFI FLVPLS004 vfi46.226.0.9 4 UP VFI FLVPLS004 vfi46.226.0.14 4 UP switch 2 Local intf Local circuit Dest addressVC ID Status - -- --- -- -- VFI FLVPLS004 vfi46.226.0.9 4 UP VFI FLVPLS004 vfi46.226.0.12 4 UP switch 3 Local intf Local circuit Dest addressVC ID Status - -- --- -- -- VFI FLVPLS004 vfi46.226.0.12 4 UP VFI FLVPLS004 vfi46.226.0.14 4 UP We are not using targeted ldp at this time. All switches are using rsvp -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.ukmailto:n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 19 Nov 2013, at 00:31, Pshem Kowalczyk pshe...@gmail.commailto:pshe...@gmail.com wrote: Hi, I assume here you're running ME3600x. Split horizon works by stopping any packets that arrived on one pseudowire from leaving on another pseudowire. Attachment circuit to another attachment circuit is not affected (unless you make add them to another split-horizon group manually). Can you show the output of 'sh mpls l2 vc' Do you also run targeted LDP between those devices? kind regards Pshem On 19 November 2013 09:05, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi, I’m tearing my hair out with this one and can’t figure out how to resolve it. I have 3 switches that have a BGP signalled VPLS with customer routers hanging off the end of all 3 ( one switch has 2 cpe ) All have the RD 56595:4 and RT 56595:4 All pseudo wires are up between the switches with config snippets below:- Switch 1 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 3, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 903 attachment circuits: Vlan903 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100033 46.226.0.9 2 402 39 Y pseudowire100037 46.226.0.14 1 401 49 Y This switch has 1 cpe with any vlan tags stripped and can ping all devices on the other switches Switch 2 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 1, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 11 attachment circuits: Vlan11 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100015 46.226.0.12 3 49 401 Y pseudowire100018 46.226.0.9 2 48 37 Y This switch has 2 cpe’s with any vlan tags stripped. They can ping each other and the device connected to switch 1 but cannot ping device on switch 3 Switch 3 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 2, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 4 attachment circuits: Vlan4 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100028 46.226.0.12 3 39 402 Y pseudowire100027 46.226.0.14 1 37 28 Y This switch has 1 cpe device connected with any vlan tags stripped and can only ping the device on switch 1 Each switch can see all the correct mac addresses. It sounds like split horizon but I assumed this was only to do with the local switch? All devices are running 15.3(3)S Any help much appreciated. Nick ___ 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] Possible split horizon issue with bgp signalled vpls
Hi Jason, It sounds very similar. If a bgp session was established direct rather than via an RR would this fix it I wonder? Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.ukmailto:n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi, I’m tearing my hair out with this one and can’t figure out how to resolve it. I have 3 switches that have a BGP signalled VPLS with customer routers hanging off the end of all 3 ( one switch has 2 cpe ) All have the RD 56595:4 and RT 56595:4 All pseudo wires are up between the switches with config snippets below:- Switch 1 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 3, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 903 attachment circuits: Vlan903 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100033 46.226.0.9 2 402 39 Y pseudowire100037 46.226.0.14 1 401 49 Y This switch has 1 cpe with any vlan tags stripped and can ping all devices on the other switches Switch 2 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 1, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 11 attachment circuits: Vlan11 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100015 46.226.0.12 3 49 401 Y pseudowire100018 46.226.0.9 2 48 37 Y This switch has 2 cpe’s with any vlan tags stripped. They can ping each other and the device connected to switch 1 but cannot ping device on switch 3 Switch 3 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 2, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 4 attachment circuits: Vlan4 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100028 46.226.0.12 3 39 402 Y pseudowire100027 46.226.0.14 1 37 28 Y This switch has 1 cpe device connected with any vlan tags stripped and can only ping the device on switch 1 Each switch can see all the correct mac addresses. It sounds like split horizon but I assumed this was only to do with the local switch? All devices are running 15.3(3)S Any help much appreciated. Nick ___ 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] Possible split horizon issue with bgp signalled vpls
Doesn’t make a diff if established direct :( On 19 Nov 2013, at 02:46, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi Jason, It sounds very similar. If a bgp session was established direct rather than via an RR would this fix it I wonder? Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.ukmailto:n...@fluency.net.ukmailto:n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi, I’m tearing my hair out with this one and can’t figure out how to resolve it. I have 3 switches that have a BGP signalled VPLS with customer routers hanging off the end of all 3 ( one switch has 2 cpe ) All have the RD 56595:4 and RT 56595:4 All pseudo wires are up between the switches with config snippets below:- Switch 1 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 3, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 903 attachment circuits: Vlan903 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100033 46.226.0.9 2 402 39 Y pseudowire100037 46.226.0.14 1 401 49 Y This switch has 1 cpe with any vlan tags stripped and can ping all devices on the other switches Switch 2 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 1, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 11 attachment circuits: Vlan11 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100015 46.226.0.12 3 49 401 Y pseudowire100018 46.226.0.9 2 48 37 Y This switch has 2 cpe’s with any vlan tags stripped. They can ping each other and the device connected to switch 1 but cannot ping device on switch 3 Switch 3 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 2, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 4 attachment circuits: Vlan4 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100028 46.226.0.12 3 39 402 Y pseudowire100027 46.226.0.14 1 37 28 Y This switch has 1 cpe device connected with any vlan tags stripped and can only ping the device on switch 1 Each switch can see all the correct mac addresses. It sounds like split horizon but I assumed this was only to do with the local switch? All devices are running 15.3(3)S Any help much appreciated. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto: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/ ___ cisco-nsp 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] Possible split horizon issue with bgp signalled vpls
Just found 1 switch on 15.3(2)S so may be worth a punt and upgrade Nick On 19 Nov 2013, at 02:02, Jason Lixfeld ja...@lixfeld.camailto:ja...@lixfeld.ca wrote: Issues I was having with BGP signalled VPLS a couple of months ago in 15.3(2)S1 resulted in filing CSCui46390. I'd otherwise suggest trying 15.3(3)S1a to see fix works, but that version seems to have introduced CSCuh05321, so I think that might end badly for you; it did for me :( On Nov 18, 2013, at 3:05 PM, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi, I’m tearing my hair out with this one and can’t figure out how to resolve it. I have 3 switches that have a BGP signalled VPLS with customer routers hanging off the end of all 3 ( one switch has 2 cpe ) All have the RD 56595:4 and RT 56595:4 All pseudo wires are up between the switches with config snippets below:- Switch 1 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 3, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 903 attachment circuits: Vlan903 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100033 46.226.0.9 2 402 39 Y pseudowire100037 46.226.0.14 1 401 49 Y This switch has 1 cpe with any vlan tags stripped and can ping all devices on the other switches Switch 2 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 1, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 11 attachment circuits: Vlan11 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100015 46.226.0.12 3 49 401 Y pseudowire100018 46.226.0.9 2 48 37 Y This switch has 2 cpe’s with any vlan tags stripped. They can ping each other and the device connected to switch 1 but cannot ping device on switch 3 Switch 3 VFI name: FLVPLS004, state: up, type: multipoint, signaling: BGP VPN ID: 4, VE-ID: 2, VE-SIZE: 10 RD: 56595:4, RT: 56595:4, 56595:4 Bridge-Domain 4 attachment circuits: Vlan4 Neighbors connected via pseudowires: Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100028 46.226.0.12 3 39 402 Y pseudowire100027 46.226.0.14 1 37 28 Y This switch has 1 cpe device connected with any vlan tags stripped and can only ping the device on switch 1 Each switch can see all the correct mac addresses. It sounds like split horizon but I assumed this was only to do with the local switch? All devices are running 15.3(3)S Any help much appreciated. Nick ___ 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/
[c-nsp] ME3600 QoS
Hi Guys, I am trying to to do some basic QoS to prioritise packets marked with DSCP EF on EFP's but keep getting errors as below: SW1.WAV-EDI(config-if-srv)#service-policy output Voip QoS: Invalid target for service-policy QoS: Configuration errors for policy map Voip Class-map and policy map as below ( I have just used priority 1 as a basic test and know it can in some circumstances starve other queues ) class-map match-any Voice match ip dscp ef ! policy-map Voip class Voice priority level 1 class class-default bandwidth remaining percent 70 Any help much appreciated. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ME3600 QoS
Hi Adam, Just reached the same conclusion. Can be applied to the member ports of the channel. Also you can't apply service policies to EFP's on a port channel either. Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 07/08/2013 12:13, Adam Vitkovsky adam.vitkov...@swan.sk wrote: Hi Nick, QoS: Invalid target for service-policy I got the same error when I tried to apply a service-policy to port-channel interface and learned that policy has to be applied to a physical ports associated with the channel instead. So I'm wondering whether your SW version supports applying of service-policies under EFPs (service-instance). 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/
Re: [c-nsp] ME3600 VPLS configuration with L2VPN CLI
Hi Jason, Just tested this myself. Only appears to work if the SVI is created and the member statement added there. Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 26/06/2013 02:07, Jason Lixfeld ja...@lixfeld.ca wrote: So I'm just trying to understand how VPLS is 'supposed' to work on ME3600s... This seems to work: ! interface GigabitEthernet0/3 description Facing CE switchport trunk allowed vlan none switchport mode trunk logging event link-status no cdp enable service instance 1 ethernet encapsulation dot1q 4013 rewrite ingress tag pop 1 symmetric ! ! bridge-domain 4013 member GigabitEthernet0/3 service-instance 1 ! interface Vlan4013 vrf forwarding management no ip address member vfi management ! #show l2vpn vfi name management Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No VFI name: management, state: up, type: multipoint, signaling: BGP VPN ID: 4013, VE-ID: 10129, VE-SIZE: 10 RD: 21949:2194904013, RT: 21949:4013, 21949:2194904013 Bridge-Domain 4013 attachment circuits: Vlan4013 Pseudo-port interface: pseudowire100036 Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100037 72.15.50.33 10033 299 354 Y However this does not: ! interface GigabitEthernet0/3 description Facing CE switchport trunk allowed vlan none switchport mode trunk logging event link-status no cdp enable service instance 1 ethernet encapsulation dot1q 4013 rewrite ingress tag pop 1 symmetric ! ! bridge-domain 4013 member GigabitEthernet0/3 service-instance 1 member vfi management ! #show l2vpn vfi name management Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No VFI name: management, state: down, type: multipoint, signaling: BGP VPN ID: 4013, VE-ID: 10129, VE-SIZE: 10 RD: 21949:2194904013, RT: 21949:4013, 21949:2194904013 Bridge-Domain 4013 attachment circuits: Pseudo-port interface: pseudowire100036 Interface Peer AddressVE-ID Local Label Remote LabelS pseudowire100037 72.15.50.33 10033 299 354 Y So even though in the latter example, vfi management is a member of bridge-domain 4013, it can't seem to find the attachment circuit. I get that the AC wouldn't be Vlan4013, but I'd sorta expect it to know that it's Gi0/3 si 1. I'm assuming that since we can now map a vfi to a bridge-domain, an SVI is no longer required, unless the VPLS instance is routed VPLS; we'd need somewhere to apply the IP and mask. Is this an incorrect assumption or is something not working that really should be working? 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] Changing ve id doesn't withdraw old prefixes
Hi Jason, It was myself on the packet exchange forum with the issue. After removing the config and reading the issue resolved itself. Have you tried removing the full config for the vfi and associated member ports and re-adding? Nick On 21/06/2013 00:37, Pshem Kowalczyk pshe...@gmail.com wrote: Hi, It does look like a bug. How often would you change ve id though? I'd expect that to be fairly static once set up. We had a number of issues of that sort (Cisco expected the number/id to be static during the lifetime of a service, but we changed it). Most of those bugs ultimately got fixed, but in some cases we were told that the conditions are too unusual, or there is some other workaround. 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] Layer 2 Traffic Monitoring
Hi Samar, Is the IX traffic and internet traffic on the same vlan? If its split between 2 you could use service instances on the ports which can be graphed via snmp. Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 11/06/2013 21:33, Samar Chokutaev s.chokut...@gmail.com wrote: Hello, everyone Could you please help me in trouble with traffic monitoring. We have IX-network with a pair ME3400 with only Layer 2 enabled. All providers connected to this switches communicate directly with each other (we use route servers). Now we need traffic monitoring for IX network. But the problem is that some of these providers buy Internet connection from the same link. That's why we need to separate internet traffic from the local. Is there any solution for this problem, except the usage of Netflow? Thank you in advance. Kind regards, Samar ___ cisco-nsp 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: BGP Signalled VPLS on ME3600
Hi Gustav,
Yep, as below:-
sw1.sco-edi-NEW#show mpls for 46.226.0.12 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
None 306496 46.226.0.12/32 0 Tu1point2point
MAC/Encaps=14/18, MRU=9000, Label Stack{306496}, via Te0/2
A8D0E55DD93788F07792BCDB8847 4AD4
No output feature configured
SW1.THN-LON#show mpls for 46.226.0.10 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
None 304720 46.226.0.10/32 0 Tu0point2point
MAC/Encaps=14/18, MRU=9000, Label Stack{304720}, via Te0/2
A8D0E55DEB3D88F077938CDB8847 4A65
--
Nick Ryce
Fluency Communications Ltd.
e. n...@fluency.net.uk
w. http://fluency.net.uk/
t. 0845 874 7000
From: gustav.ulan...@steria.semailto:gustav.ulan...@steria.se
gustav.ulan...@steria.semailto:gustav.ulan...@steria.se
Date: Friday, 7 June 2013 09:37
To: Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk
Cc: cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net, cisco-nsp
cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net
Subject: Re: [c-nsp] Fwd: BGP Signalled VPLS on ME3600
Hello.
Do you have a corresponding entry in the mpls forwarding database for the next
hop address?
Bästa hälsningar / Best regards,
Gustav Uhlander
Communication Infrastructure Engineer
Steria AB
Kungsbron 13
Box 169
SE-101 23 Stockholm
Sweden
Tel: +46 8 622 42 15
Fax: +46 8 622 42 23
Mobile: +46 70 962 71 03
gustav.ulan...@steria.semailto:gustav.ulan...@steria.se
www.steria.se
From:Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk
To:cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net
Date:2013-06-06 20:11
Subject:[c-nsp] Fwd: BGP Signalled VPLS on ME3600
Sent by:cisco-nsp
cisco-nsp-boun...@puck.nether.netmailto:cisco-nsp-boun...@puck.nether.net
Hi,
Im having a strange issue with a BGP signalled VPLS on my ME3600. I'm running
15.3.2(s).
The VFI comes up but the virtual circuit stays down with the following error:-
SW1.THN-LON#show mpls L2transport vc 501 detail
Local interface: VFI FLVPLS001 vfi up
Interworking type is Ethernet
Destination address: 46.226.0.10, VC ID: 501, VC status: down
Last error: MPLS dataplane reported a fault to the nexthop
Output interface: none, imposed label stack {}
Preferred path: not configured
Default path: no route
No adjacency
Create time: 00:19:42, last status change time: 00:19:42
Last label FSM state change time: 00:19:42
Signaling protocol: BGP
Status TLV support (local/remote) : Not Applicable
LDP route watch : Not Applicable
Label/status state machine: activating, LruRruD
Last local dataplane status rcvd: DOWN(pw-tx-fault)
Last BFD dataplane status rcvd: Not Applicable
Last BFD peer monitor status rcvd: Not Applicable
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: DOWN(pw-rx-fault)
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: Not Applicable
Last remote LDP TLVstatus rcvd: Not Applicable
Last remote LDP ADJstatus rcvd: Not Applicable
MPLS VC labels: local 27, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Control Word: Off
Dataplane:
SSM segment/switch IDs: 0/10075 (used), PWID: 12
VC statistics:
transit packet totals: receive 0, send 0
transit byte totals: receive 0, send 0
transit packet drops: receive 0, seq error 0, send 0
The next hop is available and routable so not quite sure what the issue is.
Any help greatly appreciated.
Nick
___
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/
[c-nsp] Fwd: BGP Signalled VPLS on ME3600
Hi,
Im having a strange issue with a BGP signalled VPLS on my ME3600. I'm running
15.3.2(s).
The VFI comes up but the virtual circuit stays down with the following error:-
SW1.THN-LON#show mpls L2transport vc 501 detail
Local interface: VFI FLVPLS001 vfi up
Interworking type is Ethernet
Destination address: 46.226.0.10, VC ID: 501, VC status: down
Last error: MPLS dataplane reported a fault to the nexthop
Output interface: none, imposed label stack {}
Preferred path: not configured
Default path: no route
No adjacency
Create time: 00:19:42, last status change time: 00:19:42
Last label FSM state change time: 00:19:42
Signaling protocol: BGP
Status TLV support (local/remote) : Not Applicable
LDP route watch : Not Applicable
Label/status state machine: activating, LruRruD
Last local dataplane status rcvd: DOWN(pw-tx-fault)
Last BFD dataplane status rcvd: Not Applicable
Last BFD peer monitor status rcvd: Not Applicable
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: DOWN(pw-rx-fault)
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: Not Applicable
Last remote LDP TLVstatus rcvd: Not Applicable
Last remote LDP ADJstatus rcvd: Not Applicable
MPLS VC labels: local 27, remote 16
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Control Word: Off
Dataplane:
SSM segment/switch IDs: 0/10075 (used), PWID: 12
VC statistics:
transit packet totals: receive 0, send 0
transit byte totals: receive 0, send 0
transit packet drops: receive 0, seq error 0, send 0
The next hop is available and routable so not quite sure what the issue is.
Any help greatly appreciated.
Nick
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Signalled VPLS
Had a call with cisco tac and they managed to get it working by removing the RD. No idea why this resolved it. Now to try and get it to working with a juniper PE. Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 16/04/2013 13:37, Nick Ryce n...@fluency.net.uk wrote: Hi, I have 2 x ME3600x running me360x-universalk9-mz.153-2.S and am looking to use the new VPLS BGP signalling functionality. I am using RSVP with the topology attached but I cannot get traffic to pass. Any ideas? Configs as below. Any help with debug commands would also be greatly appreciated. hostname PE1 ! ! ! no aaa new-model ip routing ! ! ! ! ip name-server 8.8.8.8 ! ! mpls traffic-eng tunnels l2vpn vfi context lab vpn id 512 autodiscovery bgp signaling bgp ve id 1 ve range 11 rd 172.16.1.1:512 route-target export 56595:512 route-target import 56595:512 ! vlan 512 name lab ! l2 router-id 172.16.1.1 ! ! ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ip ospf 1 area 0.0.0.0 ! interface Tunnel0 description PE1-to-PE2 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.2.2 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel1 description PE1-toPE3 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.3.3 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface GigabitEthernet0/1 no switchport ip address 10.0.0.1 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth percent 100 ! interface GigabitEthernet0/2 switchport access vlan 512 ! router ospf 1 router-id 172.16.1.1 network 10.0.0.0 0.0.0.3 area 0.0.0.0 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0.0.0.0 ! router bgp 56595 bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart no bgp default ipv4-unicast neighbor 172.16.2.2 remote-as 56595 neighbor 172.16.2.2 update-source Loopback0 neighbor 172.16.3.3 remote-as 56595 neighbor 172.16.3.3 update-source Loopback0 ! address-family ipv4 neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended exit-address-family ! address-family vpnv4 neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended exit-address-family ! address-family l2vpn vpls neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.2.2 prefix-length-size 2 neighbor 172.16.2.2 suppress-signaling-protocol ldp neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended neighbor 172.16.3.3 suppress-signaling-protocol ldp exit-address-family hostname PE3 ! ! ! no aaa new-model ip routing ! ! ! ! ip name-server 8.8.8.8 ipv6 multicast rpf use-bgp ! ! mpls traffic-eng tunnels l2vpn vfi context lab vpn id 512 autodiscovery bgp signaling bgp ve id 3 ve range 11 rd 172.16.3.3:512 route-target export 56595:512 route-target import 56595:512 vlan 512 name test ! ! ! ! interface Loopback0 ip address 172.16.3.3 255.255.255.255 ip ospf 1 area 0.0.0.0 ! interface Tunnel0 description PE3-to-PE2 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.2.2 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel1 description PE3-to-PE1 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.1.1 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface GigabitEthernet0 ip address 46.226.1.178 255.255.255.248 speed auto duplex auto negotiation auto ! interface GigabitEthernet0/1 no switchport ip address 10.0.0.6 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth percent 100 ! interface GigabitEthernet0/2 switchport access vlan 512 ! interface Vlan512 no ip address member vfi lab ! router ospf 1 router-id 172.16.3.3 network 10.0.0.4 0.0.0.3 area 0.0.0.0 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0.0.0.0 ! router bgp 56595 bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart no bgp default ipv4-unicast neighbor 172.16.1.1 remote-as 56595 neighbor 172.16.1.1 update-source Loopback0 neighbor 172.16.2.2 remote-as 56595 neighbor 172.16.2.2 update-source Loopback0 ! address-family ipv4 neighbor 172.16.1.1 activate neighbor 172.16.1.1 send-community extended neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended exit-address-family ! address-family vpnv4 neighbor 172.16.1.1 activate neighbor 172.16.1.1 send-community extended neighbor 172.16.2.2 activate neighbor 172.16.2.2 send
Re: [c-nsp] BGP Signalled VPLS
VPLS using BGP signalling is now available so assume multihoming can be done also. Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 23/04/2013 13:44, William Jackson william.jack...@gibtele.com wrote: So is BGP VPLS multi homing now available in cisco. Like it is in Junos? Last time I checked I could not see anything plans for it? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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 Signalled VPLS
Hi Aaron, The VE ID etc is for BGP signalling. Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 From: Aaron aar...@gvtc.commailto:aar...@gvtc.com Date: Monday, 22 April 2013 14:28 To: 'Waris Sagheer (waris)' wa...@cisco.commailto:wa...@cisco.com, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk, cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: RE: [c-nsp] BGP Signalled VPLS I ran vpls w/bgp ad w/ldg sig between (2) asr9k’s and (4) me3600’s and I didn’t have to use ve id nor ve range…. Is there something I would miss out on without using ve id or ve range? Also, is there a default value associated with ve id or ve range that was enacted in the absence of my not explicitly configuring it ? Waris, if the VE ID is for unique PE VPLS Edge ID assignment, would that mean that my configuration without the ve id configured would have duplicate VE ID’s per PE? Or maybe there is a autoassignment thing that occurs. Perhaps I’ll set it up again and see what happens, as I mentioned previously I had removed my vpls architecture for l3vpn preference. Aaron From: Waris Sagheer (waris) [mailto:wa...@cisco.com] Sent: Sunday, April 21, 2013 10:10 PM To: Nick Ryce; Aaron; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Signalled VPLS All PEs within a given VPLS are assigned a unique VPLS Edge device ID (VE ID). Nick is right about BGP NLRI, VPLS BGP NLRI (RFC 4761) AFI = 25 (L2VPN) SAFI = 65 (VPLS) VE ID VE Block Offset (VBO) VE Block Size (VBS) Label Base (LB) Best Regards, [http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg] Waris Sagheer Technical Marketing Manager Service Provider Access Group wa...@cisco.commailto:wa...@cisco.com Phone: +1 408 853 6682 Mobile: +1 408 835 1389 CCIE - 19901 [Think before you print.] Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html . From: Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk Date: Tuesday, April 16, 2013 7:52 AM To: aar...@gvtc.commailto:aar...@gvtc.com aar...@gvtc.commailto:aar...@gvtc.com, cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Signalled VPLS Its part for the BGP L2VPN NLRI as far as I'm aware. -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.ukmailto:n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 16/04/2013 15:50, Aaron aar...@gvtc.commailto:aar...@gvtc.com wrote: Anyone know what and why to use this ve stuff? I didn't use it during my vpls (ios-ioxr) trial run in my network and never understood what it was for... ve id 1 ve range 11 Aaron -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce Sent: Tuesday, April 16, 2013 7:41 AM To: Nick Ryce; cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Signalled VPLS Apologies the attachment has went through. ASCII art as below PE1---PE2PE3 PE1 and PE3 are ME3600's and PE2 is a Juniper SRX. From PE2 labels are being pushed/popped correctly. Nick On 16/04/2013 13:37, Nick Ryce n...@fluency.net.ukmailto:n...@fluency.net.uk wrote: Hi, I have 2 x ME3600x running me360x-universalk9-mz.153-2.S and am looking to use the new VPLS BGP signalling functionality. I am using RSVP with the topology attached but I cannot get traffic to pass. Any ideas? Configs as below. Any help with debug commands would also be greatly appreciated. hostname PE1 ! ! ! no aaa new-model ip routing ! ! ! ! ip name-server 8.8.8.8 ! ! mpls traffic-eng tunnels l2vpn vfi context lab vpn id 512 autodiscovery bgp signaling bgp ve id 1 ve range 11 rd 172.16.1.1:512 route-target export 56595:512 route-target import 56595:512 ! vlan 512 name lab ! l2 router-id 172.16.1.1 ! ! ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ip ospf 1 area 0.0.0.0 ! interface Tunnel0 description PE1-to-PE2 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.2.2 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel1 description PE1-toPE3 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.3.3 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface GigabitEthernet0/1 no switchport ip address 10.0.0.1
Re: [c-nsp] Network Test Plan
See the next post when he said it was posted to the wrong thread :) Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 19/04/2013 16:02, Ahmed Hilmy hilmy...@gmail.com wrote: Hello Ryan, actually i didnt get your point , would you clarify it for me ? On Fri, Apr 19, 2013 at 3:56 PM, Booth, Ryan rbo...@pantex.com wrote: This is true about the misses. From my own experience and what others have told me when a small or medium buffer is missed the frame/packet is usually dropped and requires a retransmission. For me this is evident in my IP-video traffic which suffers frame loss. Normal TCP traffic can just retransmit. Ryan Booth Blog.movingonesandzeros.net -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ahmed Hilmy Sent: Friday, April 19, 2013 1:17 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Network Test Plan Hello Friends, Alcatel-Lucent has completed our project deployment IP/MPLS Backbone, 7750 SR7 - 7750 SR12, they suggest test plan but i am thinking if i can ad some tests. Test Strategy: IGP, OSPF MPLS, LDP+RSVP+ LSP Fast Reroute VLL VPLS VPRN Any idea to share, and test to add your comment is warmly welcome Regards, Ahmed ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP Signalled VPLS
suppress-signaling-protocol ldp exit-address-family Tunnels are up in both directions. Output of some commands as below PE3#show l2vpn vfi name lab Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No VFI name: lab, state: up, type: multipoint, signaling: BGP VPN ID: 512, VE-ID: 3, VE-SIZE: 11 RD: 172.16.3.3:512, RT: 56595:512, 56595:512 Bridge-Domain 512 attachment circuits: Vlan512 Pseudo-port interface: pseudowire11 Interface Peer AddressVE-ID Local Label Remote LabelS PE1#show l2vpn vfi name lab Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No VFI name: lab, state: down, type: multipoint, signaling: BGP VPN ID: 512, VE-ID: 1, VE-SIZE: 11 RD: 172.16.1.1:512, RT: 56595:512, 56595:512 Bridge-Domain 512 attachment circuits: Vlan512 Pseudo-port interface: pseudowire13 Interface Peer AddressVE-ID Local Label Remote LabelS PE3#show bgp l2vpn vpls all BGP table version is 28, local router ID is 172.16.3.3 Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next HopMetric LocPrf Weight Path Route Distinguisher: 172.16.1.1:512 *i 172.16.1.1:512:VEID-1:Blk-1/136 172.16.1.1 0100 0 ? Route Distinguisher: 172.16.2.2:512 *i 172.16.2.2:512:VEID-2:Blk-1/136 172.16.2.2100 0 i *i 172.16.2.2:512:VEID-2:Blk-1/136 172.16.2.2100 0 i Route Distinguisher: 172.16.3.3:512 * 172.16.3.3:512:VEID-3:Blk-1/136 0.0.0.032768 ? PE1# show bgp l2vpn vpls all BGP table version is 39, local router ID is 172.16.1.1 Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next HopMetric LocPrf Weight Path Route Distinguisher: 172.16.1.1:512 * 172.16.1.1:512:VEID-1:Blk-1/136 0.0.0.032768 ? Route Distinguisher: 172.16.2.2:512 *i 172.16.2.2:512:VEID-2:Blk-1/136 172.16.2.2100 0 i *i 172.16.2.2:512:VEID-2:Blk-1/136 172.16.2.2100 0 i Route Distinguisher: 172.16.3.3:512 *i 172.16.3.3:512:VEID-3:Blk-1/136 172.16.3.3 0100 0 ? Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.ukmailto:n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 ___ cisco-nsp 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 Signalled VPLS
Apologies the attachment has went through. ASCII art as below PE1---PE2PE3 PE1 and PE3 are ME3600's and PE2 is a Juniper SRX. From PE2 labels are being pushed/popped correctly. Nick On 16/04/2013 13:37, Nick Ryce n...@fluency.net.uk wrote: Hi, I have 2 x ME3600x running me360x-universalk9-mz.153-2.S and am looking to use the new VPLS BGP signalling functionality. I am using RSVP with the topology attached but I cannot get traffic to pass. Any ideas? Configs as below. Any help with debug commands would also be greatly appreciated. hostname PE1 ! ! ! no aaa new-model ip routing ! ! ! ! ip name-server 8.8.8.8 ! ! mpls traffic-eng tunnels l2vpn vfi context lab vpn id 512 autodiscovery bgp signaling bgp ve id 1 ve range 11 rd 172.16.1.1:512 route-target export 56595:512 route-target import 56595:512 ! vlan 512 name lab ! l2 router-id 172.16.1.1 ! ! ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ip ospf 1 area 0.0.0.0 ! interface Tunnel0 description PE1-to-PE2 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.2.2 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel1 description PE1-toPE3 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.3.3 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface GigabitEthernet0/1 no switchport ip address 10.0.0.1 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth percent 100 ! interface GigabitEthernet0/2 switchport access vlan 512 ! router ospf 1 router-id 172.16.1.1 network 10.0.0.0 0.0.0.3 area 0.0.0.0 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0.0.0.0 ! router bgp 56595 bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart no bgp default ipv4-unicast neighbor 172.16.2.2 remote-as 56595 neighbor 172.16.2.2 update-source Loopback0 neighbor 172.16.3.3 remote-as 56595 neighbor 172.16.3.3 update-source Loopback0 ! address-family ipv4 neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended exit-address-family ! address-family vpnv4 neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended exit-address-family ! address-family l2vpn vpls neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.2.2 prefix-length-size 2 neighbor 172.16.2.2 suppress-signaling-protocol ldp neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended neighbor 172.16.3.3 suppress-signaling-protocol ldp exit-address-family hostname PE3 ! ! ! no aaa new-model ip routing ! ! ! ! ip name-server 8.8.8.8 ipv6 multicast rpf use-bgp ! ! mpls traffic-eng tunnels l2vpn vfi context lab vpn id 512 autodiscovery bgp signaling bgp ve id 3 ve range 11 rd 172.16.3.3:512 route-target export 56595:512 route-target import 56595:512 vlan 512 name test ! ! ! ! interface Loopback0 ip address 172.16.3.3 255.255.255.255 ip ospf 1 area 0.0.0.0 ! interface Tunnel0 description PE3-to-PE2 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.2.2 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel1 description PE3-to-PE1 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.1.1 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface GigabitEthernet0 ip address 46.226.1.178 255.255.255.248 speed auto duplex auto negotiation auto ! interface GigabitEthernet0/1 no switchport ip address 10.0.0.6 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth percent 100 ! interface GigabitEthernet0/2 switchport access vlan 512 ! interface Vlan512 no ip address member vfi lab ! router ospf 1 router-id 172.16.3.3 network 10.0.0.4 0.0.0.3 area 0.0.0.0 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0.0.0.0 ! router bgp 56595 bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart no bgp default ipv4-unicast neighbor 172.16.1.1 remote-as 56595 neighbor 172.16.1.1 update-source Loopback0 neighbor 172.16.2.2 remote-as 56595 neighbor 172.16.2.2 update-source Loopback0 ! address-family ipv4 neighbor 172.16.1.1 activate neighbor 172.16.1.1 send-community extended neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended exit-address-family ! address-family vpnv4 neighbor 172.16.1.1 activate neighbor 172.16.1.1 send-community extended neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended exit-address-family ! address-family l2vpn vpls neighbor
Re: [c-nsp] BGP Signalled VPLS
Its part for the BGP L2VPN NLRI as far as I'm aware. -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 16/04/2013 15:50, Aaron aar...@gvtc.com wrote: Anyone know what and why to use this ve stuff? I didn't use it during my vpls (ios-ioxr) trial run in my network and never understood what it was for... ve id 1 ve range 11 Aaron -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce Sent: Tuesday, April 16, 2013 7:41 AM To: Nick Ryce; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] BGP Signalled VPLS Apologies the attachment has went through. ASCII art as below PE1---PE2PE3 PE1 and PE3 are ME3600's and PE2 is a Juniper SRX. From PE2 labels are being pushed/popped correctly. Nick On 16/04/2013 13:37, Nick Ryce n...@fluency.net.uk wrote: Hi, I have 2 x ME3600x running me360x-universalk9-mz.153-2.S and am looking to use the new VPLS BGP signalling functionality. I am using RSVP with the topology attached but I cannot get traffic to pass. Any ideas? Configs as below. Any help with debug commands would also be greatly appreciated. hostname PE1 ! ! ! no aaa new-model ip routing ! ! ! ! ip name-server 8.8.8.8 ! ! mpls traffic-eng tunnels l2vpn vfi context lab vpn id 512 autodiscovery bgp signaling bgp ve id 1 ve range 11 rd 172.16.1.1:512 route-target export 56595:512 route-target import 56595:512 ! vlan 512 name lab ! l2 router-id 172.16.1.1 ! ! ! interface Loopback0 ip address 172.16.1.1 255.255.255.255 ip ospf 1 area 0.0.0.0 ! interface Tunnel0 description PE1-to-PE2 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.2.2 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel1 description PE1-toPE3 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.3.3 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface GigabitEthernet0/1 no switchport ip address 10.0.0.1 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth percent 100 ! interface GigabitEthernet0/2 switchport access vlan 512 ! router ospf 1 router-id 172.16.1.1 network 10.0.0.0 0.0.0.3 area 0.0.0.0 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0.0.0.0 ! router bgp 56595 bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart no bgp default ipv4-unicast neighbor 172.16.2.2 remote-as 56595 neighbor 172.16.2.2 update-source Loopback0 neighbor 172.16.3.3 remote-as 56595 neighbor 172.16.3.3 update-source Loopback0 ! address-family ipv4 neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended exit-address-family ! address-family vpnv4 neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended exit-address-family ! address-family l2vpn vpls neighbor 172.16.2.2 activate neighbor 172.16.2.2 send-community extended neighbor 172.16.2.2 prefix-length-size 2 neighbor 172.16.2.2 suppress-signaling-protocol ldp neighbor 172.16.3.3 activate neighbor 172.16.3.3 send-community extended neighbor 172.16.3.3 suppress-signaling-protocol ldp exit-address-family hostname PE3 ! ! ! no aaa new-model ip routing ! ! ! ! ip name-server 8.8.8.8 ipv6 multicast rpf use-bgp ! ! mpls traffic-eng tunnels l2vpn vfi context lab vpn id 512 autodiscovery bgp signaling bgp ve id 3 ve range 11 rd 172.16.3.3:512 route-target export 56595:512 route-target import 56595:512 vlan 512 name test ! ! ! ! interface Loopback0 ip address 172.16.3.3 255.255.255.255 ip ospf 1 area 0.0.0.0 ! interface Tunnel0 description PE3-to-PE2 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.2.2 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface Tunnel1 description PE3-to-PE1 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination 172.16.1.1 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic ! interface GigabitEthernet0 ip address 46.226.1.178 255.255.255.248 speed auto duplex auto negotiation auto ! interface GigabitEthernet0/1 no switchport ip address 10.0.0.6 255.255.255.252 mpls traffic-eng tunnels ip rsvp bandwidth percent 100 ! interface GigabitEthernet0/2 switchport access vlan 512 ! interface Vlan512 no ip address member vfi lab ! router ospf 1 router-id 172.16.3.3 network 10.0.0.4 0.0.0.3 area 0.0.0.0 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0.0.0.0 ! router bgp 56595 bgp log-neighbor-changes bgp graceful-restart restart-time 120 bgp graceful-restart stalepath-time 360 bgp graceful-restart
Re: [c-nsp] Internet inside a VRF?
Does memory usage not increase by putting all the internet routes in a VRF? Nick -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of michalis.bersi...@hq.cyta.gr Sent: 14 March 2012 09:47 To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Hi, Putting internet in a vrf is not that bad. I agree with some people say that separate the global routing table with vrf is easier, especially for networks that are deploying MPLS routers from scratch. I don't see any advantages from putting internet Prefixes in the global routing table. Best Regards, Michalis Bersimis -- Message: 1 Date: Tue, 13 Mar 2012 21:58:58 -0500 From: Ge Moua moua0...@umn.edu To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Internet inside a VRF? Message-ID: 4f600972.6040...@umn.edu Content-Type: text/plain; charset=windows-1252; format=flowed In RE networks, separation of commodity Internet-1 and Internet-2 traffic. -- Regards, Ge Moua University of Minnesota Alumnus Email: moua0...@umn.edu -- On 3/13/12 8:17 PM, Jose Madrid wrote: I would like to understand why you guys would do this? What is the reasoning behind this? Super granular control? Cant this level of granularity be achieved with route-maps? Sent from my iPhone On Mar 13, 2012, at 8:27 PM, Dan Armstrongd...@beanfield.com wrote: We have all our Internet peers and customers inside a VRF currently, and our Cisco SE thinks we're stark raving mad, and should redesign and put everything back in the global table. This is all on ASR 9Ks and 7600s. On 2012-03-13, at 8:12 PM, Pshem Kowalczyk wrote: Hi, On 14 March 2012 11:59, Dan Armstrongd...@beanfield.com wrote: I know this topic has been discussed a million times, but just wanted to get an updated opinion on how people are feeling about this: In a service provider network, how do people feel about putting the big Internet routing table, all their peers and customers inside a VRF? Keep the global table for just infrastructure links? In my previous role we've done just that. One internet VRF for all transit functions, separate vrfs for peering and customers and import-export statements to tie them all together. All done on ASR1k (mainly 1006, but a few of 1002 as well). 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/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- 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 Pulsant. Finally, the recipient should check this email and any attachments for the presence of viruses. Pulsant 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/
Re: [c-nsp] Question for LACP/LAG gurus
Im in the same situation as below, trying to get a LACP working between Extreme and an ASR 9k. Does anyone have a workaround for this rather than resetting the system id of the Extreme kit? Nick From: Dmitry Kiselev dmitry at dmitry.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp To: cisco-nsp at puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp Date: Tue, 12 Apr 2011 14:49:24 +0300 Subject: [c-nsp] Question for LACP/LAG gurus Hello! While building several new LAGs on IOS XR I found strange behaviour of Cisco IOSes for system priority LACP parameter. Most of classic IOSes allow to set value from 0 to 65535, but IOS XR does not: 12.2(55)SE2 Switch(config)#lacp system-priority ? 0-65535 Priority value 12.2(54)SG Switch(config)#lacp system-priority ? 0-65535 Priority value 12.2(33)SRE Router(config)#lacp system-priority ? 0-65535 Priority value IOS XE 12.2(33)XNF2 Router(config)#lacp system-priority ? 0-65535 Priority value IOS XR 4.0.1 Router(config)#lacp system priority ? 1-65535 Priority for this system. Lower value is higher priority. Moreover, IOS XR does not form the LAG if received partner system priority is zero. In this case each bundle port shows the error message Partner System ID/Key do not match that of the Selected links and remain configured state. It would remain a theoretical nuance, but Extreme Networks switches advertise priority=0 by default on all LAGs cousing some troubles in setup. Interesting fact thats in the same time zero is invalid value in Extreme switch configuration :) :) Extreme# configure sharing 7 lacp system-priority ? system_priority System Priority (1..65535) I take a short look inside IEEE 802.1AX-2008 standart and IEEE 802.3-2005 clause 43 and does not see any special case for priority=0. Does anybody in the list familar enough with LACP to explain me why Cisco IOS XR does not like zero here? Thanks -- Dmitry Kiselev Nick Ryce Senior Network Engineer Pulsant Limited T: 0845 119 9900 DDI: +44 131 5144049 W: www.pulsant.co.ukhttps://nbg01-exch-01.lumison.net/owa/redir.aspx?C=3d7cd71066064370b0210c73169f0074URL=http%3a%2f%2fwww.pulsant.co.uk -- 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 Pulsant. Finally, the recipient should check this email and any attachments for the presence of viruses. Pulsant 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/
Re: [c-nsp] VASI interfaces on IOS XR
Completely agree. Thanks for the insight. Nick On 22 Feb 2012, at 08:22, Bruce Pinsky b...@whack.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Ryce wrote: Hi Bruce, I was hoping to have an easy way out from import / export :-) In the VASI scenarios I've seen, BGP is used to send routes learned from the MP-BGP sessions to the the PE-CE BGP sessions and vice versa. So, in essence, you have three different BGP domains, the PE-CE, the MP-BGP, and the inter-VASI. In effect, you have two different redistributions going on. This is the result of having the VASI interfaces shimmed between the real interfaces facing the CE and the P/PE MPLS core. Since you don't need the VASI construct as you are not trying to apply services to a label switched interface, I don't think you need the complexity of what VASI introduces. If you simply need to get routes from one VRF to another, I think that you should be able to do something like this: router ospf 1 redistribute ospf 2 vrf bar router ospf 2 redistribute ospf 1 vrf foo I know that VRF aware redistribution is available in IOS, but not sure about XR (didn't spend a lot of time hunting through the docs). To me the downside of redistribution is that you end up with external routes but perhaps that's not an issue in your environment. Import/Export may seem like a pain, but I don't think anymore so than mutual redistribution and the access-lists and/or tags to prevent loops. I suppose you could get fancy and use BGP between VASI interfaces and redistribute your OSPF into BGP to get it across. But I think it violates the KISS and 2am principles unnecessarily. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9EpZcACgkQE1XcgMgrtya2pgCfc5fHnvtYSj2HPhORDoAu9poi 6hgAoNg+9LTpLsVo0Kv6pkoZ7JTr6WBx =xQXV -END PGP SIGNATURE- -- 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/
[c-nsp] VASI interfaces on IOS XR
Hi Guys, Does anyone know if these type of interfaces can be used without a services blade? Also is there a specific version of XR required? I have been scouring documentation and can't really find anything. Would InterFlex interfaces do the same thing? I am looking to have 1 link in a VRF and the other in a separate VRF. Then create ospf adjacencies do redistribute routes between the 2 VRF tables. Any thoughts? 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/
Re: [c-nsp] VASI interfaces on IOS XR
Hi Bruce, I was hoping to have an easy way out from import / export :-) Nick On 22 Feb 2012, at 00:21, Bruce Pinsky b...@whack.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Ryce wrote: Hi Guys, Does anyone know if these type of interfaces can be used without a services blade? Also is there a specific version of XR required? I have been scouring documentation and can't really find anything. Would InterFlex interfaces do the same thing? I am looking to have 1 link in a VRF and the other in a separate VRF. Then create ospf adjacencies do redistribute routes between the 2 VRF tables. Any thoughts? Are the routes from those different interfaces learned from other OSPF adjacencies? Seems like you should just be able to import the routes from the other VRF via an import statement? Am I missing what you are trying to do? VASI interfaces are really designed to allow for services to be applied prior to label imposition on packets that would be label forwarded toward the core. The VASI-left interface serves as a pseudo-CE and the VASI-right serves as a pseudo-PE. If the routes you are learning and needing to be readvertised are coming and going from untagged interfaces, I don't think VASI is what you need. - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9EM0MACgkQE1XcgMgrtybl5gCeMHq2qYSblgbNX+9xR79pJ22t t+0AoKau5fgjS//erKDT5ScwLT9B3TWp =hgr4 -END PGP SIGNATURE- -- 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/
Re: [c-nsp] Flow tools
Can nfdump/nfsen show useage per AS number as I cannot see anything on their site? Nick -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Dobbins, Roland Sent: 18 January 2012 06:14 To: Cisco NSP Subject: Re: [c-nsp] Flow tools On Jan 17, 2012, at 11:23 PM, John Brown wrote: 6506-E Sup720-3BXL. The NetFlow you get from this box won't be operationally useful - many caveats. Strongly suggest a move to Sup2T and DFC4 (where applicable), if you want good NetFlow from 6500s. nfdump/nfsen is a good open-source set of tools to use in getting started with flow telemetry, IMHO. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- 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/
Re: [c-nsp] 6148 L2 local switching?
Hi MKS, I believe that card only has a 1G fabric shared between 8 ports each. Therefor I don't believe you could do 2 simultaneous gig streams as you have suggested. I may be wrong though ;) Nick -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of MKS Sent: 12 January 2012 11:40 To: cisco-nsp Subject: [c-nsp] 6148 L2 local switching? A popular topic, I know, but I have a question that I can't find an answer to in previous discussions. In a given port-group, let's say 1-8, and all the ports are switchports in the same vlan. can port 1- port2 reach a gig throughput at the same time as port 3-port4. In other words, this this card capable of L2 local switching? or does every packet go to the sup and back? Regards MKS ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ -- 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/
Re: [c-nsp] IOS XR BGP
Hi Oli, That's sounds fantastic. I will give that a go and report back. Nick -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: 24 November 2011 16:04 To: Nick Ryce; Eric Morin; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] IOS XR BGP I require the specific to be from IGP. I have a funny feeling all I need to do is redistribute OSPF into BGP then use the aggregate-address as-set summary-only yes, and it looks you can limit the OSPF redistribution to a few (a single?) more specific as you are only interested in the core reachability? Just need confirmation if there is any other way. not to simulate your current solution in XR. But have you thought about orignating the aggregates you advertise to the Internet (and customers) via some central routers in your core, for example some RRs, instead of on the edge(s)? This way you will never advertise them in case your edge devices become isolated (which, if I read you correctly, is the purpose of this exercise?). If you chose this approach, you might also want to advertise these aggregates with a special next-hop (like a private 10.1.1.1), and add a static null0 to 10.1.1.1/32 on all your BGP routers. Then every router seeing the aggregate will automatically create a Null0 and will drop all packets to unallocated address space within these aggregates as soon as it enters your network? oli -- 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/
Re: [c-nsp] IOS XR BGP
Hi Vinny, aggregate-address only aggregates routes already in BGP and not from IGP. I was looking for a way to do this ala Junos that doesn't require me to redistribute OSPF routes to BGP. Nick -Original Message- From: Vinny Abello [mailto:vi...@abellohome.net] Sent: 24 November 2011 19:17 To: Oliver Boehmer (oboehmer) Cc: Nick Ryce; Eric Morin; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IOS XR BGP On 11/24/2011 11:04 AM, Oliver Boehmer (oboehmer) wrote: I require the specific to be from IGP. I have a funny feeling all I need to do is redistribute OSPF into BGP then use the aggregate-address as-set summary-only yes, and it looks you can limit the OSPF redistribution to a few (a single?) more specific as you are only interested in the core reachability? Just need confirmation if there is any other way. not to simulate your current solution in XR. But have you thought about orignating the aggregates you advertise to the Internet (and customers) via some central routers in your core, for example some RRs, instead of on the edge(s)? This way you will never advertise them in case your edge devices become isolated (which, if I read you correctly, is the purpose of this exercise?). If you chose this approach, you might also want to advertise these aggregates with a special next-hop (like a private 10.1.1.1), and add a static null0 to 10.1.1.1/32 on all your BGP routers. Then every router seeing the aggregate will automatically create a Null0 and will drop all packets to unallocated address space within these aggregates as soon as it enters your network? I have to agree with Oli here. I've followed this practice originating aggregate routes from extremely well connected core routers at multiple points in my networks. To the best of my memory, I never used network statements at the border or edge. Once or twice when building out to a new geographical area before having all of the redundancy in place, this practice has saved us when a single failed backbone link isolates the new routers in question. They stop announcing anything to their peers and we stop seeing any announcements from them obviously when their iBGP sessions drop with the rest of the network. To me this always seemed like the most simple and effective approach. Is there a reason this would not work in this situation or is there a reason using the aggregate-address commands provides some other benefit I'm missing? -Vinny -- 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/
[c-nsp] IOS XR BGP
Hi, I am moving from Juniper to Cisco ( IOS XR ) and am looking to emulate a certain feature ( aggregate addressing for BGP ) In Junos I can set routing-options aggregate route x.x.x.x/19 . If there is a less specific contributing route from IGP then the aggregate is announced through BGP. In BGP on IOS XR you use the network statement network x.x.x.x/19 now you need to have an exact route for this ( normally setting a static route ). This will not suit my requirements as if we lose IGP on that router I would like to stop announcing the ranges via BGP but the static route will still be there and I will theoretically blackhole traffic. Any ideas how to allow BGP to announce an aggregate route when there is less specific in IGP would be a great help. 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/
Re: [c-nsp] IOS XR BGP
Hi Adam,
That's great thanks.
I had just focused on the summary only part which only summarise less specific
BGP routes.
Nick
-Original Message-
From: Vitkovsky, Adam [mailto:avitkov...@emea.att.com]
Sent: 24 November 2011 12:20
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: RE: IOS XR BGP
Same as in Jonos use the aggregate cmd:
2.router bgp as-number
3.address-family { ipv4 | ipv6 } unicast
4.aggregate-address address/mask-length [ as-set ] [ as-confed-set ] [
summary-only ] [ route-policy route-policy-name ]
The as-set keyword generates autonomous system set path information and
community information from contributing paths.
The as-confed-set keyword generates autonomous system confederation set path
information from contributing paths.
The summary-only keyword filters all more specific routes from updates.
The route-policy route-policy-name keyword and argument specify the route
policy used to set the attributes of the aggregate route.
adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Thursday, November 24, 2011 11:49 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] IOS XR BGP
Hi,
I am moving from Juniper to Cisco ( IOS XR ) and am looking to emulate a
certain feature ( aggregate addressing for BGP )
In Junos I can set routing-options aggregate route x.x.x.x/19 . If there is a
less specific contributing route from IGP then the aggregate is announced
through BGP.
In BGP on IOS XR you use the network statement network x.x.x.x/19 now you need
to have an exact route for this ( normally setting a static route ). This will
not suit my requirements as if we lose IGP on that router I would like to stop
announcing the ranges via BGP but the static route will still be there and I
will theoretically blackhole traffic.
Any ideas how to allow BGP to announce an aggregate route when there is less
specific in IGP would be a great help.
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/
--
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/
Re: [c-nsp] IOS XR BGP
Still can't get this to work.
I have the network statement and a corresponding aggregate address statement
with as-set appended.
Any other thoughts?
Nick
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: 24 November 2011 12:54
To: Vitkovsky, Adam; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IOS XR BGP
Hi Adam,
That's great thanks.
I had just focused on the summary only part which only summarise less specific
BGP routes.
Nick
-Original Message-
From: Vitkovsky, Adam [mailto:avitkov...@emea.att.com]
Sent: 24 November 2011 12:20
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: RE: IOS XR BGP
Same as in Jonos use the aggregate cmd:
2.router bgp as-number
3.address-family { ipv4 | ipv6 } unicast
4.aggregate-address address/mask-length [ as-set ] [ as-confed-set ] [
summary-only ] [ route-policy route-policy-name ]
The as-set keyword generates autonomous system set path information and
community information from contributing paths.
The as-confed-set keyword generates autonomous system confederation set path
information from contributing paths.
The summary-only keyword filters all more specific routes from updates.
The route-policy route-policy-name keyword and argument specify the route
policy used to set the attributes of the aggregate route.
adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Thursday, November 24, 2011 11:49 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] IOS XR BGP
Hi,
I am moving from Juniper to Cisco ( IOS XR ) and am looking to emulate a
certain feature ( aggregate addressing for BGP )
In Junos I can set routing-options aggregate route x.x.x.x/19 . If there is a
less specific contributing route from IGP then the aggregate is announced
through BGP.
In BGP on IOS XR you use the network statement network x.x.x.x/19 now you need
to have an exact route for this ( normally setting a static route ). This will
not suit my requirements as if we lose IGP on that router I would like to stop
announcing the ranges via BGP but the static route will still be there and I
will theoretically blackhole traffic.
Any ideas how to allow BGP to announce an aggregate route when there is less
specific in IGP would be a great help.
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/
--
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/
--
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
Re: [c-nsp] IOS XR BGP
No, I am not introducing IGP into BGP.
All I want to do is that if IGP is lost then the subsequent aggregate routes in
BGP are withdrawn, if that makes sense.
Nick
-Original Message-
From: Vitkovsky, Adam [mailto:avitkov...@emea.att.com]
Sent: 24 November 2011 14:35
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: RE: IOS XR BGP
I see so you are introducing the more specifics from igp into bgp with the
network commands on the same router where you'd like to aggregate right?
Do you see the more specifics within the aggregate range in the particular BGP
AF table?
adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Thursday, November 24, 2011 2:56 PM
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IOS XR BGP
Still can't get this to work.
I have the network statement and a corresponding aggregate address statement
with as-set appended.
Any other thoughts?
Nick
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: 24 November 2011 12:54
To: Vitkovsky, Adam; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IOS XR BGP
Hi Adam,
That's great thanks.
I had just focused on the summary only part which only summarise less specific
BGP routes.
Nick
-Original Message-
From: Vitkovsky, Adam [mailto:avitkov...@emea.att.com]
Sent: 24 November 2011 12:20
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: RE: IOS XR BGP
Same as in Jonos use the aggregate cmd:
2.router bgp as-number
3.address-family { ipv4 | ipv6 } unicast
4.aggregate-address address/mask-length [ as-set ] [ as-confed-set ] [
summary-only ] [ route-policy route-policy-name ]
The as-set keyword generates autonomous system set path information and
community information from contributing paths.
The as-confed-set keyword generates autonomous system confederation set path
information from contributing paths.
The summary-only keyword filters all more specific routes from updates.
The route-policy route-policy-name keyword and argument specify the route
policy used to set the attributes of the aggregate route.
adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Thursday, November 24, 2011 11:49 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] IOS XR BGP
Hi,
I am moving from Juniper to Cisco ( IOS XR ) and am looking to emulate a
certain feature ( aggregate addressing for BGP )
In Junos I can set routing-options aggregate route x.x.x.x/19 . If there is a
less specific contributing route from IGP then the aggregate is announced
through BGP.
In BGP on IOS XR you use the network statement network x.x.x.x/19 now you need
to have an exact route for this ( normally setting a static route ). This will
not suit my requirements as if we lose IGP on that router I would like to stop
announcing the ranges via BGP but the static route will still be there and I
will theoretically blackhole traffic.
Any ideas how to allow BGP to announce an aggregate route when there is less
specific in IGP would be a great help.
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/
--
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
Re: [c-nsp] IOS XR BGP
Hi Eric,
I require the specific to be from IGP.
I have a funny feeling all I need to do is redistribute OSPF into BGP then use
the aggregate-address as-set summary-only
Just need confirmation if there is any other way.
Nick
-Original Message-
From: Eric Morin [mailto:eric.mo...@corp.xplornet.com]
Sent: 24 November 2011 14:24
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: RE: [c-nsp] IOS XR BGP
I don't know how the as-set piece works, but you need a 'specific' in your BGP
table in order to trigger the aggregate that encompasses that specific. You
don't need a network statement (unless it is for a more specific prefix that is
being added into BGP in this device as well, which would also require an exact
match route).
The one thing to note is with eBGP on XR you need an out policy applied to the
neighbor (prefix list, route map ect), by default all prefixes are dropped to
ebgp neighbours (ibgp works the same as non-XR where it sends everything by
default).
Hope this helps
Eric
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Thursday, November 24, 2011 9:56 AM
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IOS XR BGP
Still can't get this to work.
I have the network statement and a corresponding aggregate address statement
with as-set appended.
Any other thoughts?
Nick
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: 24 November 2011 12:54
To: Vitkovsky, Adam; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] IOS XR BGP
Hi Adam,
That's great thanks.
I had just focused on the summary only part which only summarise less specific
BGP routes.
Nick
-Original Message-
From: Vitkovsky, Adam [mailto:avitkov...@emea.att.com]
Sent: 24 November 2011 12:20
To: Nick Ryce; cisco-nsp@puck.nether.net
Subject: RE: IOS XR BGP
Same as in Jonos use the aggregate cmd:
2.router bgp as-number
3.address-family { ipv4 | ipv6 } unicast
4.aggregate-address address/mask-length [ as-set ] [ as-confed-set
] [ summary-only ] [ route-policy route-policy-name ]
The as-set keyword generates autonomous system set path information and
community information from contributing paths.
The as-confed-set keyword generates autonomous system confederation set path
information from contributing paths.
The summary-only keyword filters all more specific routes from updates.
The route-policy route-policy-name keyword and argument specify the route
policy used to set the attributes of the aggregate route.
adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce
Sent: Thursday, November 24, 2011 11:49 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] IOS XR BGP
Hi,
I am moving from Juniper to Cisco ( IOS XR ) and am looking to emulate a
certain feature ( aggregate addressing for BGP )
In Junos I can set routing-options aggregate route x.x.x.x/19 . If there is a
less specific contributing route from IGP then the aggregate is announced
through BGP.
In BGP on IOS XR you use the network statement network x.x.x.x/19 now you need
to have an exact route for this ( normally setting a static route ). This will
not suit my requirements as if we lose IGP on that router I would like to stop
announcing the ranges via BGP but the static route will still be there and I
will theoretically blackhole traffic.
Any ideas how to allow BGP to announce an aggregate route when there is less
specific in IGP would be a great help.
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/
--
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
Re: [c-nsp] IOS XR BGP
Hi Nick, I understand this but there is sometimes hundreds of more specifics in IGP so there would not really be any flapping as such unless some core links horrifically died. So would redist ospf into BGP then use aggregate address work then? Nick -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: 24 November 2011 15:22 To: Nick Ryce Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IOS XR BGP On 24/11/2011 14:38, Nick Ryce wrote: All I want to do is that if IGP is lost then the subsequent aggregate routes in BGP are withdrawn, if that makes sense. You mean, you want the whole world to know every time you have an igp flap? :-D This is not really considered to be good engineering practice. Lots of reasons why, but for a good starting point, google for: bgp synchronization +site:nanog.org 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/
[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/
Re: [c-nsp] IOS XR RPL
Thanks guys -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: 22 September 2011 12:18 To: Nick Ryce; cisco-nsp@puck.nether.net Subject: 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/ -- 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/
Re: [c-nsp] IOS XR RPL
Just found prepend as-path most-recent. I assume this is the one I need? Nick -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Ryce Sent: 22 September 2011 11: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/ -- 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/
Re: [c-nsp] Another unsupported-transceiver issue
Hi Tim, Thanks for this. I'm getting in touch with our optic supplier to see if they have had any other reports of this. Its a chan35 optic to plug into some DWDM kit. Pity Cisco seem to have omitted this channel from their optic range or we would have used them. Nick -- Nick Ryce Network Engineer Lumison t: 0845 1199 900 d: +44 131 514 4049 P.S. Fancy some light reading? Clouds to networks, download a Lumison whitepaper now athttp://www.lumison.net/why-lumison/whitepapers On 04/09/2011 12:24, tim t...@haitabu.net wrote: Nick, On 02.09.2011 4:47 PM, Nick Ryce wrote: State: Administrative state: enabled Operational state: Down (Reason: Security failure (not a valid part)) LED state: Yellow On Is there another hidden command I need to set to get the XFP to work? I am not an optical or XFP expert, but we had the same issue with some second source optics and the ASR 9000 series. The ASR 9000 line-cards seem to be more aggressive in the time-slot between giving power to the XFP and wanting to fetch the data from the XFP eeeprom (i.e., the XFP has not so much time to boot/get warm and deliver the eeeprom data to the line-card). One can test this by resetting the line-card with the XFP inserted. If the XFP comes up properly it is (it could be) this issue. We have no (realistic) work-around for this second source optics, but discussed this with the XFP vendors and they modified/upgraded the XFPs and now they work with the ASR 9000 series routers. BTW: Until now we had no example were we needed the global service unsupported-transceiver statement. We do use the transceiver permit pid all statement in interface configuration mode for some SFPs. Hth, tim -- 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/
[c-nsp] Another unsupported-transceiver issue
Hi All, We have an ASR9006 with some opnext 10Gig optics. I have set the service unsupported-transceiver option and also set transceiver permit pid all on the interface. The interface does not come up and when issuing a show controllers ten0/0/0/1 I see the following:- State: Administrative state: enabled Operational state: Down (Reason: Security failure (not a valid part)) LED state: Yellow On Is there another hidden command I need to set to get the XFP to work? 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/
[c-nsp] IOS XR SSH
Hi, Do you need the k9 version of IOS XR in order to set up the ssh server for secure connections into it? I cant see any command references to enable the ssh server in the basic 4.1.0 version. Any help much appreciated. 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/
Re: [c-nsp] IOS XR SSH
It makes me die inside that a router of the asr calibre cant have management access encrypted with ssh without a different software version :( Nick -Original Message- From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com] Sent: 26 August 2011 12:51 To: Nick Ryce; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] IOS XR SSH Do you need the k9 version of IOS XR in order to set up the ssh server for secure connections into it? I cant see any command references to enable the ssh server in the basic 4.1.0 version. yes, you need the crypto image (k9), the command you're looking for is ssh server [v2] to enable a ssh server (default is off/no server listening to tcp/22).. oli -- 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/
[c-nsp] Graph cisco 4948 SVI
Hi, Does anyone know if the 4948 has the ability to be able to graph traffic transiting the SVI of a vlan? I know the 3550/3560's are unable to do this? 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/
[c-nsp] Multi Area OSPF
Hi Guys, Im having some issues with setting up multi area ospf between a j 2320 and a cisco 1812. I have a funny feeling the issues will be user related. The j2320 is acting as an abr with backbone area 0.0.0.0 and stub area 0.0.0.1 and advertises a default route into the stub area. The 1812 is set as a stub with no other routing protocols being used. When I use the redistribute static or redistribute connected commands it advises these cant be used as the router is an asbr. The router is only running 1 ospf process for the stub area so I am not sure why this is occurring. I add the network x.x.x.x y.y.y.y area 0.0.0.1 command and can start seeing a default route being sent by the juniper which is great but the juniper cannot see anything being sent from the router. I can get around this by setting the network in the ospf process to 0.0.0.0 255.255.255.255 but is this the correct way to do this as it would mean that any interface on the router will be sending out ospf requests which I do not want to occur as I want to be specific. Any ideas? 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/
[c-nsp] DHCP Option 66 String
Hi Guys, I have been hunting around trying to find if when using cisco dhcp and option 66 I can use a http url rather than tftp? Within most linux dhcp daemons this can be done. Any help greatly appreciated. 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 and nPlusOne. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison and nPlusOne 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/
