Re: Famous operational issues
On Fri, Feb 19, 2021 at 9:40 AM Warren Kumari wrote: > 4: Not too long after I started doing networking (and for the same small ISP > in Yonkers), I'm flying off to install a new customer. I (of course) think > that I'm hot stuff because I'm going to do the install, configure the router, > whee, look at me! Anyway, I don't want to check a bag, and so I stuff the > Cisco 2501 in a carryon bag, along with tools, etc (this was all pre-9/11!). > I'm going through security and the TSA[0] person opens my bag and pulls the > router out. "What's this?!" he asks. I politely tell him that it's a router. > He says it's not. I'm still thinking that I'm the new hotness, and so I tell > him in a somewhat condescending way that it is, and I know what I'm talking > about. He tells me that it's not a router, and is starting to get annoyed. I > explain using my "talking to a 5 year old" voice that it most certainly is a > router. He tells me that lying to airport security is a federal offense, and > starts looming at me. I adjust my attitude and start explaining that it's > like a computer and makes the Internet work. He gruffly hands me back the > router, I put it in my bag and scurry away. As I do so, I hear him telling > his colleague that it wasn't a router, and that he certainly knows what a > router is, because he does woodwork... OK, Warren, achievement unlocked. You've just made a network engineer to google 'router' P.S. I guess I'm obliged to tell a story if I respond to this thread...so... "Servers and the ice cream factory". Late spring/early summer in Moscow. The temperature above 30C (86°F). I worked for a local content provided. Aircons in our server room died, the technician ETA was 2 days ( I guess we were not the only ones with aircon problems). So we drove to the nearby ice cream factory and got *a lot* of dry ice. Then we have a roaster: every few hours one person took a deep breath, grabbed a box of dry ice, ran into the server room and emptied the box on top of the racks. The backup person was watching through the glass door - just in case, you know, ready to start the rescue operation. We (and the servers) survived till the technician arrived. And we had a lot of dry ice to cool the beer.. -- SY, Jen Linkova aka Furry
Re: ipv6 and geolocation
On Tue, Oct 22, 2013 at 9:16 PM, Blair Trosper blair.tros...@gmail.com wrote: Everyone loves IPv6, and it's a fantastic technology. However, I've been pondering a few quirks of v6, including the low priority of PTR, but I have a question I want to throw out there: Do you think IPv6 geolocatoin (GeoIP) will ever be viable? You might find this interesting: https://ripe67.ripe.net/presentations/324-self-published-geo_RIPE67.pdf http://tools.ietf.org/html/draft-google-self-published-geofeeds-02
Re: ISIS and OSPF together
On Sun, May 12, 2013 at 6:41 PM, Glen Kent glen.k...@gmail.com wrote: I would like to understand the scenarios wherein the service provider/network admin might run both ISIS and OSPF together inside their network. Is this something that really happens out there? One scenario that i can think of when somebody might run the 2 protocols ISIS and OSPF together for a brief period is when the admin is migrating from one IGP to the other. The other instance would be when say OSPF is used to manage the OOB network and the ISIS is used for network reachability. Is there any other scenario? There is still equipment around which doesn't support ISIS but support OSPF. Getting such boxes into a network which is using ISIS might lead to running both protocols together. -- SY, Jen Linkova aka Furry
Re: Juniper - Cisco IPv6 BGP peering
On Thu, Dec 8, 2011 at 8:54 AM, Randy Carpenter rcar...@network1.net wrote: When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. on second thought - why are they using link-local as the next-hop in the first place if the eBGP session is established over GUA? -- SY, Jen Linkova aka Furry
Re: Juniper - Cisco IPv6 BGP peering
On Sat, Dec 10, 2011 at 9:55 AM, Daniel Roesen d...@cluenet.de wrote: Any switch on the path? It is an L2 circuit that rides a couple of different pieces of gear before it lands at the other side. Sounds like this equipment having problems with IPv6 multicast... Yep, that's why I was asking - but it doesn't explain how/why ND for GUA works in this case. -- SY, Jen Linkova aka Furry
Re: Juniper - Cisco IPv6 BGP peering
On Thu, Dec 8, 2011 at 11:53 AM, Randy Carpenter rcar...@network1.net wrote: Tried that. I agree with others that it is an NDP issue. NDP for the GUA is fine, but just not for the link local. Is there something that would block only link local by default? I should add that I have another uplink to a different provider that works perfectly. The other end is Juniper for that one. Just to begin with: 0) Does your Juniper device have the neighbor cache entry for Cisco link-local address? What is the state of the entry? Can you get packet capture on both sides? 1) is Cisco sending NS packets? 2) is your Juniper receiving them? 3) is Juniper device sending anything back? 4) are those NA reaching Cisco? Any switch on the path? [lazy mode on] I'd also suggest: - debug ipv6 nd on cisco - checking for bugs for IOS and JunOS versions you are using On Dec 7, 2011, at 17:53, Peter Rubenstein peter...@gmail.com wrote: Try setting local-address in the bgp neighbor config on the Juniper side? --Peter On Dec 7, 2011, at 4:54 PM, Randy Carpenter rcar...@network1.net wrote: Does anyone have any suggestions on setting up BGP peering between Juniper (SRX) and Cisco? I successfully have cisco-cisco and juniper-juniper without problems. When I am trying to peer to one of my upstreams (who has cisco) with my Juniper SRX, They are seeing the link-local address as the next-hop, but are unable to get an ND entry for it, and thus cannot forward traffic to me. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 -- SY, Jen Linkova aka Furry
Re: First real-world SCADA attack in US
On Tue, Nov 22, 2011 at 8:35 AM, Mark Radabaugh m...@amplex.net wrote: Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention. This is a problem that doesn't really need a bunch of new legislation. It's an education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. I agree, it is mostly education and resources issue . But the environment of control networks is slightly different from IT industry, IMHO. 1) control network people have been living in a kind of isolation for too long and haven't realized that their networks are connected to Big Bad Internet (or at least intranet..) now so the threat model has changed completely. 2) There aren't many published cases of successful (or even unsuccessful) attacks on control networks. As a result, the risk of an attack is considered to have large potential loss and but *very* low probability of occurring and high cost of countermeasures = ignoring.. 3) Interconnections between control networks and normal LANs are a kind of grey area (especially taking into account that both types of networks are run by different teams of engineers). It is very hard to get any technical/security requirements etc - usually none of them exist. And as the whole system as as secure as the weakest element the result is easily predictable. 4) any changes in control network are to be done in much more conservative way. all those apply the patch..oh, damn, it crashed..rollback' doesn't work there. In addition (from my experience which might not be statistically reliable) the testing/lab resources are usually much more limited for control networks; 5) as the life cycle of hwsw is much longer than in IT industry, it is very hard to meet the security requirements w/o significant changes to existing control network (inc. procedures/policies) - but see #4 above.. So there is a gap - those control networks are 10 (20?) years behind internet in terms of security. This gap can be filled but not immediately. The good news that such stories as the one we are discussing could help scary the decision makers..oops, sorry, I was going to say 'raise the level of security awareness' -- SY, Jen Linkova aka Furry
Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24
On Sun, Sep 11, 2011 at 8:49 AM, Aftab Siddiqui aftab.siddi...@gmail.com wrote: with in the span of couple of hours this prefix was originated from 3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians). As per the STC it was orginated by one of their customer having Juniper router. but I still don't understand why/how they are adv this prefix with unrecog transitive attributes. For example, AS_CONFED_SEQUENCE and/or AS_CONFED_SET in AS4_PATH again..;( On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes richard.bar...@gmail.comwrote: Looks like the RIS collectors are seeing it originating mostly from STC and KACST ASNs: http://stat.ripe.net/212.118.142.0/24 Some of the show ip bgp reports on that screen are also showing AS8866 BTC-AS Bulgarian Telecommunication Company. Not sure what's up with that. --Richard On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren pixitha.k...@gmail.com wrote: Is this announcement still showing up this way (no easy way to check myself). ripe ris? -Kyle On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes chay...@centracomm.net wrote: On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) j...@probe-networks.de wrote: Hello, anyone else getting a route for 212.118.142.0/24 with invalid attributes? Seems this is (again) causing problems with some (older) routers/software. Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1 6-Resolve tree 2 AS path: 6453 39386 25019 I Unrecognized Attributes: 39 bytes AS path: Attr flags e0 code 80: 00 00 fd 88 40 01 01 02 40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05 04 00 00 00 64 Accepted Multipath -Jonas Yup! We're seeing the same thing too, and we're filtering it out. Originating AS is 25019 -Clay -- SY, Jen Linkova aka Furry
Re: IPv6 fc00::/7 — Unique local addresses
Hi Jeroen, On Thu, Oct 21, 2010 at 8:48 AM, Jeroen van Aart jer...@mompl.net wrote: According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an fc00::/7 address includes a 40-bit pseudo random number: fc00::/7 — Unique local addresses (ULA's) are intended for local communication. They are routable only within a set of cooperating sites (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing prefix intended to minimize the risk of conflicts if sites merge or packets are misrouted into the Internet. Despite the restricted, local usage of these addresses, their address scope is global, i.e. they are expected to be globally unique. I am trying to set up a local IPv6 network and am curious why all the examples I come accross do not seem to use the 40-bit pseudorandom number? What should I do? Use something like fd00::1234, or incorporate something like the interface's MAC address into the address? It'd make the address quite unreadable though. RFC4193 specifies a suggested algorithm to do it: http://tools.ietf.org/html/rfc4193#section-3.2.2 The section 3.2.1 also states that Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is a high probability of uniqueness. I'm not sure where did you find the examples you've mentioned. If it's just a documentation example - seems to be fine. If someone is doing it in real networks - that's just not right.. -- SY, Jen Linkova aka Furry
Re: Strange practices?
Hi, On Tue, Jun 8, 2010 at 6:50 AM, Dale Cornman bstym...@gmail.com wrote: Has anyone ever heard of a multi-homed enterprise not running bgp with either of 2 providers, but instead, each provider statically routes a block to their common customer and also each originates this block in BGP? One of the ISP's in this case owns the block and has even provided a letter of authorization to the other, allowing them to announce it in BGP as well. I had personally never heard of this and am curious if this is a common practice I have seen it quite often. It allows an enterprise to be multihomed w/o getting PI or PA address space so they are usually pretty happy with it. as well as if this would potentially create any problems by 2 Autonomous Systems both originating the same prefix. AFAIR prefixes can be originated by more than one AS so there shouldn't be any issues. -- SY, Jen Linkova aka Furry
