RE: So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today
It looks great though I would not want to troubleshoot the RIB to FIB programing errors unless there's a note somewhere saying what abbreviation to search for in FIB. The other think that comes to mind is that the more specifics could have different backup next-hops programed. adam From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brett Frankenberger Sent: Thursday, August 14, 2014 4:50 AM On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote: you mean your vendor won't give you the knobs to do it smartly ([j]tac tickets open for five years)? wonder why. Might be useful if you mentioned what you considered a smart way to trim the fib. But then you couldn't bitch and moan about people not understanding you, which is the real reason you post to NANOG. Optimization #1 -- elimination of more specifics where there's a less specific that has the same next hop (obviously only in cases where the less specific is the one that would be used if the more specific were left out). Example: if 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 with a different next hop). Optimization #2 -- concatenation of adjacent routes when they have the same next hop Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, leave them both out of TCAM and install 10.10.14.0/14 Optimization #3 -- elimination of routes that have more specifics for their entire range. Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, 10.10.6.0/24 an 10.10.7.0/24 all exist Some additional points: -- This isn't that hard to implement. Once you have a FIB and primitives for manipulating it, it's not especially difficult to extend them to also maintain a minimal-size-FIB. -- The key is that aggregation need not be limited to identical routes. Any two routes *that have the same next hop from the perspective of the router doing the aggregating* can be aggregated in TCAM. DFZ routers have half a million routes, but comparatively few direct adjacencies. So lots of opportunity to aggregate. -- What I've described above gives forwarding behavior *identical* to unaggregated forwarding behavior, but with fewer TCAM entries. Obviously, you can get further reductions if you're willing to accept different behavior (for example, igoring more specifics when there's a less specific, even if the less specific has a different next hop). (This might or might not be what Randy was talking about. Maybe he's looking for knobs to allow some routes to be excluded from TCAM at the expense of changing forwarding behavior. But even without any such things, there's still opportunity to meaningfully reduce usage just by handling the cases where forwarding behavior will not change.) -- Brett
RE: Verizon Public Policy on Netflix
-Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matthew Petach Sent: Friday, July 11, 2014 3:35 AM So, if Netflix had to pay additional money to get direct links to Verizon, you'd be OK paying an additional 50cents/month to cover those additional costs, right? And when Time Warner also wants Netflix to pay for direct connections, you'd be ok paying an additional 50cents/month to cover those costs as well, right? And another 50cents/month for the direct connections to Sprint? And another 50cents/month for the direct connections to cablevision? (repeat for whatever top list of eyeball networks you want to reference). At what point do you draw the line and say wait a minute, this model isn't scalable; if every eyeball network charges netflix to connect directly to them, my Netflix bill is going to be $70/month instead of $7/month, and I'm going to end up cancelling my subscription to them. Matt I disagree as all of this makes perfect sense. Would it be right if Netflix comes to You and says we see you've got a lot of our customers hooked up to your backbone so to serve better service we'd like to connect to your network directly. And you goes: so you would like to become our customer? Sure this is the monthly fee for the link and transport service that would suite your needs. And Netflix goes: well how about you build the link to us bearing all the costs and you gonna charge us nothing for the transport you provide, deal? What would be your answer? Of course this good deal has some precursors. If your customers fail to obey your statistical multiplexing predictions and links to your upstreams are running hot than you have several options. a) You could pay for the upgrades of links to your upstreams. b) You could take the good deal Netflix has proposed to save costs for a). c) You could not give a damn about your customers as they have nowhere else to go anyways and use this advantage to force Netflix to become your customer (well paying customer as they would need big pipes). What would you do? Options a) and b) assumes of course that Netflix has good connections to their upstreams and not misusing their position into forcing the customer relationship into free peering one. adam
RE: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Irwin, Kevin Sent: Wednesday, May 07, 2014 4:39 PM I¹m really surprised that most people have not hit this limit already, especially on the 9K¹s, as it seems Cisco has some fuzzy math when it comes to the 512K limit. I would actually be very surprised if someone would hit the 512K limit on ASRs. With 6500/7600 I can understand they've been around for ages and no one anticipated the 512k limit back then. But ASRs? When these where bough engineers must have known that 512k is not going to be enough. I guess one does some reading and tweaking before installing a box as a PE or Internet Edge. adam
RE: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]
From: Mark Tinka [mailto:mark.ti...@seacom.mu] On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva) wrote: Segment routing (SR) could/would certainly work with single-stack v6 and enable MPLS forwarding. Certainly, but based on the Paris meeting, it was not high up on the agenda. So we will, likely, have to rely on other solutions and wait for SR to catch up later. At the moment, it seems SR is being pushed hard for PCEP as well as SDN. Mark. I think the most revolutionary SR use case is the: 3.2. Protecting a node segment upon the failure of its advertising node. Of the now expired: draft-filsfils-rtgwg-segment-routing-use-cases-02. It's the first, complete and elegant FRR solution for the hierarchical MPLS implementations. adam
RE: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]
Ideally, we would have a solution where an entire MPLS infrastructure could be built without v4 space, demoting v4 to a legacy application inside a VRF, but the MPLS standards wg seems content with status quo. There is work ongoing in the MPLS IETF WG on identifying the gaps that various MPLS applications have so they can be prepared for IPv6 MPLS control and data planes. Long overdue, if you ask me, but at least it's starting to get some attention. Mark. You mean the SR right? adam
RE: Best practices IPv4/IPv6 BGP (dual stack)
Sure it's a different transport protocol altogether, anyways It's interesting to see how everybody tends to separate the IPv4 and IPv6 AFs onto a different TCP sessions and still run the plethora of other AFs on the common v4 TCP session, maybe apart from couple of the big folks, who can afford running separate control-plane and edge infrastructure for some of the AFs, IPv6 AF being the first ran separately. adam
RE: The FCC is planning new net neutrality rules. And they could enshrine pay-for-play. - The Washington Post
How is this good for the consumer? How is this good for the market? You are asking a wrong question all they care about is Where's my moneyTM adam
RE: BGPMON Alert Questions
That Upstream B is simply accepting everything their customer is sending to them without applying proper filters, or checking to confirm that what their customer needs to send them should come from them is absolutely and unacceptably shocking! I wonder when (or if ever) we'll have such a discussion about data packets, i.e. finding that someone is not doing packet-filtering based on BGP updates is absolutely and unacceptably shocking! adam
RE: How to catch a cracker in the US?
From: Dobbins, Roland [mailto:rdobb...@arbor.net] Sent: Tuesday, March 11, 2014 8:06 AM Although it's questionable whether or not it's possible to remotely absolutely ascertain whether the attacking machine in question was being operated by miscreants unbeknownst to its actual owner. Though it's 100% correct would this withstand in the court? e.g. nope wasn't me downloading that movie, must have been a hacker misusing my PC, I didn't even know there's a torrent client as you guys call it installed on my PC I only use it to play solitaire.
RE: [c-nsp] OAM/CFM question on IOS-XR
Hi, Herro91 Sent: Wednesday, March 05, 2014 6:19 PM 1) I think I should be seeing MIPs in my traceroute when there is a P router in between the two PEs, correct? It is a L2 form of traceroute so it will record only L2 hops configured as MIPs or MEPs. So in a p2p PW there are going to be only PW endpoints as MEPs for a particular Level. 2) If the P router in between these PEs is just a transit node, what configuration is required to create the MIPs? See CFM is meant for L2 OAM where there are no interface ip addresses you can ping to or capture in a traceroute. So in case of an e.g. me3400 connected to your XR box than p2p PW to another XR box than another me3400 as CPE. These four boxes form the L2 domain over which you can utilize CFM to pin-point the failure. You could have the me3400 as MEPs and XR boxes as MIPs for the particular level. This gets handy as the L2 (aggregation) domain at each end of the MPLS cloud gets bigger and it's more difficult to see which L2 box dropped the ball. Regarding the MPLS core in between, well you already have tools to identify the failed P/core box. adam -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Herro91 Sent: Wednesday, March 05, 2014 6:19 PM To: Cisco-nsp; nanog@nanog.org Subject: [c-nsp] OAM/CFM question on IOS-XR Hi, I've been working on a basic configuration for E-OAM starting with one domain. I have CFM working between the PEs (IOS-XR) devices tied to an EoMPLS instance, but have a few questions below: 1) I think I should be seeing MIPs in my traceroute when there is a P router in between the two PEs, correct? 2) If the P router in between these PEs is just a transit node, what configuration is required to create the MIPs? I have seen the MIP autocreate all, but it seems to be tied to a service configuration under CFM which would not apply in the case of a transit/P router. Thanks! ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
RE: Filter on IXP
- the IXP participants keep their IRRDB information fully up-to-date Geez anything else but the fully up-to-date IRRDB please. That just won't fly. That's why I said that an up to date IRRDB would have been a nice side effect of IXP filtering. - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Yes this is a valid point I think the technicalities of how to implement this kind of filtering at the IXP equipment is out of scope for this discussion. Anyways I believe IXPs should not be responsible for this mess and that BCP38 should be implemented by the participants of an IXP. As Saku Ytti mentioned several times Tier2 ISPs are in the best position for a successful BCP38 filtering at their network boundaries. adam -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Sunday, March 02, 2014 2:01 PM To: Vitkovský Adam; Jérôme Nicolle; nanog@nanog.org Subject: Re: Filter on IXP On 02/03/2014 12:45, Vitkovský Adam wrote: On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. And that's a really nice side effect. and it only works for leaf networks. The moment your ixp supports larger networks, it will break things horribly. It also assumes that: - all your IXP members use route servers (not generally true) - the IXP kit can filter layer 3 traffic on all supported port configurations (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 and VPLS (not generally true) - the IXP port ASICs can handle large L2 access lists (not generally true) - there is an automatic mechanism in place to take RS prefixes and installed them on edge L2 ports (troublesome to implement and maintain) - there is a fail-safe mechanism to prevent this from causing breakage (difficult to implement) - the IXP participants keep their IRRDB information fully up-to-date (not generally true) - the IXP operators put in mechanisms to stop both route-leakages and incorrect IRRDB as-set additions from causing things to explode. Last but not least: - there is a mandate from the ixp community to get the IXP operators into the business of filtering layer 3 data (not generally the case) There are many places where automated RPF makes a lot of sense. An IXP is not one of them. Nick
RE: Filter on IXP
On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. And that's a really nice side effect. However in case of transit providers the problem is that RaDB /RIPE lists what prefixes you are allowed to advertise. But that does not necessarily fully match with what source IPs can leave your network. I mean ISP-A can have a customer that uses PA range of other ISP-B and only has a static route towards ISP-A for some TE purposes. I'm not well versed with RIPE myself so I'm not sure whether there's a way to handle this situation. adam -Original Message- From: Jérôme Nicolle [mailto:jer...@ceriz.fr] Sent: Friday, February 28, 2014 6:03 PM To: Nick Hilliard; nanog@nanog.org Subject: Re: Filter on IXP Le 28/02/2014 17:52, Nick Hilliard a écrit : this will break horribly as soon as you have an IXP member which provides transit to other multihomed networks. It could break if filters are based on announced prefixes. That's preciselly why uRPF is often useless. On the other hand, if a member provides transit, he will add its customer prefixes to RaDB / RIPEdb with appropriate route objects and the ACL will be updated accordingly. Shouldn't break there. -- Jérôme Nicolle +33 6 19 31 27 14
