Fw: new message
Hey! New message, please read <http://widegrins.com/children.php?p2s> adam vitkovsky
RE: best practice for advertising peering fabric routes
> However, a good engineer would know there are drawbacks to next-hop-self, > in particular it slows convergence in a number of situations. > There are networks where fast convergence is more important than route > scaling, and thus the traditional design of BGP next-hops being edge interfaces, > and edge interfaces in the IGP performs better. Well it's not true anymore BGP PIC edge and core converges under 50ms. "fast external failover" and "local repair" where available long before -but yes that's applicable only for MPLS. adam -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Wednesday, January 15, 2014 3:18 PM To: Dobbins, Roland Cc: NANOG list Subject: Re: best practice for advertising peering fabric routes On Jan 15, 2014, at 12:02 AM, "Dobbins, Roland" wrote: > Again, folks, this isn't theoretical. When the particular attacks cited in this thread were taking place, I was astonished that the IXP infrastructure routes were even being advertised outside of the IXP network, because of these very issues. I know a lot of people push next-hop-self, and if you're a large ISP with thousands of BGP customers is pretty much required to scale. However, a good engineer would know there are drawbacks to next-hop-self, in particular it slows convergence in a number of situations. There are networks where fast convergence is more important than route scaling, and thus the traditional design of BGP next-hops being edge interfaces, and edge interfaces in the IGP performs better. By attempting to force IX participants to not put the route in IGP, those IX participants are collectively deciding on a slower converging network for everyone. I don't like a world where connecting to an exchange point forces a particular network design on participants. > IXPs are not the problem when it comes to breaking PMTU-D. The problem is largely with enterprise networks, and with 'security' vendors who've propagated the myth that simply blocking all ICMP somehow increases 'security'. That's some circular reasoning. Networks won't 9K peer at exchange points for a number of reasons, including PMTU-D discovery issues. Since there are virtual no 9K peering at exchange points, PMTU-D is a non-issue. Maybe if IXP design didn't break PMTU-D it would help attract more 9K peers, or there might even be a future where 9K peering was required? This whole problem smacks to me of exchange points that are "too big to fail". Since some of these exchanges are so big, everyone else must bend to their needs. I think the world would be a better place if some of these were broken up into smaller exchanges and they imposed less restrictions on their participants. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: best practice for advertising peering fabric routes
> But hey, I get why ISP's don't want to offer 9K MTU clean paths end to end. > Customers could then buy a VPN appliance and manage their own VPN's > with no vendor lock-in. MPLS VPN revenues would tumble, and customers > would move more fluidly between providers. That's terrible if you're an ISP. No it's exactly why some carriers do their best to provide 9K+ MTU to most of their POPs so that they can provide L2 services to ISPs and other carriers that require 9K MTU for their BB links to capitalize on these new emerging markets. Customers locked in to a single provider (MPLS VPN) can rely on certain class of service (predictable delay, jitter and packet loss) properties you can't get out of a pure internet connection from NY to Tokyo. adam -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Wednesday, January 15, 2014 4:31 PM To: Dobbins, Roland Cc: NANOG list Subject: Re: best practice for advertising peering fabric routes On Jan 15, 2014, at 8:49 AM, "Dobbins, Roland" wrote: > Not really. What I'm saying is that since PMTU-D is already broken on so many endpoint networks - i.e., where traffic originates and where it terminates - that any issues arising from PMTU-D irregularities in IXP networks are trivial by comparison. I think we're looking at two different aspects of the same issue. I believe you're coming at it from a 'for all users of the Internet, what's the chance they have connectivity that does not break PMTU-D.' That's an important group to study, particularly for those DSL users still left with < 1500 byte MTU's. And you're right, for those users IXP's are the least of their worries, mostly it's content-side poor networking, like load balancers and firewalls that don't work correctly. I am approaching it from a different perspective, 'where is PMTU-D broken for people who want to use 1500-9K frames end to end?' I'm the network guy who wants to buy transit in the US, and transit in Germany and run a tunnel of 1500 byte packets end to end, necessitating a ~1540 byte packet. Finding transit providers who will configure jumbo frames is trivial these days, and most backbones are jumbo frame clean (at least to 4470, but many to 9K). There's probably about a 25% chance private peelings are also jumbo clean. Pretty much the only thing broken for this use case is IXP's. Only a few have a second VLAN for 9K peerings, and most participants don't use it for a host of reasons, including PMTU-D problems. I'm an oddball. I think MPLS VPN's are a terrible idea for the consumer, locking them into a single provider in the vast majority of cases. Consumers would be better served by having a tunnel box (IPSec maybe?) at their edge and running there own tunnel over IP provider-independently, if they could get > 1500B MTU at the edge, and move those packets end to end. While I've always thought that, in the post-Snowden world I think I seem a little less crazy, rather than relying on your provider to keep your "VPN" traffic secret, customers should be encrypting it in a device they own. But hey, I get why ISP's don't want to offer 9K MTU clean paths end to end. Customers could then buy a VPN appliance and manage their own VPN's with no vendor lock-in. MPLS VPN revenues would tumble, and customers would move more fluidly between providers. That's terrible if you're an ISP. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: "Everyone should be deploying BCP 38! Wait, they are ...."
> Actually, it would be nice if someone who writes security software > like NOD32 or Malwarebytes, or spybot, adaware, etc, would > integrate it into their test suite. Then you get the thousands of > users from them added to the results. I have just sent an email to ESET promoting participation on the BCP38 initiative by incorporating spoofer projects program in their program suite. If there's more of us maybe we can make a change. adam -Original Message- From: Robert Drake [mailto:rdr...@direcpath.com] Sent: Tuesday, February 18, 2014 9:56 PM To: nanog@nanog.org Subject: Re: "Everyone should be deploying BCP 38! Wait, they are " On 2/18/2014 2:19 PM, James Milko wrote: > Is using data from a self-selected group even meaningful when > extrapolated? It's been a while since Stats in college, and it's very > likely the guys from MIT know more than I do, but one of the big > things they pushed was random sampling. > > JM > > Isn't it probable that people who know enough to download the spoofer projects program and run it might also be in position to fix things when it's broken, or they may just be testing their own networks which they've already secured, just to verify they got it right. I may put it on my laptop and start testing random places like Starbucks, my moms house, conventions and other things, but if I'm running it from my home machine it's just to get the gold "I did this" star. So yeah, data from the project is probably meaningless unless someone uses it as a worm payload and checks 50,000 computers randomly (of course I don't advise this. I just wish there was a way to really push this to be run by everyone in the world for a week) Maybe with enough hype we could get CNN to advise people to download it. Actually, it would be nice if someone who writes security software like NOD32 or Malwarebytes, or spybot, adaware, etc, would integrate it into their test suite. Then you get the thousands of users from them added to the results.
mac limit per VPLS domain
I'm wondering what would be the sane default MAC limit per VPLS domain as well as per port assuming the RSP can hold up to 512K MAC addresses please? I believe the answer would partly depend on the business model (like I can start with 2 MACs per port and 50 per domain and have customers to pay extra for additional MACs) as well as expected number of VPLS customers/domains Thank you
RE: Are people still building SONET networks from scratch?
>Does anyone make a cheaper OC3 circuit emulation module or box? Maybe Cisco ME 3600X 24CX Switch or Cisco ASR 903 Router adam
Ethernet OAM BCPs Please are there any yet???
Hi Are there any best common practices for the CFM levels use Since my pure Ethernet aggregation layers are small I believe I only need two CFM levels I plan on using Level 5 between CPEs managed by us and Level 4 between Aggregation devices -that's where MPLS PWs kicks in So leaving Level 7 and Level 6 for customers and carrier-customers respectfully -would this be enough please? I'm also interested on what's the rule of thumb for CCMs Frequency, Number of Packets, Interpacket Interval, Packet Size and Lifetime for the particular operation Thanks a lot for any inputs adam
RE: Ethernet OAM BCPs Please are there any yet???
Thank you so much Jonathon. This is exactly what I what I was searching for. Oh and yes I should have mentioned I'd like to do the Y.1731 and measure the delay and delay variance Just yesterday evening I found a great article about how ATT did theirs active measurements though for IP - wondering if I could do the same for my Y.1731 They used dedicated servers and I'll be running this form the routers ME3600X and CX and ASR9K so I'm a bit worried about the scaling of the whole thing ATT basically used two probes and each 24-hour day is divided into 96 test cycles of 15 minutes A Poisson probe sequence of duration equal to the test cycle characteristics: - Poisson distribution with average interarrival time of 3.3 s - Packet size of 278 bytes, including headers - UDP protocol Two periodic probe sequences in every test characteristics: - Interval of 20 ms between successive packets (or 50 packets/s) - 1 min duration - Random start time within the 15 min cycle - Packet size of 60 bytes (including headers) - UDP protocol adam -Original Message- From: Jonathon Exley [mailto:jonathon.ex...@kordia.co.nz] Sent: Wednesday, September 26, 2012 6:34 PM To: nanog@nanog.org Subject: RE: Ethernet OAM BCPs Please are there any yet??? The ITU recommend the following levels: 5,6,7 = Customer 3,4 = Provider 1,2 = Operator 0= Local segment I don't know if there are any rules of thumb for the CCM interval - faster is more sensitive & unstable, slow is sluggish but stable. The spec allows between 3.33 ms and 10 minutes in 7 steps, with 1s being the midpoint. So we use 1s intervals. I'm not sure if the other parameters you mention are configurable for CCM. I think the packet has a constant size. Are you wanting to also do Y.1731 performance management? Jonathon > -----Original Message- > From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk] > Sent: Wednesday, 26 September 2012 9:29 p.m. > To: nanog@nanog.org > Subject: Ethernet OAM BCPs Please are there any yet??? > > Hi > Are there any best common practices for the CFM levels use Since my > pure Ethernet aggregation layers are small I believe I only need two > CFM levels I plan on using Level 5 between CPEs managed by us and > Level 4 between Aggregation devices -that's where MPLS PWs kicks in So > leaving Level 7 and Level 6 for customers and carrier-customers > respectfully -would this be enough please? > > I'm also interested on what's the rule of thumb for CCMs Frequency, > Number of Packets, Interpacket Interval, Packet Size and Lifetime for > the particular operation Thanks a lot for any inputs This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R).
MP-BGP next hop tracking delay 0
I was wondering whether you have some experience with setting of the next hop tracking delay value for BGP to 0 for critical changes please There's gonna be only a few prefixes registered with BGP so far, around 150+ adam
RE: MPLS acceptable latency?
It might be some T1 muxing issue adam -Original Message- From: Mikeal Clark [mailto:mikeal.cl...@gmail.com] Sent: Thursday, November 15, 2012 8:35 PM To: Jared Mauch Cc: nanog@nanog.org Subject: Re: MPLS acceptable latency? The location in question is 7 T1s. They were not willing to give us fiber. On Thu, Nov 15, 2012 at 1:20 PM, Jared Mauch wrote: > > On Nov 15, 2012, at 2:15 PM, Scott Weeks wrote: > >> >> >> --- mikeal.cl...@gmail.com wrote: >> From: Mikeal Clark >> >> I have some AT&T MPLS sites under a managed contract with latency >> averaging 75-85 ms without any load. These sites are only 45 minutes >> away. What is considered normal/acceptable? >> >> >> >> Coast-to-coast latency is around 60-65msec, so that's high. > > What link speed? > > Perhaps he's using ISDN or a T1? > > Serialization delay is not to be ignored. > > - Jared >
RE: Google/Youtube problems
>From the latest csco prime presentation it appears it offers similar functionality in one of the modules that one can buy to it so that providers can have a sneak peak on these type of data in order to sell them to third parties Though I wouldn't even know whom to sell such information Nor have I been hit by a targeted advertisement, yet adam -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, November 19, 2012 3:30 PM To: nanog@nanog.org Subject: Re: Google/Youtube problems In a message written on Mon, Nov 19, 2012 at 03:59:22PM +0200, Saku Ytti wrote: > What I'm trying to say, I can't see youtube generating anywhere nearly > enough revenue who shift 10% (or more) of Internet. And to explain > this conundrum to myself, I've speculated accounting magic (which I'd > frown > upon) and leveraging market position to get free capacity (which is > ok, I'd do the same, had I the leverage) I suspect you're thinking about revenue in terms of say, the advertisements they run with the videos. I beleive you're right, that would never pay the bills. Consider a different model. Google checks out your gmail account, and discovers you really like Red Bull and from your YouTube profile knows you watch a lot of Ke$ha videos. It also discovers there are a lot more folks with the same profile. They can now sell that data to a marketing firm, that there is a strong link between energy drinks and Ke$ha videos. GOOG-411 - building a corpus of voice data for Android's voice recognition. ReCaptcha - improving visual recognition for their book scanning process. Most of the "free" services are simply the cheapest way to get the data needed for some other service that can make much more money. It may seem weird to write off all the costs of YouTube as data aquisition costs, but there's far more money to be made selling marketing data than ads against streaming videos... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: Google/Youtube problems
For some providers this might be an interesting revenue stream in these days where we need to build ever faster backbones to carry more and more video traffic for users that want to pay less and less for high-speed internet connectivity adam -Original Message- From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk] Sent: Monday, November 19, 2012 4:17 PM To: 'Leo Bicknell'; 'nanog@nanog.org' Subject: RE: Google/Youtube problems >From the latest csco prime presentation it appears it offers similar functionality in one of the modules that one can buy to it so that providers can have a sneak peak on these type of data in order to sell them to third parties Though I wouldn't even know whom to sell such information Nor have I been hit by a targeted advertisement, yet adam -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Monday, November 19, 2012 3:30 PM To: nanog@nanog.org Subject: Re: Google/Youtube problems In a message written on Mon, Nov 19, 2012 at 03:59:22PM +0200, Saku Ytti wrote: > What I'm trying to say, I can't see youtube generating anywhere nearly > enough revenue who shift 10% (or more) of Internet. And to explain > this conundrum to myself, I've speculated accounting magic (which I'd > frown > upon) and leveraging market position to get free capacity (which is > ok, I'd do the same, had I the leverage) I suspect you're thinking about revenue in terms of say, the advertisements they run with the videos. I beleive you're right, that would never pay the bills. Consider a different model. Google checks out your gmail account, and discovers you really like Red Bull and from your YouTube profile knows you watch a lot of Ke$ha videos. It also discovers there are a lot more folks with the same profile. They can now sell that data to a marketing firm, that there is a strong link between energy drinks and Ke$ha videos. GOOG-411 - building a corpus of voice data for Android's voice recognition. ReCaptcha - improving visual recognition for their book scanning process. Most of the "free" services are simply the cheapest way to get the data needed for some other service that can make much more money. It may seem weird to write off all the costs of YouTube as data aquisition costs, but there's far more money to be made selling marketing data than ads against streaming videos... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: /. ITU Approves Deep Packet Inspection
So is it recommended now to go over all the NGN core routers and restore them to default with: no lawful-intercept disable cmd? :) adam
RE: OOB core router connectivity wish list
>"CMP" this is what we need. +1000
RE: L2 redundant VPN
> Run MPLS over these four boxes and build L2 pseudowires across Using link bundling and one router at each end has faster convergence and it's cheaper, you can do l2tpv3 if you can't have mpls adam
RE: Metro Ethernet, VPLS clarifications
And for fun you can also do: Ethernet over PBB to VPLS Ethernet over PBB over VPLS -that's actually called EVPN adam -Original Message- From: Fabien Delmotte [mailto:fdelmot...@mac.com] Sent: Wednesday, February 06, 2013 4:07 PM To: Scott Helms Cc: NANOG; Abzal Sembay Subject: Re: Metro Ethernet, VPLS clarifications Hi, My 2 cents > VPLS can be run across several different kinds of layer 1 & 2 > technologies and is independent of the underlying technology because > it builds it pseudo wires at layers 3 & 4. VPLS leverages technologies > like Metro Ethernet and MPLS to extend a business' Ethernet LAN > (technically the broadcast domain) to remote sites. At the end of the > day you can use several kinds of tunneling technologies to provide VPLS, including GRE, MPLS, and L2TPv3. For fun you can also do : LDP VPLS over a GRE tunnel LDP over a GRE tunnel within an encrypted network I can be wrong but VPLS is running over MPLS (rfc 4762) because it is using LDP Regards Fabien Le 6 févr. 2013 à 15:41, Scott Helms a écrit : >> >> From my understanding M-Ethernet is a some kind of service. >> Standartized technology that allows to connect multiple different >> networks. And it is independent from physical and datalink layers. >> > > Metro Ethernet is a datalink (layer 2) protocol. It also has physical > (layer 1) specifications though there are several kinds of physical > medium that can be used. Most commonly its delivered over fiber > (single or multi-mode depending on distance from the last active > element) or cat 5E/6 twisted pair. > > > >> And nowadays which tecnology is the most used(VPLS or Metro)? What >> about MPLS? Sorry I'm a little confused. I really want to understand. >> > > VPLS can be run across several different kinds of layer 1 & 2 > technologies and is independent of the underlying technology because > it builds it pseudo wires at layers 3 & 4. VPLS leverages technologies > like Metro Ethernet and MPLS to extend a business' Ethernet LAN > (technically the broadcast domain) to remote sites. At the end of the > day you can use several kinds of tunneling technologies to provide VPLS, including GRE, MPLS, and L2TPv3. > > Here are the main two RFCs: > > http://tools.ietf.org/html/rfc4761 > http://tools.ietf.org/html/rfc4762 > > >> >> >> -- >> Regards, >> >> Abzal >> >> > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > > http://twitter.com/kscotthelms >
RE: Alcatel-Lucent and France Tel deploy 400G for testing
Can't find any statement whether the nifty proclaimed 400G wavelength is indeed a single 100GHz channel or just a bundled supper channel The only hint is the total capacity of a fiber of 17.6 Tbps with 44 wavelengths which is roughly the whole 100GHz spaced grid adam -Original Message- From: Jay Ashworth [mailto:j...@baylink.com] Sent: Wednesday, February 06, 2013 7:04 PM To: NANOG Subject: Alcatel-Lucent and France Tel deploy 400G for testing http://www.telecomramblings.com/2013/02/alcatel-lucent-and-france-telecom-surpass-100g-implement-400g/ -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
RE: The 100 Gbit/s problem in your network
> > to watch the latest Quad-HD movie >"Multicast" -I'm afraid it has to be unicast so that people can pause/resume anytime they need to go... well you know what I mean adam
RE: The 100 Gbit/s problem in your network
> Works fine too with multicast, for instance with FuzzyCast: Well yes but you need to make some compromises on behalf of user experience. And 30sec delay is unacceptable. You can use 10 cheaper VOD servers closer to eyeballs making it 1000 customers abusing the particular portion of the local access/aggregation network. adam
RE: The 100 Gbit/s problem in your network
>The only time real-time per se matters is if you're playing the same content >on multiple screens and *synchronization* matters. And there's the HFT where "real-time" really does matter :) adam
RE: The 100 Gbit/s problem in your network
I don't see a need for multicast to work in Internet scale, ever. adam -Original Message- From: Saku Ytti [mailto:s...@ytti.fi] Sent: Friday, February 08, 2013 6:02 PM To: nanog@nanog.org Subject: Re: The 100 Gbit/s problem in your network On (2013-02-08 14:15 +), Aled Morris wrote: > "Multicast" I don't see multicast working in Internet scale. Essentially multicast means core is flow-routing. So we'd need some way to decide who gets to send their content as multicast and who are forced to send unicast. It could create de-facto monopolies, as new entries to the market wont have their multicast carried, they cannot compete pricing wise with established players who are carried. -- ++ytti
RE: The 100 Gbit/s problem in your network
> Multicast is dead. Feel free to disagree. :-) > > Tim:> > Multicast will never be dead. With ever raising bandwidth needs we'll always welcome a distribution method that allows us to pass the same data least times over the least number of links. We all remember the spikes in BW demands when the Austrian fellow jumped from space And regarding the global m-cast. Well we don't need it. You can get the IPTV streams via direct link or via common carrier's mvpn adam
RE: Cloudflare is down
> From my point of view, outages are caused by: > 1) operator > 2) software defect > 3) hardware defect >From my experience now days the likelihood of an outage as a result of 3) is magnitude less than 2) and same goes for 2) to 1) ratio. In other words the vast majority of the outages are caused by human error. One way to partially rule out 1) is to have a fully customized stupid proof provisioning system - customized by those who know how stuff works. adam
RE: internet routing table in a vrf
Hi 1) control plane (route reflectors ) - you can either run a separate control plane infrastructure for inet vrf or you can use common RRs that depends on your hardware capabilities (or you can run a separate BGP process for reflecting inet vrf). - no need to worry about data-plane as VPN routes are not installed into FIB on RRs. - as it was mentioned already porting inet prefixes into VPN table increases control-plane demands. 2) forward plane (recursive lookup issues) - for inet vrf I'd recommend per CE/next-hop labels instead of per prefix labels to save up some label space. - per next-hop label still points directly to outgoing interface so no recursive lookups. - recursive lookups are only needed with per VRF label -but I would not recommend that as it could introduce loops when PIC is used in some scenarios. 3) Operational - I find it operationally complex to keep inet table on the P-Core boxes/vrf-default. 4) DDOS - as I mentioned you can run a separate infrastructure for inet vrf i.e. dedicated box or SDR for inet PEs and inet RRs. - or you can use separate BGP processes so in case some university decides to test some special attribute on their BGP advertisements it will not reload your VPN BGP process. - or you can deploy enhanced BGP error handling on the edges and hope for the best (actually this is what should be implemented as a first thing). adam
RE: internet routing table in a vrf
There's some fundamental misunderstanding here. By default with vpnv4 and vpnv6 address-familie there's next hop self set by the PE. Local-Repair and label-retention was around many years before PIC came along. It worked nicely with eibgp multipath and allowed the primary PE to work around the failed PE-CE link and send traffic to alternate PE that advertised the same prefix. The added value with PIC is you don't have to have equal attributes in order to have an alternate path installed into FIB There are no micro-loops involved on an alternate PE. During normal operation packet incoming on Primary PE would be label-switched based on the per-prefix or per-ce label via PE-CE link as directed by the L2 overwrite in the FIB. In case of the local PE-CE link failure. PIC or Local-Repair will just label switch the incoming label with label advertised by the alternate PE. Once the alternate PE receives the labeled packet it will just label-switch it out the PE-CE link. During normal operation or during failure there is no recursive lookup done just label-switching. As Ytti pointed out already you don't want the PE-CE links to be carried by the IGP as you can fast reroute over their failure and perform a "local-repair" until the BGP converges and the ingress PE starts forwarding traffic to alternate PE/NH. The only case when you experience an excessive loss of connectivity is when the egress PE fails -in that case you need to really on the speed of IGP convergence to inform the ingress PE to switch to a preprogramed backup path/NH (PIC CORE). There are already some RFCs that propose P-core to fast reroute to alternate PE in case the primary PE fails - can't wait :). adam -Original Message- From: Matt Newsom [mailto:matt.new...@rackspace.com] Sent: Friday, March 08, 2013 7:18 PM To: Saku Ytti; nanog@nanog.org Subject: RE: internet routing table in a vrf If you run PIC and hide the next hop information between a loopback which is what will happen in a vpn environment you will lose awareness of the failure of an edge link on a remote PE. The remote PE will continue to send traffic to the PE with the failed link until it has completely converged both at the control plane, and written to the FIB. If the remote PE has PIC running he can bounce that traffic back to his backup path via another PE. There will be some percentage of your traffic that will then form a transient micro loop though because that remote PE will have his primary path through the failed link due to shortest as path length etc, and he will not have converged yet around the failure on the remote PE and has no awareness of the failure. One possible solution to this is to guarantee that a PE will never use another PE for a primary transit route. This can be accomplished via metrics such as weight etc.. Again one of the downsides of this is you need to run VRF labels so that a local IP lookup can be done on the PE with the failed link and it can execute a local repair when it see's the link drop. -Original Message- From: Saku Ytti [mailto:s...@ytti.fi] Sent: Friday, March 08, 2013 11:23 AM To: nanog@nanog.org Subject: Re: internet routing table in a vrf On (2013-03-08 16:40 +), Matt Newsom wrote: > 2) forward plane (recursive lookup issues) > Most platforms program prefix's with associated labels slower so your base convergence will suffer. Do you have any reference you could share? What level of penalty per prefix have you observed in each platform tested? >In addition if you want to run PIC you will likely be left with a bit of custom engineering to make it work. VPN's hide the next hop behind the loopback of the PE so next hop failure awareness of an edge tie will be lost. If you can stomach the double lookup you can run per-vrf labels (per prefix isn't feasible on most platforms) and weight up your edge ties and force a bounce back to another PE, otherwise you will be stuck with bgp control plane based convergence with per-ce labels. PIC is about converging each prefix at the same time. It does not make statement where next_hop is pointing, is it loop0 (next-hop-self in INET) or is it edge CE. If your IGP carries all edge links, and you don't run next-hop-self, far end PE can converge faster in INET scenario. But current efforts are not to fix this, current efforts are to make the local PE do hitless repair when arriving frame is pointing to dead edge interface. It seems to be very rare to run INET in this way, majority don't carry edge links in IGP and do run next-hop-self. -- ++ytti
RE: CBT Nuggets streaming account
CBT Nuggets is just a quick overview of what you need to read and lab through in order to know your stuff adam -Original Message- From: Ryan Burtch [mailto:rburt...@gmail.com] Sent: Tuesday, June 12, 2012 3:21 PM To: Jonathan Rogers Cc: nanog@nanog.org Subject: Re: CBT Nuggets streaming account I used cbt nuggets conceptually in ccna and it gave me a good overview of the concepts. It may be my style of learning. That said, I was only asking if someone would be willing to help me with ccnp cbt nuggets training as I know that streaming accounts are multi user. On Jun 11, 2012 5:05 PM, "Jonathan Rogers" wrote: > > GNS3 is completely insufficient for CCNP-level training and labs. You will need actual equipment. Fortunately, it has gotten a lot cheaper over the past few years and you don't need the latest and greatest. Check out Wendell Odom's website for tips. > > Also we have a CBTNuggets account at my company and I was unimpressed with their Cisco coverage, but that may be a matter of taste. > > Just my $0.02...as a CCNA working towards MY CCNP. > > --jono > > > On Mon, Jun 11, 2012 at 4:56 PM, Garrett Skjelstad > wrote: >> >> Don't spam the list looking for black market copies of training material. Use GNS3 and design your own labs and google the test topics. Plzkthx. >> >> Sent from my iPhone >> >> On Jun 11, 2012, at 12:30, Ryan Burtch wrote: >> >> > Could someone contact me off list if you have a CBT Nuggets >> > streaming account and would be willing to help me in working towards my CCNP? >> >
RE: IPv6 Lo. for 6PE/6VPE
Right the :::: sounds familiar I guess there was also an option that the P router would just label switch the packet towards the exit PE and the PE would than originate the ICMP back to source Or you can turn off TTL propagation across the core -so the ICMP could only time out at the PEs adam -Original Message- From: Nagendra Kumar (naikumar) [mailto:naiku...@cisco.com] Sent: Friday, June 15, 2012 12:52 PM To: Daniel Roesen; nanog@nanog.org Subject: RE: IPv6 Lo. for 6PE/6VPE Hi, Per my understanding, it is not required to have ipv6 address in loopback intf on all P routers inorder to have 6PE work. If I remember it correctly, P router will use :::: while originating ICMPv6 error message. -Nagendra -Original Message- From: Daniel Roesen [mailto:d...@cluenet.de] Sent: Friday, June 15, 2012 4:02 PM To: nanog@nanog.org Subject: Re: IPv6 Lo. for 6PE/6VPE On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree wrote: > I was just wondering , while I'm planning my network to support > 6PE/6VPE why should i assign an IPv6 for Loopbacks? > > Maybe it's needed for Point-Point links or external interfaces between > my peers, but anyone here know why i should assign IPv6 for all my > Routers inside my ISP if we will run PE/6VPE not dual stack. Otherwise the intermediate P devices do not have an address to source ICMPv6 "hop count exceeded" error replies => traceroute doesn't work properly. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
RE: raging bulls
No, not ever shorter under-see cables no. NEUTRINOS -shooting information at speed of light right through the earth (not around it) Should there be any high speed traders in here this is what you should invest all your money in to gain advantage against your competition First it was cold war times which gave birth to the Internet, that has changed our lives from the ground up Maybe this time it will be the stock markets and scent of money that will give the communication development spiral an unimaginable momentum adam -Original Message- From: Naslund, Steve [mailto:snasl...@medline.com] Sent: Wednesday, August 08, 2012 4:14 PM To: nanog@nanog.org Subject: RE: raging bulls It is a tough technical problem to be sure but not insurmountable. Think about a system in which the real time market data is also encrypted in such a way that it can only be decrypted at a particular point in time. Essentially it would be like each trading system receiving an envelope that must be opened simultaneously. Picture a satellite network that is time synchronized to transmit a key stream used to decrypt the data that is received over a terrestrial network. I am not talking about easy to implement here just what is possible. It is probably easier than faster than light travel although I supposed real estate on Mt Everest could get very valuable (closer to the satellites) :) Steve -Original Message- From: Brett Frankenberger [mailto:rbf+na...@panix.com] Sent: Wednesday, August 08, 2012 9:08 AM To: Naslund, Steve Cc: nanog@nanog.org Subject: Re: raging bulls On Wed, Aug 08, 2012 at 08:52:51AM -0500, Naslund, Steve wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. This isn't about giving international traders a fair shake. This sort of latency is only relevant to high speed program trading, and the international traders can locate their servers in NYC just as easily as the US-based traders. What it's about is allowing traders to arbitrage between markets. When product A is traded in, say, London, and product B is traded in New York, and their prices are correlated, you can make money if your program running in NY can learn the price of product B in London a few milliseconds before the other guy's program. And you can make money if your program running in London can learn the price of product A in NY a few milliseconds before the other guy's program. Even if you execute the trades based on a GPS timestamp (I'm ignoring all the logistics of preventing cheating here), it doesn't matter, because the computer that got the information first will make the trading decision first. -- Brett
RE: [c-nsp] DNS amplification
>Indeed, in many cases, why aren't these things an external, separately rack mountable box with simply an interconnect to speak to the control plane? You mean like CRS multi-chassis systems? adam
RE: BCP38 - Internet Death Penalty
> If you are doing strict BGP prefix-filter, it's either very easy to generate ACL while at it Yes and that is exactly what needs to become a habit for all the operators. We all do care what our neighbors advertise to us or what prefixes we accept from them. But only a few really do care whether that's actually what is leaving our neighbor's network. It's a pity that rpf is not "on" by default for interfaces over which the ebgp session is configured. adam
RE: BCP38 - Internet Death Penalty
Yes I see now I have worded it miserably :) What I got on my mind was an eBGP session to stub site /single homed customer. Now that I think about it I believe it could have been "on" by default on all the router interfaces and would have to be turned off manually(or automatically if mpls is enabled on the interface) for core interfaces and interfaces facing dual-homed sites. Anyways disabling urpf would than soon become a part of standard interface-config templates. So I guess no matter what tools we'd have it boils down to (and I don't want to use a word "laziness") maybe comfortability of operators. adam -Original Message- From: wher...@gmail.com [mailto:wher...@gmail.com] On Behalf Of William Herrin Sent: Thursday, March 28, 2013 2:43 PM To: Adam Vitkovsky Cc: Saku Ytti; nanog@nanog.org Subject: Re: BCP38 - Internet Death Penalty On Thu, Mar 28, 2013 at 8:20 AM, Adam Vitkovsky wrote: > It's a pity that rpf is not "on" by default for interfaces over which > the ebgp session is configured. Hi Adam, Considering that's one of the key scenarios for which RPF is known to NOT WORK reliably, I would have to disagree with that statement. Folks running BGP expect to manipulate routes asymmetrically. If you had said, "It's a pity that RPF is not on by default over interfaces for which no routing protocol is configured (connected and static routes only)" I might have agreed with you. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
RE: BCP38 - Internet Death Penalty
> If the best route you pick for the customer's advertisement goes to your upstream instead of your customer, you won't advertise it to your peer. > And if your customer sets a BGP community defined to mean "don't advertise to peers" then you won't advertise it to the peer. > Yet they may well transmit packets to you for which delivery to that peer is directed by your routing table. Yes asymmetric routing would kill the update-based urpf unless there would be an informational urpf NRLI we could use for these purposes adam
RE: route for linx.net in Level3?
First of all I agree with Leo that not advertising IX prefixes permanently causes more problems than it solves. > Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it Well if I would peer with such an ISP at London and Frankfurt I could create a GRE tunnel from London to Frankfurt via the other ISP and use it to transport packets that would otherwise have to traverse my backbone. Or if my peer has a router at IX that happens to have full routing view I can just point a static default toward it and have a free transit. Check out: http://www.bcp38.info adam -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Thursday, April 04, 2013 9:29 PM To: NANOG Subject: Re: route for linx.net in Level3? In a message written on Thu, Apr 04, 2013 at 02:57:11PM -0400, Jay Ashworth wrote: > Yes. In the fallout from the Cloudflare attack of last week it was > announced that several IXs were going to stop advertising the address > space of their peering lan, which properly does not need to be > advertised anyway. Well, now that's a big maybe. I was a big advocate for the peering exchanges each having their own ASN and announcing the peering block back in the day, and it seems people may have forgotten some of the issues with unadvertised peering exchange blocks. It breaks traceroute for many people: The ICMP TTL Unreachable will come from a non-routed network (the exchange LAN). If it crosses another network boundary doing uRPF, even in loose mode, those unreachables will be dropped. It also reduces the utility of a tool like MTR. Without the ICMP responese it won't know where to ping, and even if it receives the ICMP it's likely packets towards the LAN IP's will be dropped with no route to host. It has the potential to break PMTU discovery for many people: If a router is connected to the exchange and a lower MTU link a packet coming in with DF set will get an ICMP would-fragment reply. Most vendors source from the input interface, e.g. the exchange IP. Like the traceorute case, if crosses another network boundary doing uRPF, even in loose mode, those ICMP messages will be lost, resulting in a PMTU black hole. Some vendors have knobs to force the ICMP to be emitted from a loopback, but not all. People would have to turn it on. But hey, this is a good thing because a DDOS caused issues, right? Well, not so much. Even if the exchange does not advertise the exchange LAN, it's probably the case that it is in the IGP (or at least IBGP) of everyone connected to it, and by extension all of their customers with a default route pointed at them. For the most popular exchanges (AMS-IX, for instance) I suspect the percentage of end users who can reach the exchange LAN without it being explicitly routed to be well over 80%, perhaps into the upper 90% range. So when those boxes DDOS, they are going to all DDOS the LAN anyway. Security through obscurity does not work. This is going to annoy some people just trying to do their day job, and not make a statistical difference to the attackers trying to take out infrastructure. How about we all properly implement BCP 38 instead? -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: route for linx.net in Level3?
> The older school of thought was to put all of the edge interfaces into the IGP, and then carry all of the external routes in BGP. I thought people where doing it because IGP converged faster than iBGP and in case of an external link failure the ingress PE was informed via IGP that it has to find an alternate next-hop. Though now with the advent of BGP PIC this is not an argument anymore. adam
RE: Ethernet CFM & LMI vs EBGP between PE-CE
Well CFM and Ethernet LMI is great help in L2VPN services to pin point the failed portion of the L2 circuit. For L3VPN services I rather relay on BFD over PE-CE link and BGP PIC Edge in the backbone to achieve fast convergence. adam
RE: Illegal usage of AS51888 (and PI 91.220.85.0/24) from AS42989 and AS57954 (in ukraine)
-Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Friday, May 03, 2013 8:21 PM > From a deployment point of view, there's a pretty big gap between poking around with rpki and actually dropping prefixes on your routers. I don't see that the rpki data will be good enough for the latter any time soon, but maybe one day. Well you can always jus lower the preference for a particular prefix based on the roa state or roa missing. Than it is solely up to your customers whether they bother to register their prefixes to avoid hijacks or not, as you'll be ready on your part. adam
RE: Variety, On The Media, don't understand the Internet
Maybe we should try poetry, Human, you tied the soul, You will not behold joy if you break down that wall, So why the leaving beam is calling you, Brick by brick, slowly one by one, ... hoping to at least catch a glimpse of ray. Translated from: Kingmaker (Life ... in a nest of copper) By: Rikin adam -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Wednesday, May 15, 2013 8:07 PM To: Jean-Francois Mezei Cc: nanog@nanog.org Subject: Re: Variety, On The Media, don't understand the Internet On May 15, 2013, at 09:59 , Jean-Francois Mezei wrote: > On 13-05-15 09:02, Brett Frankenberger wrote: > >> So it's only on the Internet if it uses a provider's transit capacity? All of this is leading me to the following conclusion: If we, as network engineers can't agree on the nature and definition of the internet, how can we possibly expect the media to understand it? Owen
RE: PRISM: NSA/FBI Internet data mining project
>Happily, none of the companies listed are transport networks: I believe it's logical that government turned to biggest US based ISPs with request to help monitoring communication channels after 2001 events, as back in those days facebook was not around and google was not as prevalent. But to be frank I don't know what was the nature of monitoring, phone calls, internet communication, ... adam
RE: PRISM: NSA/FBI Internet data mining project
> How would you tap a few TBit/s so that you can filter it down to where you can look it at layer 7 in ASICs, and filter out something to a more manageable data rate? Well "lawful-intercept" is on by default. And you don't get to worry about the L7 and filtering/parsing -that's done by the black boxes. adam
RE: Single AS multiple Dirverse Providers
> neighbor a.b.c.d allowas-in route-map SAFETY Wow this would be so cool, I'll definitely mention this to our SE. I was wondering if the internet service is realized as MPLS VRF than the ISP could do as-override which is pretty standard for VPN services. What I'm curious about is the percentage of tier2/3 ISPs doing full internet in a VRF over common MPLS backbone as I guess it's not that common. adam
RE: Multihop eBGP peering or VPN based eBGP peering
> route reflectors should be in the data plane, ... I believe in modern networks data-plane and control-plane(s) should be separated as it provides for great scalability and versatility the drawback of course is a more complex system to manage. adam
RE: Multihop eBGP peering or VPN based eBGP peering
-Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Monday, June 24, 2013 2:32 PM To: Adam Vitkovsky Cc: 'John van Oppen'; nanog@nanog.org Subject: Re: Multihop eBGP peering or VPN based eBGP peering >>> route reflectors should be in the data plane, ... >> I believe in modern networks data-plane and control-plane(s) should be >> separated as it provides for great scalability and versatility the >> drawback of course is a more complex system to manage. >more complex systems scale poorly, break easily, and are hard to debug. >oops! all my competitors should have such 'modern networks.' >randy Well in the context of RRs complex systems have virtually endless scalability, they are built with redundancy in mind so they don't break or don't break easily and well as far as the debug goes, I think it's a matter of how well are the Operations educated by the architects. adam
