Re: [c-nsp] tftp woes
On Sun, 2011-07-24 at 21:43 -0500, Dan Letkeman wrote: After about 12-15 machines start the image transfer the server gets over utilized and the tftp download from the server starts to take a lot longer on the rest of the machines that need to download the imaging software, not the image itself. Is there a simple way on these switches to prioritize the tftp traffic over the actual image transfer? Possibly some simple QOS commands? tftp is UDP-based, have you checked the whole network to make sure you don't have a duff link producing errors and dropping UDP packets? Are you suffering over-utilization at any point? Is the initial software download happening in a machine's PXE environment? If so, the timeout for tftp packets may be a lot larger than you expect, hence a single packet being dropped equates a much larger impact. Have you looked at a multicast-based solution for imaging the machines? Peter -- Peter Hicks peter.hi...@poggs.co.uk ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EIGRP HSRP Successors
Hi, On Sun, Jul 24, 2011 at 04:06:03PM -0500, Dan Letkeman wrote: I'm working on a test configuration for hsrp between two switches where i'm running eigrp, and I'm wondering if its best practice to leave the added successors in the route list? We usually run HSRP/VRRP on customer-facing interfaces, and consequently, running EIGRP there is a complete no-go for us. No benefit, and interesting attack vectors... So we run all interfaces with passive-interface default, and selectively enable EIGRP on backbone interfaces (which do not have HSRP/VRRP anyway). For different topologies, of course YMMV. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpLmIK8j8dfx.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] memory leaking in IOS 12.2(58)SE1 on 2960's
Hi Adnras, Dne 20.7.2011 21:35, Tóth András napsal(a): Hi Jiri, When you mention logs are useless, do you mean you did not find anything in the logs after logging on to the switch which freed up some memory? Yup, there were no signs of anything unusual in the log. logging severity is set to notifications. Any chance to collect the following command from the switch which freed up some memory during the night? sh mem allocating-process totals DC.Cisco.138#sh mem allocating-process totals Total(b)Used(b) Free(b) Lowest(b) Largest(b) Processor 21585348195477682037580 133081 1374036 PC Total Count Name 0x015D73F4 2202188 277 Process Stack 0x0032C018 1213820 1050 *Packet Header* 0x005B1364 743256 74 Flashfs Sector 0x00F81528 712840 8Init 0x00E7B38C 523328 85 Init 0x01546F8C 496176 36 TW Buckets 0x0048A008 439340 1Init 0x01443754 393480 6STP Port Control Block Chunk 0x01011B34 292956 3149 IPC Zone 0x0032F68C 262720 6pak subblock chunk 0x00A6BA2C 262232 2CEF: hash table 0x00489FD8 256300 1Init 0x0079E27C 250672 2PM port_data 0x0158BD78 207900 275 Process 0x00339870 203148 57 *Hardware IDB* 0x01011BDC 196740 3IPC Message Hea 0x0016CDD0 196740 3Mat Addr Tbl Ch 0x004EE5A8 196652 1HRM: destination array 0x015F68A8 191876 3EEM ED ND 0x00E5C79C 184320 2event_trace_tbs 0x0032C06C 164640 4*Packet Data* 0x00809DC8 163884 1Init 0x00949AF4 145484 399 MLDSN L2MCM 0x004F6FA8 135652 29 HULC_MAD_SD_MGR 0x01030A50 133468 383 Virtual Exec 0x013F2930 132728 7VLAN Manager 0xE8BC 132132 11 DTP Protocol 0x00AD52E0 131976 4VRFS: MTRIE n08 0x00336804 131116 1*Init* 0x014271B0 130376 12 SNMP SMALL CHUN 0x007910A8 129948 51 PM port sub-block 0x016F4304 125244 1820 Init 0x009561E4 110676 399 MLDSN L2MCM 0x0048A020 109868 1Init Unfortunately I'm not familiar with usual values these processes should allocate. This might sound stupid but can you confirm by looking at the uptime that the switch did not crash? If it did, please collect the crashinfo files and send them so I can take a look. The switch did not crash, it's uptime is over 6 weeks now. While monitoring the memory usage, if you see regular increase, collect the following commands several times so you can compare them later to see which process allocates most memory. sh proc mem sorted sh mem allocating-process totals Memory graphing is being implemented now. As soon as I have relevant graphs, I will gather info given by these commands. Thank you, Jiri Best regards, Andras On Wed, Jul 20, 2011 at 1:22 PM, Jiri Prochazka jiri.procha...@superhosting.cz wrote: Hi Andras, All I was able to get from the switch was '%% Low on memory; try again later', so I had no chance to get any usefull info. None of them really crashed, even now (a few days after the issue raised) all are forwarding everything without any interruption. The only (doh) problem is that they are refusing any remote/local management. We have aproximately 40 2960's in our network, all were upgraded to 12.2(58)SE1 at the same night 42 days ago. Till this day four of them have shown this error (first one a week ago, the rest during the last 7 days). I will definitely implement graphing of memory usage and monitor this. Logs are useless, as there is absolutely none info regarding to this behaviour. update: Wow, one of 'crashed' switches surprisingly managed to free some memory over the night and there is no problem with remote login now! DC.Cisco.138#show mem HeadTotal(b) Used(b) Free(b) Lowest(b) Largest(b) Processor27A819C2158534819502124 2083224 1330816 1396804 I/O2C0 4194304 2385892 1808412 1647292 1803000 Driver te1A0 1048576 44 1048532 1048532 1048532 DC.Cisco.138#show proc mem sorted Processor Pool Total: 21585348 Used: 19506548 Free:2078800 I/O Pool Total:4194304 Used:2385788 Free:1808516 Driver te Pool Total:1048576 Used: 40 Free:1048536 PID TTY Allocated FreedHoldingGetbufsRetbufs Process 0 0 209660643684020 13930872 0 0 *Init* 0 0 349880992 30354565617584884520010 421352 *Dead* 0 0 0 0 722384 0 0 *MallocLite* 67 0 531728 17248 463548 0 0 Stack Mgr Notifi 81 0 488448232 332392 0
[c-nsp] recomended 12 dot IOS for 7206/G2
Hi All, I was just wondering what the consensus recommended 12 dot something IOS is for L2TP/MPLS (L3VPN) use these days. No ATM, no fancy voice stuff, nothing NAT and barely any ACLs. -- two eyes to tease, an aargh ... an oh there's a pie in there somewhere ___ cisco-nsp 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] recomended 12 dot IOS for 7206/G2
Hi, On Tue, Jul 26, 2011 at 01:42:39AM +1000, Phil Pierotti wrote: I was just wondering what the consensus recommended 12 dot something IOS is for L2TP/MPLS (L3VPN) use these days. No ATM, no fancy voice stuff, nothing NAT and barely any ACLs. I'd go with 12.4 main or 15.0 main. 12-with-letters for 7200 seems to cause pain (these days). But some folks are using 12.2SRE* and can still talk, so maybe things have improved. (Not that all of this wouldn't be in the mailing list archives). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp9ATScxbXVR.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] recomended 12 dot IOS for 7206/G2
Hi Most of our 7206/G2 are running 12.4-24.T1 System restarted at 02:42:05 UTC Tue Jul 28 2009 System image file is disk2:c7200p-spservicesk9-mz.124-24.T1.bin Some has also been upgraded to 15.0-1.M5 using advipservice (for OSPFv3 support) System restarted at 12:03:27 cet Tue Jun 14 2011 System image file is disk2:c7200p-advipservicesk9-mz.150-1.M5.bin MPLS, L3VPN, EoMPLS, L2TPv2(PPPoE) Never any problems with these routers using above IOS Jon Den 7/25/2011 5:56 PM, skrev Gert Doering: Hi, On Tue, Jul 26, 2011 at 01:42:39AM +1000, Phil Pierotti wrote: I was just wondering what the consensus recommended 12 dot something IOS is for L2TP/MPLS (L3VPN) use these days. No ATM, no fancy voice stuff, nothing NAT and barely any ACLs. I'd go with 12.4 main or 15.0 main. 12-with-letters for 7200 seems to cause pain (these days). But some folks are using 12.2SRE* and can still talk, so maybe things have improved. (Not that all of this wouldn't be in the mailing list archives). gert ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] tftp woes
Thanks guys, I will do some packet captures and see what it shows me. I think the server might be over utilized as well, because if we are imaging off of one server and then we tftp off of another, things are faster. So that to me says that its a server problem and not a network problem. Yes we multicast as well, but sometimes the guys who do the imaging want to unicast instead for what ever reason. Dan. On Mon, Jul 25, 2011 at 2:25 AM, Peter Hicks peter.hi...@poggs.co.uk wrote: On Sun, 2011-07-24 at 21:43 -0500, Dan Letkeman wrote: After about 12-15 machines start the image transfer the server gets over utilized and the tftp download from the server starts to take a lot longer on the rest of the machines that need to download the imaging software, not the image itself. Is there a simple way on these switches to prioritize the tftp traffic over the actual image transfer? Possibly some simple QOS commands? tftp is UDP-based, have you checked the whole network to make sure you don't have a duff link producing errors and dropping UDP packets? Are you suffering over-utilization at any point? Is the initial software download happening in a machine's PXE environment? If so, the timeout for tftp packets may be a lot larger than you expect, hence a single packet being dropped equates a much larger impact. Have you looked at a multicast-based solution for imaging the machines? Peter -- Peter Hicks peter.hi...@poggs.co.uk ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] recomended 12 dot IOS for 7206/G2
My only comment here is that 12.4T became 15.0M. Also they aren't really doing anything else for 12.4 mainline so you are probably better off with 15.0M or 12.4.T code anyhow. 12.2SR (latest) is also pretty solid code. 15M is geared more towards your general purpose deployments, while SR code is based on the 7600's code train and geared more toward the service provider space. Generally my experience has been to run 15M latest unless you have a reason not to. There is always the risk of regressions (bugs caused by fixing other bugs), but generally the later the rebuild (the last number) the more stable the release. -Pete On Mon, Jul 25, 2011 at 11:56 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Tue, Jul 26, 2011 at 01:42:39AM +1000, Phil Pierotti wrote: I was just wondering what the consensus recommended 12 dot something IOS is for L2TP/MPLS (L3VPN) use these days. No ATM, no fancy voice stuff, nothing NAT and barely any ACLs. I'd go with 12.4 main or 15.0 main. 12-with-letters for 7200 seems to cause pain (these days). But some folks are using 12.2SRE* and can still talk, so maybe things have improved. (Not that all of this wouldn't be in the mailing list archives). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp 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] Common uRPF setting on all interfaces
Hello list, We recently did a forklift upgrade of a 6509 from a SUP2 unit to a SUP720-3B box. At the same time I also plunked over a few VRFs which had been living on an external router due to lack of VRF support on the SUP2s. To my surprise one of the moved customers reported lack of Internet connectivity (VPN was fine - they collocate a firewall) at sites hanging off of the upgraded box. I determined that, though I thought I copied everything properly, an SVI's uRPF got messed up and was dropping packets from the Internet. In troubleshooting I added allow-default to the ip verify ... line on the SVI and it worked. Being connected to an internal VLAN that peers with other switches in that VPN (we're not MPLS yet) where all other ingress traffic is filtered I figured it was a redundant step so removed the line completely. Well, this afternoon I saw RANCID email me a list of changes from that box. Every single SVI that used to have some incantation of uRPF now have ip verify unicast source reachable-via rx allow-default allow-self-ping on them. Explains how the allow-default got removed in the first place; the next SVI I pasted in doesn't have that bit. Has anyone seen this before? I did a couple of quick searches but my Google-fu is letting me down. Is there some secret that only one possible stanza for uRPF is allowed on this box, unless the line isn't present? Running 12.2(33)SXI4a on SUP720-3B in a 6509. Thanks Ross ___ cisco-nsp 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] Common uRPF setting on all interfaces
Hi Ross, This is a 'well-known' limitation of uRPF checking on sup720. It's documented here (3rd bullet): http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/secure.html#wp1099693 Hope that helps, Tim At 12:04 PM 7/25/2011, Ross Halliday commented: Hello list, We recently did a forklift upgrade of a 6509 from a SUP2 unit to a SUP720-3B box. At the same time I also plunked over a few VRFs which had been living on an external router due to lack of VRF support on the SUP2s. To my surprise one of the moved customers reported lack of Internet connectivity (VPN was fine - they collocate a firewall) at sites hanging off of the upgraded box. I determined that, though I thought I copied everything properly, an SVI's uRPF got messed up and was dropping packets from the Internet. In troubleshooting I added allow-default to the ip verify ... line on the SVI and it worked. Being connected to an internal VLAN that peers with other switches in that VPN (we're not MPLS yet) where all other ingress traffic is filtered I figured it was a redundant step so removed the line completely. Well, this afternoon I saw RANCID email me a list of changes from that box. Every single SVI that used to have some incantation of uRPF now have ip verify unicast source reachable-via rx allow-default allow-self-ping on them. Explains how the allow-default got removed in the first place; the next SVI I pasted in doesn't have that bit. Has anyone seen this before? I did a couple of quick searches but my Google-fu is letting me down. Is there some secret that only one possible stanza for uRPF is allowed on this box, unless the line isn't present? Running 12.2(33)SXI4a on SUP720-3B in a 6509. Thanks Ross ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Common uRPF setting on all interfaces
Correct. All uRPF has to be configured the same. http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SXF/configuration/guide /secure.pdf Page 4 - Note - The most recently configured mode is automatically applied to all ports configured for Unicast RPF check. -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Ross Halliday Sent: Monday, July 25, 2011 3:05 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Common uRPF setting on all interfaces Hello list, We recently did a forklift upgrade of a 6509 from a SUP2 unit to a SUP720-3B box. At the same time I also plunked over a few VRFs which had been living on an external router due to lack of VRF support on the SUP2s. To my surprise one of the moved customers reported lack of Internet connectivity (VPN was fine - they collocate a firewall) at sites hanging off of the upgraded box. I determined that, though I thought I copied everything properly, an SVI's uRPF got messed up and was dropping packets from the Internet. In troubleshooting I added allow-default to the ip verify ... line on the SVI and it worked. Being connected to an internal VLAN that peers with other switches in that VPN (we're not MPLS yet) where all other ingress traffic is filtered I figured it was a redundant step so removed the line completely. Well, this afternoon I saw RANCID email me a list of changes from that box. Every single SVI that used to have some incantation of uRPF now have ip verify unicast source reachable-via rx allow-default allow- self-ping on them. Explains how the allow-default got removed in the first place; the next SVI I pasted in doesn't have that bit. Has anyone seen this before? I did a couple of quick searches but my Google-fu is letting me down. Is there some secret that only one possible stanza for uRPF is allowed on this box, unless the line isn't present? Running 12.2(33)SXI4a on SUP720-3B in a 6509. Thanks Ross ___ cisco-nsp 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] tftp woes
Dan Letkeman danletke...@gmail.com wrote: I think the server might be over utilized as well, because if we are imaging off of one server and then we tftp off of another, things are faster. So that to me says that its a server problem and not a network problem. Yes we multicast as well, but sometimes the guys who do the imaging want to unicast instead for what ever reason. Our guys need the same (they rarely use the multicast functionality although they do still need it) as we unfortunately have to use FreeGhost, well I guess it's better than that 'other' ghosting tool. Anyway, I remember duct taping the problem by configuring SFQ on the Linux host in the egress direction to stop the unicast NFS flows saturating the link and preventing the TFTP flows from being starved. Not perfect, but it was good enough as a quick fix. Cheers -- Alexander Clouter .sigmonster says: Are you a turtle? ___ cisco-nsp 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] Common uRPF setting on all interfaces
Hi, On Mon, Jul 25, 2011 at 03:04:53PM -0400, Ross Halliday wrote: Has anyone seen this before? I did a couple of quick searches but my Google-fu is letting me down. Is there some secret that only one possible stanza for uRPF is allowed on this box, unless the line isn't present? Exactly this. The box can only do a single mode of uRPF on all interfaces that have uRPF active. Hardware limitation. (And no IPv6 uRPF in hardware at all) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpZ4tu20gp7n.pgp Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] MVPN Rosen interoperation configuration Cisco and Juniper
Can someone please share the working Rosen MVPN configuration of Cisco and Juniper? Do I have to use vrf-table-label or VT interface on Juniper router to make it working? -- David W. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] VRF-lite configuration - BGP and Local Routes
Hi Everyone, I am hoping that someone can give me some guidance with how to setup VRF-Lite and routing with BGP and intra-vrf routing. I have been playing with this for about a week now and figured out how to setup vrf-lite to a certain point. I know if I apply the ip vrf xx to an interface such as physical, loopback, or vlan I can pass traffic up or down it on the same vrf, including if I set the vrf on an interface going outbound to a BGP peering neighbor I can pull in their bgp announcements to that vrf, but what I am having problems with is can this be done via the Global BGP routing table? Or can I somehow do a Global Leak so that the VRF can communicate out of its area to the remote peer? I hope I am clear here, if not I will be happy to share my testing configuration. Basically we are wanting to separate 2 networks so that they have their own BGP Routing tables so they have different routes out but at the same time be able to communicate between all of the local networks the router has installed on it. Thanks Joe ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] just installed a Huawei...
Not sure if it's any interest of this group, but I just installed a Huawei CX600 router this last week. It's like Cisco quality (garbage!) for the price that Cisco should be (low!). The commands are very similar (e.g. switchport - portswitch, no shut - undo shut, etc), and you configure it almost identical to what you'd expect on a Cisco. The worst part about the Huawei is probably the documentation. It's scattered all over the place, so if you want something simple (like telnet access), it's in a completely different PDF than if you want, say, VLAN configuration commands. Finding it all is a huge scavenger hunt. But hey...for like a 1/4 of the price or whatever (so I've heard), I'd say it's worth it. :b -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubac...@gmail.com ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] WAAS Mobile client and IE7
Hey All, Bit of a long shot but is anyone running WAAS mobile client and having issues with IE7. I have had reports and now able to replicate issues where IE7 will open and crash the WAAS mobile client. Currently have a tac case open but just wanted to see if anyone has run into an issues like this and whether there is a quick fix (other than stop using IE7). WAAS mobile version 3.5.2 Cheers, Simon T. Save money and avoid queues – pre-purchase discounted Ekka tickets at your local RACQ store. Visit: racq.com/entertainment Please Note: If you are not the intended recipient, please delete this email as its use is prohibited. RACQ does not warrant or represent that this email is free from viruses or defects. If you do not wish to receive any further commercial electronic messages from RACQ please e-mail unsubscr...@racq.com.au or contact RACQ on 13 19 05. ___ cisco-nsp 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] VRF-lite configuration - BGP and Local Routes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joseph Hardeman wrote: Hi Everyone, I am hoping that someone can give me some guidance with how to setup VRF-Lite and routing with BGP and intra-vrf routing. I have been playing with this for about a week now and figured out how to setup vrf-lite to a certain point. I know if I apply the ip vrf xx to an interface such as physical, loopback, or vlan I can pass traffic up or down it on the same vrf, including if I set the vrf on an interface going outbound to a BGP peering neighbor I can pull in their bgp announcements to that vrf, but what I am having problems with is can this be done via the Global BGP routing table? Or can I somehow do a Global Leak so that the VRF can communicate out of its area to the remote peer? I hope I am clear here, if not I will be happy to share my testing configuration. Basically we are wanting to separate 2 networks so that they have their own BGP Routing tables so they have different routes out but at the same time be able to communicate between all of the local networks the router has installed on it. Leaking between VRFs is done via import/export statements indicating which route targets are put into the global VPNv4 table and which should be brought into a particular VRF. Leaking routes between into/out of the global routing table is typically accomplished via static routes. There are examples of both types of leaking here http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml - -- = bep -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4uUQUACgkQE1XcgMgrtya7WwCg/oSEzUQndQTjcBSb0mrijOEj MOoAni2RS1Xv0NdBG26Z3qMpLgiH+7Eu =IlzE -END PGP SIGNATURE- ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] just installed a Huawei...
but then you spend 4 x the time configuring and maintaining your network false economy? Andrew Jones -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rogelio Sent: Tuesday, 26 July 2011 2:51 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] just installed a Huawei... Not sure if it's any interest of this group, but I just installed a Huawei CX600 router this last week. It's like Cisco quality (garbage!) for the price that Cisco should be (low!). The commands are very similar (e.g. switchport - portswitch, no shut - undo shut, etc), and you configure it almost identical to what you'd expect on a Cisco. The worst part about the Huawei is probably the documentation. It's scattered all over the place, so if you want something simple (like telnet access), it's in a completely different PDF than if you want, say, VLAN configuration commands. Finding it all is a huge scavenger hunt. But hey...for like a 1/4 of the price or whatever (so I've heard), I'd say it's worth it. :b -- Also on LinkedIn? Feel free to connect if you too are an open networker: scubac...@gmail.com ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Alphawest Disclaimer If this communication is not intended for you and you are not an authorised recipient of this email you are prohibited by law from dealing with or relying on the email or any file attachments. This prohibition includes reading, printing, copying, re-transmitting, disseminating, storing or in any other way dealing or acting in reliance on the information. If you have received this email in error, we request you contact Alphawest immediately by returning the email to postmas...@alphawest.com.au and destroy the original. This email is confidential and may contain privileged client information. Alphawest has taken reasonable steps to ensure the accuracy and integrity of all its communications, including electronic communications, but accepts no liability for materials transmitted. Alphawest collects, uses and stores information regarding its customers from time to time in accordance with its privacy policy located on www.alphawest.com.au. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
