Re: SDN - Killer Apps
Hi Glen. Here's some thoughts how Networking can learn from SDN: http://forums.juniper.net/t5/The-New-Network/Decoding-SDN/ba-p/174651 /Pelle
Re: Packet over SONET failback
Hi Jason. PoS failure detection happens in under 50ms IMHO this is the most important part, fast *down* detection. It's not actually SONET all the way through. It's GigE from the router to the SONET node, an unprotected OC192 wave to another node, out GigE to the far end router. If the gear manages to shut down the GE lasers within the 50ms, you have no rights at all to complain :-) I'm not necessarily talking about forwarding of packets here, I'm talking simply about the time it takes the far side interface to come back up over a SONET node; layer 1. Maybe this has nothing at all to do with SONET, I dunno :) It was gleaned that the next step might be to look at the SONET node and see if it's waiting 15 seconds to turn the laser back on or something. A 15 second wait before enabling the path is a good thing. Nothing worse than switch back to a path and experience a second down event (and thrid, forth etc.). If it's been up 15 secs, it probably is safe to use. -- Pelle RFC1925, truth 11: Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
At AMSIX, a Cisco 12000 running IOS will get into trouble with the 170pps of ND seen there. AMSIX doesn't do MLD snooping so everybody gets everything and on IOS 12000 ND is punted to RP and when it's busy with calculating BGP, it'll start dropping BGP sessions. Really? I've tried to duplicate the results in our lab, but I can't provoke any problems at those numbers. Is it the other multicast traffic that's interfering with ND? When pounding the CPU with ~30 times more (5000pps) Neighbour solicitations and flapping 1000 BGP IPv4 prefixes (out of 51000) every 5 seconds, I get the following load (worst case): 12k#sh proc cpu | ex 0.00 CPU utilization for five seconds: 99%/13%; one minute: 83%; five minutes: 76% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 29 19472 7944653 2 0.31% 0.07% 0.05% 0 PowerMgr Main 1605120 3415 1499 0.47% 0.18% 0.06% 0 Exec 181 17016 76522129 0 0.07% 0.14% 0.15% 0 CEF RP IPC Backg 185 1992892 19727573101 17.91% 19.36% 20.02% 0 IPv6 Input 213 256008 9155905 27 3.03% 2.80% 2.83% 0 BGP Router 216 3606044677600 5321 64.31% 45.74% 37.41% 0 BGP Scanner 12k# Even though the load is high, there is no flaps, neither in ISIS, LDP, BFD (3 sessions with 3 x 50 ms asynch mode) nor BGP. When BGP Scanner is not running, the numbers are much lower: martin#sh proc cpu | ex 0.00 CPU utilization for five seconds: 45%/16%; one minute: 82%; five minutes: 76% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1605192 3454 1503 0.79% 0.20% 0.08% 0 Exec 181 17068 76522593 0 0.15% 0.15% 0.15% 0 CEF RP IPC Backg 185 2000528 19764701101 24.79% 19.70% 20.01% 0 IPv6 Input 213 256976 9156110 28 3.03% 2.82% 2.83% 0 BGP Router martin# The hardware in question is a PRP-1 running SY9b, and the same LC (SIP-601/SPA-5x1GE-v2) is used for both ND and BGP. Note: When doing 1pps ND, the LDP-adjacency with a neighbour on the same LC did flap occasionally. -- Pelle RFC1925, truth 11: Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
Re: Another v6 question
Hi Owen. The downside is that it doesn't provide enough bits for certain kinds of auto-topology management that are being considered by CE vendors. I highly recommend /48 instead. I've seen this claim (you need a /48) from your side several times, but never seen any explanation why a /56 won't work. Is there any requirement that sub-delegations must happen on 8-bit boundaries? AFAICS there is at least nothing in the RFC. Wouldn't for example a nibble boundary work equally well (splitting a /56 into 16 /60s, each containing 16 /64s)? I don't challenge the claim, I'm just trying to understand the rationale behind it. -- Pelle RFC1925, truth 11: Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
Re: network name 101100010100110.net
Technically, no. But you probably fancy annoying people. I wouldn't imaging anyone typing that right on the first attempt. On 17 Oct 2010 06:47, Day Domes daydo...@gmail.com wrote: I have been tasked with coming up with a new name for are transit data network. I am thinking of using 101100010100110.net does anyone see any issues with this?
Re: P2P link over STM-1
If it's a full STM-1, your client might be thinking of POS (packet over sonet/sdh). This is (were) a very common high bandwidth technology some years ago. At least the 7200 do have cheap POS interfaces. -- Pelle (sorry about the top-posting, I'm on a mobile device)
Re: Vyatta as a BRAS
Is the CRS-1 hardware or software? Lots of custom hardware in there - but lots of processing cores that look suspiciously like software engines too. It might well be software engines in there, but that's not the point here. The linecards (MSC/PLIM etc.) in a CRS is designed to handle wirerate traffic *of any packet length* and simultaneously do ACLs, QoS or whatever else you throw at them. If that is done using FPGAs, CPUs or trained monkeys isn't really that interesting, as long as it works. And it does. But it won't come for free. A software-based router, i.e something equipped with a central CPU doing all heavy lifting, of *any kind* isn't designed to do that. The old corollary 7a in RFC1925 still make sense: Good, Fast, Cheap: Pick any two (you can't have all three). Some of the arguments expressed also vaguely resembles truth 11 in the same RFC: Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. There is a reason internet isn't built on Dell hardware... -- Pelle A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
