|
Powercrazy posted:Change miles to meters and this is correct. 1m = 5ns propagation delay, 300km = 3ms delay. Serialization should be insignificant at at 1Gb. -edit- Whoops this was round trip, madsushi below has 1 way figures ragzilla fucked around with this message at 23:26 on Aug 15, 2013 |
#
?
Aug 15, 2013 23:23
|
|
|
|
| # ? May 28, 2024 18:05 |
|
|
Bluecobra posted:I am not sure why you think such a short run would have that latency. This is the host-to-host round-trip latency on one of our 1Gb DWDM circuits between two data centers that is 50 miles apart: Speed of light is about 300 km/ms in a vacuum, or 200 km/ms in fiber, which would mean 600km for 3ms of latency, which is like 370 miles.
|
|
#
?
Aug 15, 2013 23:24
|
|
|
Yea I messed up my units. Should have said kilometers. Anyway, short answer is simulating latency is hard to do, especially at Gbps or greater.
|
|
#
?
Aug 15, 2013 23:45
|
|
|
Bluecobra posted:I am not sure why you think such a short run would have that latency. This is the host-to-host round-trip latency on one of our 1Gb DWDM circuits between two data centers that is 50 miles apart:
|
|
#
?
Aug 16, 2013 00:27
|
|
|
Bluecobra posted:I am not sure why you think such a short run would have that latency. This is the host-to-host round-trip latency on one of our 1Gb DWDM circuits between two data centers that is 50 miles apart: lol here is 2.1km (10Ge DF) code:nzspambot fucked around with this message at 01:38 on Aug 16, 2013 |
|
#
?
Aug 16, 2013 01:35
|
|
|
Bluecobra posted:I am not sure why you think such a short run would have that latency. This is the host-to-host round-trip latency on one of our 1Gb DWDM circuits between two data centers that is 50 miles apart: I hope your DR policy doesn't say 50mi, because that's only ~46mi based on .7224ms rtt 361.2us one way latency, ~204m/us @ 1.4682 refractive index (smf-28) = 73684m or 45.79mi. Probably even less than that even due to ser/deser time (minimal), switching latency (who knows), and time for the hosts to respond/process. nzspambot if you're pinging the switch instead of a host, you're going to get bad results from the slow processor in it.
|
|
#
?
Aug 16, 2013 02:29
|
|
|
|
|
#
?
Aug 16, 2013 02:34
|
|
|
ragzilla posted:
I get the same results from pinging each hop along the way (switch -> FW -> VM) nzspambot fucked around with this message at 03:42 on Aug 16, 2013 |
|
#
?
Aug 16, 2013 03:40
|
|
|
ragzilla posted:I hope your DR policy doesn't say 50mi, because that's only ~46mi based on .7224ms rtt That's probably correct. The driving directions are about ~37 miles apart so I just rounded up to 50 miles. Also, the switch latency isn't that bad. The host on one end is plugged into a Force10 S4810 which is about 900ns, and the other end is plugged into a 6509 w/Sup 720 with PFC3 (about 20 microseconds) and that is in turned plugged into another S4810 with 900ns latency.
|
|
#
?
Aug 16, 2013 04:15
|
|
|
Anyone wanting to work with Multicast on a Nexus 5k running L3 would be better off shooting themselves in the face than attempting to dig through the damned caveats to find all the wonderful oops that can happen when PIM interacts with vPC. Jesus christ..... Honestly Cisco if you don't want people to run L3 on the 5ks, stop loving selling the solution.
|
|
#
?
Aug 16, 2013 22:39
|
|
|
5ks are poo poo.
|
|
#
?
Aug 17, 2013 00:30
|
|
|
Does anyone have any Notepad++ or Sublime Text (or any) Cisco syntax highlighting files? I have been using one designed a long time ago, and doesn't seem to cover any of the NX-OS commands and only like 50% of the IOS commands. Anyone have a user-defined language file to share?
|
|
#
?
Aug 17, 2013 00:46
|
|
|
madsushi posted:Does anyone have any Notepad++ or Sublime Text (or any) Cisco syntax highlighting files? I have been using one designed a long time ago, and doesn't seem to cover any of the NX-OS commands and only like 50% of the IOS commands. Anyone have a user-defined language file to share? I made one, but it doesn't have NX-OS and was designed around my personal color theme, so probably doesn't work well. But sure! I'll grab it Monday.
|
|
#
?
Aug 17, 2013 05:39
|
|
|
Flash z0rdon posted:5ks are poo poo. We love ours (layer 2 for life)
|
|
#
?
Aug 17, 2013 14:12
|
|
|
Flash z0rdon posted:5ks are poo poo. They're decent access layer devices since you can get FC and ethernet in one box. Layer 3 on them is horrible though.
|
|
#
?
Aug 17, 2013 19:12
|
|
|
1000101 posted:They're decent access layer devices since you can get FC and ethernet in one box. Oh yeah forgot about this.  Storage likes them.
|
|
#
?
Aug 17, 2013 19:47
|
|
|
adorai posted:We love ours (layer 2 for life) Yep, we said gently caress layer 3 on ours. Been great
|
|
#
?
Aug 17, 2013 21:27
|
|
|
1000101 posted:They're decent access layer devices since you can get FC and ethernet in one box. Layer 3 on them is horrible though. Why is there such a huge push to put layer 3 on switches? (or higher?)
|
|
#
?
Aug 18, 2013 00:50
|
|
|
CrazyLittle posted:Why is there such a huge push to put layer 3 on switches? (or higher?) Wire speed is faster. Can depend on your network design. If you have an rear end-ton of VLANs, something has to provide layer 3 between.
|
|
#
?
Aug 18, 2013 02:46
|
|
|
adorai posted:We love ours (layer 2 for life) Yeah never had any problems here either. If you want layer 3 services, don't use a switch designed for layer 2. abigserve fucked around with this message at 11:03 on Aug 18, 2013 |
|
#
?
Aug 18, 2013 11:00
|
|
|
Tasty Wheat posted:Wire speed is faster. Can depend on your network design. If you have an rear end-ton of VLANs, something has to provide layer 3 between.
|
|
#
?
Aug 18, 2013 16:22
|
|
|
adorai posted:We use vyatta in VMware trunked to a pair of Nexus 5k switches. It routes 10gbe no problem. Best of all, it's free. Yeah, that's pretty much what I'm getting at. Shame on me for not saying it outright, but why is there a push to put layer 3 on a switch when a router can handle those tasks better?
|
|
#
?
Aug 18, 2013 19:49
|
|
|
CrazyLittle posted:Yeah, that's pretty much what I'm getting at. Shame on me for not saying it outright, but why is there a push to put layer 3 on a switch when a router can handle those tasks better? What do you mean push? Layer 3 has been on switches for ages.
|
|
#
?
Aug 19, 2013 02:54
|
|
|
The basic reason is you don't want to purchase additional hardware. If you've got some nexuses already, the simplest design would be to use them to route as well instead of buying at least one 6500 (two if you need redundancy). Knowledge of the product of course, tells us that this can be tricky. I should also mention I've never heard of any issue with L3 routing on the nexus platform unless VPC is involved somewhere - i.e a N7K with dual everything's seems to handle all the standard L3 tasks fine. This is of course not taking into account HPC style solutions where it's a routed edge to get around spanning-tree issues (I'm looking at you, extreme),
|
|
#
?
Aug 19, 2013 03:27
|
|
|
For low levels of unicast traffic the 5k is ok, but start mixing vPC, multicast, and any failover routing and you've got an RPF check powderkeg waiting to explode in your face. I've used them multiple times for small scale routing at edge sites where I was looking for a L2/3 switch with fiber channel capabilities. Worked great for that.
|
|
#
?
Aug 19, 2013 03:37
|
|
|
ruro posted:What do you mean push? Layer 3 has been on switches for ages. I'm not seeing the added value of duct-taping a lackluster routing feature onto the side of a decent wire-speed switch. Sure I get running routing logic on power switches with routing processor cards, but trying to do BGP/OSPF for 100mbit of traffic on a 3750? Why not just use the switch as a switch and use a router to route traffic?
|
|
#
?
Aug 19, 2013 04:28
|
|
|
abigserve posted:The basic reason is you don't want to purchase additional hardware. If you've got some nexuses already, the simplest design would be to use them to route as well instead of buying at least one 6500 (two if you need redundancy). I'm doing routed-edge designs a lot more frequently now coupled with VXLAN. Bit of the best of both worlds and can keep the VMware people happy. edit: clarity
|
|
#
?
Aug 19, 2013 06:11
|
|
|
CrazyLittle posted:I'm not seeing the added value of duct-taping a lackluster routing feature onto the side of a decent wire-speed switch. Sure I get running routing logic on power switches with routing processor cards, but trying to do BGP/OSPF for 100mbit of traffic on a 3750? Why not just use the switch as a switch and use a router to route traffic?
|
|
#
?
Aug 19, 2013 14:47
|
|
|
Man, now that I have a cursory understanding of IPv6 from studying for the 640-816 exam, I want to be some sort of "IPv6 is the way of the future!" evangelist. Pretty cool system, that.
|
|
#
?
Aug 19, 2013 14:53
|
|
|
CrazyLittle posted:I'm not seeing the added value of duct-taping a lackluster routing feature onto the side of a decent wire-speed switch. Sure I get running routing logic on power switches with routing processor cards, but trying to do BGP/OSPF for 100mbit of traffic on a 3750? Why not just use the switch as a switch and use a router to route traffic? What? The 3750 does L3 just as fast as it does L2. However the control-plane/fib wont scale as high as a 'real' router. Not really a problem unless you are clueless and try to put a full BGP table on it.
|
|
#
?
Aug 19, 2013 15:06
|
|
|
QPZIL posted:"IPv6 is the way of the future!" Join us in the
|
|
#
?
Aug 19, 2013 15:10
|
|
|
QPZIL posted:Man, now that I have a cursory understanding of IPv6 from studying for the 640-816 exam, I want to be some sort of "IPv6 is the way of the future!" evangelist. Should have capped it at a 64 bit address space, max. 48 is even better. There's a reason or two its been sitting for what 10 years? I know we need all the IP4 bolt-ons to be integrated but gently caress, say 2 to the 128'th in english. Overkill in my opinion.
|
|
#
?
Aug 19, 2013 15:34
|
|
|
Why would it be better to cap it at 64 or 48 bits instead of 128? The whole point was to make it such a large address space that we'd never have to deal with the address exhaustion problem again, at least on this planet. Also, it allows for some cool features like mapping a 48-bit MAC address into the 64-bit host portion for auto-addressing within a subnet. You couldn't do that as easily with a 64 or 48 bit address.
|
|
#
?
Aug 19, 2013 15:42
|
|
|
Here is the answer to the problem: compute the exponential expression: 2 to the 64th 2 to the 64th = 18446744073709551616, that is to say 18,446,744,073,709,551,616 is read in English as: "eighteen quintillion, four hundred fourty-six quadrillion, seven hundred fourty-four trillion, seventy-four billion, seven hundred nine million, five hundred fifty-one thousand, six hundred sixteen." e: Oh yah, and a loopback address that doesn't consume an entire 'class A' net. Herv fucked around with this message at 16:22 on Aug 19, 2013 |
|
#
?
Aug 19, 2013 16:13
|
|
|
SamDabbers posted:Why would it be better to cap it at 64 or 48 bits instead of 128? The whole point was to make it such a large address space that we'd never have to deal with the address exhaustion problem again, at least on this planet. Also, it allows for some cool features like mapping a 48-bit MAC address into the 64-bit host portion for auto-addressing within a subnet. You couldn't do that as easily with a 64 or 48 bit address. There are two main reasons for wanting a shorter address space. The first is entirely human. Most of us who deal with a lot of IPs end up remembering a bunch of them. An IPv4 address is pretty easy in that way, it's only slightly more complicated than a phone number and nicely grouped. This also helps in communicating them via speech, be it in person, over the phone, etc. IPv6 pretty much makes DNS a requirement for meatbag-friendly operation. I mean just think about 10.0.0.15 vs. fd00:0000:0000::15. IPv6 addresses don't really get simpler than that and can be a lot more complex. Technically since those two sets are all zeros they can also be compacted in to the ::, but officially the fd00::/8 range is supposed to have all those zeroes as 40 bits of random, so you'd legitimately need to remember at least the amount I listed in most cases. That said, it's not like being forced to do DNS right is truly a bad thing, but to those who have been happily doing without for years it can be a challenge to deal with. The second is routers. Big routers use specialized chips for everything to do things as fast as they do. Those chips only have so much memory, as in some cases the kind of memory best suited for the job is expensive. More address space = more routes to deal with = greater memory requirements = greater cost. Multiply that by the scale of large providers and its not hard to see why so many have waited until the absolute last minute to do anything. edit: This should not be taken as me arguing against IPv6 or it being 128 bits, I really don't care what the answer is as long the end result gets NAT the gently caress out of my life. Since IPv6 is currently the only viable option for that, even with its arguable "flaws" I have to support it. edit2: Now that I'm not at a customer site that blocks Wiki, here's a link for anyone interested in the expensive memory in big routers/switches: http://en.wikipedia.org/wiki/Content-addressable_memory Basically it's memory that the CPU can ask "is this value here?" rather than having to search the entire thing looking for it. Herv posted:Yep, even if we have 6 octets in an 'IP v7 address' the first 5 would stay rather static, with a padded out mask. That's thinking about it in a rather narrow way. Obviously private addresses will stay rather boring in general, but I only used those for the direct comparison with as simple of an address as they get. The internal-only addresses I used really don't have much of a point for most users in IPv6, link-local is already there for local communication and its so easy to get more IPv6 space than you'd ever need so any actual managed IPv6 networks should usually be using the real stuff unless it will absolutely never ever need internet connectivity. For a more real-world comparison, how about google.com, which returns 74.125.225.67 (among others) for IPv4 but 2607:f8b0:4009:803::1000 for IPv6. Neither are "padded out", but the IPv6 one is a lot less human-friendly. Regarding the number of addresses, keep in mind that a large chunk of IPv4 space is "wasted" due to the logistics of routing traffic in logical ways without blowing up routing tables (see TCAM problem above). IPv6 will be the same way, so having more addresses than we could ever need multiple times over allows the space to be divided in logical ways while still practically guaranteeing that we won't find ourselves 15 years down the road with some new space crunch requiring us to start the whole process over again. Since memory chips and memory buses tend to have power-of-two sizes/widths, 64 and 128 are the two logical steps up from 32 bits. Why not 64 bit then? My best guess is something to do with wanting to be able to use the 48 bit MAC address as a supposedly unique number for automatic addressing schemes, but that's just a thought off the top of my head and not based in any actual knowledge. wolrah fucked around with this message at 21:49 on Aug 19, 2013 |
|
#
?
Aug 19, 2013 16:30
|
|
|
Yep, even if we have 6 octets in an 'IP v7 address' the first 5 would stay rather static, with a padded out mask. 10.10.10.10.10.200 (Host) 255.255.255.255.255.0 (Mask) 10.10.10.10.10.254 (GW) That gives us a measly 281 Trillion address (2 to the 48th) to squeeze by with until we develop whatever the gently caress we use in 50 years.  Still standing by my 48 bit proposal. I read DNS and Bind in the 90's but still... gently caress 128 bits in it's ear for a technical solution. I want IPv7 with a 48 bit address field.
|
|
#
?
Aug 19, 2013 16:54
|
|
|
Are any of you running MetroE through AT&T in the DC area? I'm trying to get a general idea of pricing, but their website is very coy and I'm not allowed to talk to sales because I'm a contractor. e: We already have an ingress, which I know makes a big difference. psydude fucked around with this message at 19:29 on Aug 19, 2013 |
|
#
?
Aug 19, 2013 19:27
|
|
|
psydude posted:I'm not allowed to talk to sales because I'm a contractor. What?!@! DoD would never buy anything if I wasn't allowed to talk pricing with vendors.
|
|
#
?
Aug 19, 2013 19:42
|
|
|
wolrah posted:There are two main reasons for wanting a shorter address space.  . The internal draft IPv6 addressing standard they have where I work at the moment is easier for me to remember than the IPv4 standard as there are sufficient 'fields' to use for pertinent information, e.g.: <routing prefix>:site/cust id:building:level:level-net:host or <routing prefix>:dc num:cust id:cust-net:device-type:host.TCAM/CAM utilisation may be an issue for service providers, but I'd be surprised if that was an issue for anybody else.
|
|
#
?
Aug 19, 2013 22:51
|
|
|
|
| # ? May 28, 2024 18:05 |
|
|
wolrah posted:
Believe it or not, we used to not NAT. I was using a 10 net for the ubiquity. What's probably clouding my judgement is that I have been at this for about 20 years, so I was a first hand witness to the bitness getting over allocated. I wouldn't call myself a Network Engineer these days. I'm just an old fart IT Director that used to be a Network Engineer. The first time I was asked to do NAT was in '96 or so, on a 'PIX Classic' that was already in production. It was firewalling (ok, ok, packet filtering) but not NAT'ing. There were publicly routable addresses to the desktops, and this was for a MS Gold Partner. It was the same at Bell Labs in the 90's too (6500 folks, one huge facility, PC and a SPARC on each desktop... where I cut my teeth thank god), routable addresses, but not NAT'd. It seems like everything has been crafted around address exhaustion since the late 90's and for good reason. OK, all bitness aside, how efficient do you see the skeleton to usable IP addresses play out? 50 percent loss to the network addressing vs host addresses? Take my 48 and 64 bit fields and split them up however inefficient you want to get, that's still some BIG math waiting for us to fill up. Keep routable addressing, but lose the NAT. 140 Trillion for 48, 14 Quintillion for 64 bits. Every house gets a fuggin Class A net (I know classes are deprecated looong ago) Having said that, the issue of all the bolt-ons have to be addressed (poo poo) but once again, RFC1918 was based on exhaustion no? e: Added the cut in half metrics for 48 and 64 bits. Herv fucked around with this message at 23:16 on Aug 19, 2013 |
|
#
?
Aug 19, 2013 22:52
|
|