Re: Standard DC rack rail distance, front to back question
On Thu, Apr 27, 2023 at 9:53 AM Chuck Church wrote: > for a Cisco ASA1001, there aren’t rails, but rather front and back ‘ears’ > you use to hit both front and back posts. > Front *and* back ears? I'm not sure what an ASA 1001 is (ASR?) but my experience with these boxes is that they have a single pair of ears which can be mounted front OR back. The heavier / deeper 1RU devices do tend to sag alarmingly. > Is there a ‘standard’ distance between front and back rails that devices > usually adhere to? > If you're thinking of setting the front/back distance to accommodate a specific device, table 2 might be of some interest: https://i.dell.com/sites/doccontent/business/solutions/engineering-docs/en/Documents/rail-rack-matrix.pdf
Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis
On Mon, Aug 5, 2019 at 11:38 AM Nicolas Chabbey wrote: > > Are there any good reasons of using proprietary FHRPs like HSRP and GLBP > over VRRP ? HSRP has an potential advantage over VRRP in that HSRP speakers keep track of groups (virtual gateway clusters) in which they do not participate. The distinction could matter in a configuration where the routers all participate in dynamic routing and might be generating ICMP redirects to steer host traffic toward routers in different groups. A VRRP router will redirect the client traffic toward the physical interface of a (failure-prone) physical router (the redirect matches the sending router's routing table). An HSRP router recognizes that the preferred next-hop is participating in an HSRP group, so it redirects the client traffic toward the VIP associated with that group, rather than the physical router's interface. Since these redirects result in something akin to a static route in the host device, it's safer to have that route pointing at a virtual gateway than a physical interface. You could easily convince me that any access LAN including multiple routers participating in different FHRP groups is due for a redesign, so this distinction might be moot. But I think it's a neat subtlety. /chris
Re: Console Servers & Cellular Providers
Lots of references to static IPs from cellular providers for OoB access in this thread. Why? It seems like a dial-home scheme is an obvious solution here, whether it's Opengear's Lighthouse product, openvpn, or whatever... Do you all have a security directive that demands whitelisted IP addresses? I've got a handful of OoB systems that dial home via cellular, but only after they've been poked by SMS. Opengear's auto-response facilitates that, and I've done it with EEM (to start DMVPN) on Cisco ISRs. The main headache I've run into is that it's tough to get a SIM card from ATT that does data and SMS: ATT's M2M plans don't allow SMS, and moving the SIM from an iPhone to "a computer" causes the SMS capability to vanish. My ATT OoB boxes (used only where Verizon is reported to not work) are online all the time.
Re: Marriott wifi blocking
On Sat, Oct 4, 2014 at 2:47 PM, Jay Ashworth wrote: > > - Original Message - > > From: "Chris Marget" > > > You [I] said: > > > > > It is OK for an enterprise wifi system to make this sort of attack > > > *on rogue APs which are trying to pretend to be part of it (same ESSID). > > > > I'm curious to hear how you'd rationalize containing a copycat AP > > under the current rules. > > > > > > The "need to manage our RF space" arguments ring hollow to me. I certainly > > understand why someone would *want* to manage the spectrum, but that's > > just not anyone's privilege when using ISM bands. If the need is great > > enough, get some licensed spectrum and manage that. > > I wasn't making that argument. Yes, sorry. I presented two arguments. Only the one about copycat SSIDs is yours. > I was making the "if someone tries to pretend to be part of my network, > so that my users will inadvertantly attach to them and possibly leak > 'classified' data, *then that rogue user is making a 1030 attack on my > network*. > > > A copycat AP is unquestionably hostile, and likely interfering with users, > > but I'm unconvinced that the hostility triggers a privilege to attack it > > under part 15 rules. In addition to not being allowed to interfere, we also > > have: > > You're not attacking it, per se; you are defensively disconnecting from > it *users who are part of your own network*; these are endpoints *you are > administratively allowed to exert control over*, from my viewpoint. Okay, so we're not talking about wholesale containment of the copycat AP, but rather management of our own client devices which, by definition, we can't interfere with. Because they're ours. That approach sounds perfectly reasonable. I wonder, absent certificates, how one can be certain about the identity of the client, and if such a narrowly scoped containment mechanism is actually implemented by the various checkboxes available to enterprise wifi administrators. > I make a clear distinction (now that it's not 3am :-) between what Marriott > is doing, and what enterprises doing rogue protection are doing, as noted > above. Is it clear exactly what "enterprises going rogue protection" are up to? I've asked several, gotten wildly different answers. Keeping "my clients" off "copycat APs" sounds reasonable. More aggressive action might not be. Thanks.
Re: Cisco Nexus
There are some unfortunate limitations in classifying incoming traffic. It's been a while, but I think the rule is that Nexus 2000 devices can only classify based on incoming 802.1p cos values. It's a pretty strange and disappointing limitation for an edge device where you're less likely to have incoming dot1q tags and you're less likely to trust the other end of the link to mark its own traffic. /chris
PMTUD for IPv4 Multicast - How?
I recently discovered that my routers weren't generating ICMP Type 3 Code 4 (unreachable, DF-bit) messages in response to too-big IPv4 multicast packets with DF=1. At first, I thought this was a bug, but then learned that RFCs 1112, 1122 and 1812 all specify that ICMP unreachables not be sent in response to multicast packets. RFC1981 (PMTUD for IPv6), on the other hand, is explicit that PMTUD works for multicast flows, that the path MTU for a multicast flow is the smallest MTU available anywhere in the distribution tree, and that a single multicast packet may provoke many ICMP unreachables from routers along the tree. Further complicating matters, the default Linux behavior (ip_no_pmtu_disc = 0) sets the DF bit on all packets unless the application is explicit (setsockopt()) that DF be cleared. This behavior strikes me as a troublesome assumption (that the application will interpret unreachables) in the case of unicast UDP sockets, and downright broken (because traffic will be dropped silently) in the case of multicast UDP sockets. I'm struggling to grok the rationale behind not sending unreachables in response to multicast packets. It seems to me that our networks put IPv4 multicast speakers in a position where it's impossible for them to do the right thing. Does anybody understand why PMTUD for IPv4 multicast flows is disabled in routers? Is there a secret lever to enable it in Cisco IOS? What should a responsible IPv4 multicast application do when receivers are flung far and wide with un-knowable MTUs in the transit path? Thanks, /chris
Re: PMTUD for IPv4 Multicast - How?
On Mon, Aug 31, 2015 at 12:37 PM, wrote: > On Mon, 31 Aug 2015 12:12:16 -0400, Chris Marget said: > > > At first, I thought this was a bug, but then learned that RFCs 1112, 1122 > > and 1812 all specify that ICMP unreachables not be sent in response to > > multicast packets. > > > I'm struggling to grok the rationale behind not sending unreachables in > > response to multicast packets. It seems to me that our networks put IPv4 > > multicast speakers in a position where it's impossible for them to do the > > right thing. > > For the exact same reason that replying to an ICMP Echo Request sent to > your broadcast address is generally considered a Bad Idea. > > The obvious solution is "Doctor, it hurts when I do that" "Don't do that > anymore". > It's not as obvious to me as it is to you. I mean, v6 *requires* exactly this behavior, so it can't be all that bad, can it? > Don't send multicast packets with DF set. > Are you asserting that the default behavior of the Linux kernel (setting DF on multicast packets) is wrong then? I'll probably come around, but I've not yet concluded that "screw it, fragment my traffic, I don't care" is the stance that a conscientious application should be taking. /chris
Re: PMTUD for IPv4 Multicast - How?
>> I'll probably come around, but I've not yet concluded that "screw it, >> fragment my traffic, I don't care" is the stance that a conscientious >> application should be taking. > > Don't you care, for routers, generating ICMP PTB is as burdensome > as generating fragments? I don't think so. If PMTUD is working (big IF, I know), the ICMP PTB generation is a one-time thing (or once per 10 minutes or whatever) and can be rate limited with little impact. Fragmenting transit traffic, on the other hand, needs to be done for every transit packet.
Re: PMTUD for IPv4 Multicast - How?
> > It's not as obvious to me as it is to you. I mean, v6 *requires* exactly > > this behavior, so it can't be all that bad, can it? > > ICMP replies to multicast packets can cause ICMP "implosion". This is > not a new discussion - see for instance > > http://mailman.nanog.org/pipermail/nanog/2012-June/048685.html Thanks very much for the pointer to that discussion. "ICMP implosion" has been a helpful search term. The position taken there appears to boil down to: - The IPv6 requirement to generate "too big" messages *really is a problem* - RFC2463 should not have made the exception which allows sending these messages - Multicast PMTUD should not be a thing - Multicast speakers should send un-fragmentable minimum-sized packets I remain fuzzy on exactly the nature of the implosion problem. Is the concern that I might DDoS myself by sending un-fragmentable traffic? It's hard for me to recognize this as a problem, but I'm working on it. It seems to me that as a multicast speaker, the influx of ICMP errors is both desirable (I set DF because I intend to react) and under my control. It certainly beats sending minimum-sized packets, which appears to be the recommendation in the linked discussion. If somebody would be so kind as to detail the disastrous nature of the implosion, that would be helpful.
Re: PMTUD for IPv4 Multicast - How?
On Mon, Aug 31, 2015 at 8:55 PM, Masataka Ohta wrote: > Chris Marget wrote: >>>> I'll probably come around, but I've not yet concluded that "screw it, >>>> fragment my traffic, I don't care" is the stance that a conscientious >>>> application should be taking. >>> >>> Don't you care, for routers, generating ICMP PTB is as burdensome >>> as generating fragments? >> >> I don't think so. If PMTUD is working (big IF, I know), > > Yup. > >> the ICMP PTB >> generation is a one-time thing (or once per 10 minutes or whatever) > > A meaningful interval of retry is not 10 minutes but RTT measured > at layer 4 or above. I took the 10 minute value from RFC1191's recommendation about when it's appropriate to try larger MTU sizes. One ICMP message should hold the sender off for 10 minutes (or whatever), just like it does with unicast traffic. Would you explain why a router might need to generate ICMP PTB at a rate corresponding to intervals of RTT? I don't see why the error rate would be correlated with path length. Anyway, RTT isn't something that necessarily exists with multicast applications. >> Is the concern that I might DDoS myself > > Or, with spoofed source addresses, someone else. The latter concern isn't unique to this case and applies to many (most? all?) types of reflection attacks. Indeed, many other protocols have disabled potentially useful features in order to thwart reflection attacks which rely on spoofed source addresses. At least in the case of those protocols, we have the choice to enable monlist, ip_respond_to_echo_broadcast or whatever as appropriate for the environment. I'm still not sure where this leaves the application which wants to do the right thing. - Send 1500 byte frames and expect fragmentation? - Guess at the least of all likely path MTUs? - Send 576 byte frames? - Build a feedback mechanism into the application?
Re: Multiple Spanning Tree Instance 0
On Wed, Feb 25, 2015 at 4:09 PM, Graham Johnston wrote: > We are planning a migration from Rapid PVST+ to Multiple Spanning Tree to > better support a mixed vendor environment. My question today is about MST > Instance 0. In practice do you map any VLANs there other than VLAN 1? I'd hoped to see some responses to this thread because I recently had some awkward moments with a vendor after discovering that their switch wouldn't allow me to map VLANs to STP instances in an arbitrary manner. I took the position that the implementation was faulty, their position was more along the lines of "Well, why would you want to do that anyway?" Addressing the question directly, I know of two switching platforms which force the operator to map VLANs other than 1 into instance 0. Some Broadcom FASTPATH based platforms fail to mention VLAN 4094 in any 'show spanning-tree' commands, but always maps it to instance 0. The implementation of MST available on Cumulus Linux only supports instance 0, maps all VLANs there. My Cumulus experience is a bit dated, this may have changed in the last year. /chris
Re: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking FLOKsociety.org by accident or on purpose?
200.10.150.169 is reachable from AS2828 and from AS20115, but not from AS22394 (Verizon Wireless) On Fri, Oct 4, 2013 at 12:28 PM, Brandon Galbraith < brandon.galbra...@gmail.com> wrote: > Site appears up and available, over Comcast Business fiber and Cogent from > Chicago (using Chrome 28). > > > On Fri, Oct 4, 2013 at 11:17 AM, Matthew Huff wrote: > > > My traceroute goes through, but we don't go through Verizon. However, the > > web server is returning an error that it is unavailable. It's possible > that > > the destination web server has a geo location plug in that stops access > > from foreign locations, or that their server is down. > > > > > > > > [root@lancaster ~]# traceroute -I 200.10.150.169 > > traceroute to 200.10.150.169 (200.10.150.169), 30 hops max, 40 byte > packets > > 1 129.77.108.252 (129.77.108.252) 0.345 ms 0.384 ms 0.442 ms > > 2 switch-user1.ox.com (129.77.154.253) 0.408 ms 0.523 ms 0.585 ms > > 3 rtr-inet2.ox.com (129.77.1.252) 3.394 ms 3.437 ms 3.464 ms > > 4 129.77.3.254 (129.77.3.254) 0.515 ms 0.517 ms 0.541 ms > > 5 189d20f9.cst.lightpath.net (24.157.32.249) 4.909 ms 4.923 ms > 4.922 > > ms > > 6 18267502.cst.lightpath.net (24.38.117.2) 7.318 ms 9.900 ms 9.889 > ms > > 7 (69.74.203.201) 9.877 ms 9.444 ms 9.434 ms > > 8 * * * > > 9 adsl-065-015-003-181.sip.mia.bellsouth.net (65.15.3.181) 9.455 ms > * * > > 10 * * * > > 11 xe-9-1-2.edge2.Newark1.Level3.net (4.31.45.173) 8.378 ms 14.395 ms > > 14.244 ms > > 12 ae-32-52.ebr2.Newark1.Level3.net (4.69.156.62) 39.992 ms 42.318 ms > > 42.303 ms > > 13 ae-4-4.ebr2.Washington1.Level3.net (4.69.132.101) 42.283 ms 42.284 > > ms 42.280 ms > > 14 ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 50.599 ms > > 50.594 ms 50.586 ms > > 15 ae-61-61.ebr1.washington1.level3.net (4.69.134.129) 40.769 ms > > 43.276 ms * > > 16 ae-2-2.ebr3.atlanta2.level3.net (4.69.132.85) 43.293 ms 39.230 ms > > 38.957 ms > > 17 ae-73-73.ebr2.Atlanta2.Level3.net (4.69.148.254) 38.942 ms 38.942 > > ms 38.501 ms > > 18 ae-2-2.ebr2.miami1.level3.net (4.69.140.141) 39.404 ms 37.772 ms > > 37.487 ms > > 19 ae-2-52.edge1.Miami2.Level3.net (4.69.138.107) 50.685 ms 50.674 ms > > 50.568 ms > > 20 telefonica.edge1.miami2.level3.net (4.71.212.118) 62.446 ms 60.038 > > ms 59.416 ms > > 21 176.52.251.189 (176.52.251.189) 57.850 ms 58.637 ms 58.541 ms > > 22 176.52.252.66 (176.52.252.66) 94.381 ms 97.548 ms 99.258 ms > > 23 * * * > > 24 * * * > > 25 * * * > > 26 host-186-5-116-193.telconet.net (186.5.116.193) 118.811 ms 118.803 > > ms 118.808 ms > > 27 host-186-101-89-42.telconet.net (186.101.89.42) 98.612 ms 98.589 > ms > > 98.605 ms > > 28 200.10.150.169 (200.10.150.169) 98.534 ms 98.564 ms 98.505 ms > > > > dig +short www.floksociety.org. > > 200.10.150.169 > > > > telnet 200.10.150.169 80 > > Trying 200.10.150.169... > > Connected to 200.10.150.169. > > Escape character is '^]'. > > GET / HTTP/1.0 > > > > HTTP/1.1 503 Service Unavailable > > Server: Varnish > > Content-Type: text/html; charset=utf-8 > > Retry-After: 5 > > Content-Length: 418 > > Accept-Ranges: bytes > > Date: Fri, 04 Oct 2013 16:12:33 GMT > > Connection: close > > > > > > > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > > > > > > 503 Service Unavailable > > > > > > Error 503 Service Unavailable > > Service Unavailable > > Guru Meditation: > > XID: 477990820 > > > > Varnish cache server > > > > > > Connection to 200.10.150.169 closed by foreign host. > > > > > -Original Message- > > > From: Gordon Cook [mailto:c...@cookreport.com] > > > Sent: Friday, October 04, 2013 12:10 PM > > > To: nanog@nanog.org list > > > Subject: verizon trouble ticket NJ DQ04PWR9 -- is verizon blocking > > FLOKsociety.org by > > > accident or on purpose? > > > > > > > > > Dear NANOG > > > > > > The Ecuadoran government has via the FLOK society hired Michel Bauwens > > of the P2p > > > foundation to lead a two year long efforts to revision the ecudoran > > economy along the > > > lines of a commons oriented collaborative society. I am very > interested > > in the program > > > yet i have NEVER been able to connect to their web site. At the end > of > > two hours of > > > trouble shooting with apple i was advised to call verizon. I am a FiOS > > customer on a two > > > year contact. The traceroute below confirmed that the fault is in > > verizons network. The > > > verizon tech agreed otherwise i never would have gotten the trouble > > ticket > > > > > > my verizon trouble ticket is NJ DQ04PWR9. > > > > > > Can someone tell me what number to call to pursue resolution of this > > trouble ticket? > > > > > > as of 12:04 eastern time i still cannot connect > > > > > > 24 hours was the promise > > > 14 of the 24 have elapsed > > > > > > > traceroute to floksociety.org (200.10.150.169), 64 hops max, 72 byte > > packets > > > > 1 192.168.1.1 (192.168.1.1) 0
