- NANOG - lists.nanog.org

Re: 2nd try: YANG daemeon for Linux
by Karl Jørn 26 Jul '18

26 Jul '18

Anyone ? Found this but i am not sure if this is going to go public or not : https://packetpushers.net/new-network-os-startup-arrcus-targets-whitebox-sw… Danke, Karl On Fri, Jul 20, 2018 at 12:30 PM, Karl Jørn <karljorn787(a)gmail.com> wrote: > Hi > > Is there a YANG daemeon for Linux ? If yes, can any one please share their > experiences ? > > Danke, > Karl >

1 0

Godaddy Contact needed for routing issue
by Erik Sundberg 26 Jul '18

26 Jul '18

Hello, Can someone from GoDaddy's routing team contact me off list. We have customer's unable to reach www.cat5cableguys.com<http://www.cat5cableguys.com> via the Equinix Chicago - Internet Exchange. #traceroute www.cat5cableguy.com Wed Jul 25 16:47:08.266 CDT Type escape sequence to abort. Tracing the route to 184.168.221.11 1 ge-0-0-0-8.ar1.chi1.us.nitelusa.net (207.200.195.173) 22 msec 21 msec 21 msec 2 eqix-ch.godaddy.com (208.115.136.141) 22 msec 22 msec 21 msec 3 * * * 4 * * * 5 * * * This website is reachable over other carrier's just not Equinix Chicago - Internet Exchange. Thanks Erik ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

2 1

Equinix SV8 Peering fabric flooded since 1:45PM PST
by Peter Kranz 25 Jul '18

25 Jul '18

Since around 1:45PM PST today we've been receiving a constant 10Gbps of flooding from the SV8 peering fabric. Traffic is not in the VLAN 6 peering VLAN so I haven't peeked at it. Anyone else seeing this at that exchange? Peter Kranz www.UnwiredLtd.com <http://www.unwiredltd.com/> Desk: 510-868-1614 x100 Mobile: 510-207-0000 pkranz(a)unwiredltd.com <mailto:pkranz@unwiredltd.com>

1 0

Re: using expect to log into devices
by Scott Weeks 25 Jul '18

25 Jul '18

--- valdis.kletnieks(a)vt.edu wrote: From: valdis.kletnieks(a)vt.edu On Sun, 22 Jul 2018 00:43:35 +0200, Niels Bakker said: > Fine as a personal exercise, of course. The inability to download > modules seems sadistic to me, though. And given the adage "Never create a rule you can't enforce", I wonder how they enforce it - have to be pretty hardcore to make sure that stuff doesn't get imported via USB or tethering off a cellphone. (Or more correctly, I know how they do those sort of things if you're a spook agency or doing classified research - how do you make it palatable to employees in corporate sites?) ------------------------------------------------- It's not corporate and believe me, they enforce it... ;-) scott

3 2

Finally some common sense - No to blocking DNS
by Jacques Latour 25 Jul '18

25 Jul '18

This is good news for the internet up here! It's unconstitutional to block DNS access!!! JF must be happy :) https://www.theglobeandmail.com/canada/article-court-rejects-quebecs-bid-to… Court rejects Quebec's bid to ban citizens' access to private online gaming sites THE CANADIAN PRESS PUBLISHED JULY 24, 2018UPDATED 18 HOURS AGO Quebec's attempt to ban its citizens' access to online gaming websites unauthorized by the state-run gambling corporation is unconstitutional because it infringes upon federal jurisdiction, indicated a recent Superior Court ruling.......

2 1

AS205869, AS57166: Featured Hijacker of the Month, July, 2018
by Ronald F. Guilmette 25 Jul '18

25 Jul '18

Before I get into talking about this month's honorary Hijacker of the Month, I really must start by thanking everyone who pitched in and helped to insure an appropriate response and outcome for the BitCanal case, which I reported here last month. You all know who you are, and I won't explicitly name you here, only because most of you have expressed to me privately that you would prefer it if I didn't. But you folks deserve the lion's share of the credit, and I, in contrast, played only the most minor supporting role. I must also say that I was astonished and very pleasantly surprised by the very effective and, to-date, very nearly 100% effective response to my call to action with respect to Bitcanal. This thief, Joao Silveira, aka Mr. Bitcanal, and his business are still limping along, and, I'm sure, trying desperately to get back online after everybody with half a brain became convinced of what he has been up to for lo these past several years. He's apparently managed to at least get his main web site (www.bitcanal.com) back online, but now he's totally dependent on GoDaddy hosting for that. :-) I guess that he doesn't have a whole lot of IP space to call his own anymore, or any least not very much of it that he can actually get anyone to route for him. I should also offer my apologies for the rather deliberately rude way that I got right up into the faces of Cogent, GTT, and Level3, right here on the NANOG list, with regards to BitCanal. I see now that that was really rather completely unfair and uncalled for. All three took swift and appropriate action once they became fully aware of the issue/problem, and I am grateful to all of them for their prompt action, and also, of course, I am equally grateful also to the many other providers and IXes who also took appropriate action in this case. Following my posting last month about BitCanal, at least one person rightly took me to task for the rude way I approached the problem, and even moreso for the fact that I escalated the problem to this list as my first response to the whole issue. With 20/20 hindsight, I can now only agree with those criticisms. I shouldn't have done that. I am pleased with the final result, i.e. Bitcanal being kicked from essentially the whole Internet, but the ends do not justify the rather hamfisted means I elected to employ. I will try to do better in future. With that in mind, when I recently found another such operation... another entity performing an entire set of obviously very deliberate hijacks, evidently for the purpose of leasing the hijacked space to snowshoe spammers... I took what I had learned from the BitCanal case and applied it. In particular, rather than me having a very public tantrum and getting on the cases of each and every company that bgp.he.net said might be connected to the hijacker somehow, I instead began by running traceroutes to all of the relevant hijacked blocks. (If I would have had the good sense to have done this in the BitCanal case, I most probably would have begun by just hasseling Cogent alone, and privately, off list, since from where I sit, all of the traceroutes to all the blocks that Bitcvanal stole had Cogent as the next-to-last hop. YMMV) Anyway, in this new case I found that the next-to-last hop for all of the relevant traceroutes was a set of routers belonging to Telecom Italia. Rather than calling them out here, this time I had the good sense to just message TelecomItalia directly about the issue. it took me a couple of tries, but I was eventually able to find a proper contact address for a proper sort of person to discuss this matter with @ Telecom Italia. The two links below are (1) my message to them and (2) their very nice and proactive response back to me: Me -> Telecom Italia https://pastebin.com/raw/Ek3mxKCR Telecom Italia -> Me https://pastebin.com/raw/mtcA4Ehy Given that I sent my message to them well after business hours on Friday, I consider their response, sent on Monday, to be super-fast and very responsive. Of course, I am absolutely ecstatic also that they have elected to stop all routing to the particular bunch of of badness that I explicitly called out to them, at least for the time being. As you can all see, my message to TelecomItalia describes the issue/problem with AS205869 - Universal IP Solution Corp. in some considerable detail. In a nutshell, these guys are criminals and they've been reselling the IPv4 space they've hijacked, specifically but perhaps not only to snowshoe spammers. (Specific evidence available upon request.) Of course, one can easily imagine even vastly worse uses that may be made of stolen IP space. By the time that I personally became aware of what these specific jerks were up to, they had already used, abused, and tossed aside several other IPv4 blocks -and- also a number of other previously abandoned ASNs. (They have been absconding with -both- abandoned IPv4 address blocks -and- also a number of previously abandoned ASNs... as well as one that was/is in active use by its legitimate owner. And they have bee doing so without any apparent restraint watever.) The evidence of all this is crystal clear from a quick review of all of the relevant RIPE records. They left their bloody fingerprints all over this mess. Anyway, by the time I noticed them. late last week, the set of routes and ASNs that this particular set of crooks were still fradulently using were as follows: ASN Route ---------------------- 10510 216.238.64.0/18 10737 207.183.96.0/20 10800 192.110.32.0/19 19529 104.143.112.0/20 19529 198.14.0.0/20 19529 198.32.208.0/20 19529 206.41.128.0/20 30237 192.73.128.0/20 30237 192.73.144.0/20 30237 192.73.160.0/20 30237 192.73.176.0/20 (The above list was present also in my private message to TelecomItalia. See link above.) I suspect that perhaps the fact that the final four routes in the list above are for IPv4 space which is formally registered to the United States Air Force may possibly have contributed somewhat to TelecomItalia's apparent readiness and willingness to take swift and decisive action in this case. (It's not every day that you see USAF IP space being routed by mysterious Ukranian networks. :-) In any case, as I've noted above, I am greatly pleased that TelecomItalia took the action it did, regardless of what factors may have entered into their decision. At this point in my presentation, anyone who might have been expecting another "call to arms", like my posting here last month, will be disappointed. I'd greatly appreciate it if readers of this post would help me to to confirm that the non-routing of the above block is both universal and complete... as it is, at least, from where I am sitting... but at this point I have nothing and nobody to rail against. (Or so I thought! But while writing this post I found some new and apparently associated curiosities relating to a different ASN, AS57166. Read on!) So, anyway with regards to AS205869... case closed? Is it Miller time? Well, yes and no. There's still the question of just who or what the devil is this thing called Universal IP Solution Corp. (which also, apparently, goes by the name of "ADMASTER-MNT" within RIPE WHOIS records). And then there is the question of what there is to prevent these hijackers from just coming back tomorrow under a different guise or corporate identity and starting the game all over again. Even more worrying is the distinct possibility that they may not even find it necessary to change out their current corporate identity before getting back into the game. They could just keep their current name... as BitCanal did... and try to reroute their connectivity via one of their other existing peers. The (ostensible) list of those is shown here: https://bgp.he.net/AS205869#_peers These crooks may have already anticipated the small setback of losing their TelecomItalia connection, and as you can see, they already have nine listed IPv4 peers, although at least four of these are provably ones that they themselves have been masquerading as, specifically: AS11717 Solarus AS7827 American Business Information AS11324 BRFHH Shreveport, LLC AS32226 Menard, Inc. The above ASNs have all been hijacked by the folks using the handle ADMASTER-MNT. The RIPE WHOIS records essentially prove that. (Menard, Inc., by the way, is a chain of retail home improvement stores, comparable to HomeDepot, located in the U.S. MidWest region. Hardly the kind of place you'd expect to be peering with mysterious Ukranian company, -or- to be indirectly routing space... 216.238.64.0/18... for a long-dead Pennsylvania ISP such as Razor, Inc. The case of BRFHH Shreveport, LLC is arguably more worrying than any of the rest of this, because in that case the hijackers apparently didn't even care that the ASN in question was still in active use by its rightful owners, uhsystem.com, which appears to be a University-based hospital in Louisiana. HIPPA horrors easily imaginable!) Anyway, eliminating the ASNs above, we are still left with multiple possible "Plan Bs" for this hijacking operation: AS6762 Telecom Italia <============== plug already pulled AS8359 MTS PJSC (Russia) AS1299 Telia Company AB (Sweden) AS35320 Eurotranstelecom Ltd. (Ukraine) AS57166 D2 International Investment Ukraine Ltd. Now that Telecom Italia has pulled the plug, I'll be emailing to the other peers listed above, and asking them to do likewise. We'll just have to wait and see what they do. But there is one ASN from the above list that I quite definitely -won't- be sending any emails to, and that's the last one, D2 International Investment Ukraine Ltd. AS57166, D2 International Investment Ukraine Ltd. was a name already known to me. It came up previously, right here on this mailing list, in the context of a discussion I had started here on October 5th, 2016 relating to a previous set of hijacks that I had reported here: https://mailman.nanog.org/pipermail/nanog/2016-October/088487.html This thing, whetever it is, has/had a peering relationship, both then and now, with AS29632 Netassist Limited, which is headquartered in... ummm... Ukraine. No. Wait. Make that Gibraltar. Anyway, we'll come back to that a bit latter on. Back in the day, D2 International Investment Ukraine Ltd. was using two different ASNs, i.e. AS43659 and AS57166. As of now, it doesn't seem to be using the former for much of anything: https://bgp.he.net/AS43659 AS57166 is a rather different story however. The listing of IPv4 peers shown currently at bgp.he.net (https://bgp.he.net/AS57166#_peers) shows the following as current peers of AS57166: AS205869 Universal IP Solution Corp. AS29632 Netassist Limited AS11695 TheStreet.Com AS8011 CoreComm Internet Services Inc The first two are (or were) headquartered in Ukraine, so other than the fact that Universal IP Solution Corp. is hip deep in IP address space thievery, those two are unremarkable as peers for D2 International Investment Ukraine Ltd. which is also allegedly located in Ukraine. That third one should come as a bit of a shock to anyone who has ever had the privlege (or misfortune, depending on your point of view) of watching "Mr. Booyah" Jim Cramer attempts to make the muundane world of stock trading entertaining for the masses. TheStreet.com is a highly popular web destination belonging to a company of the same name which was founded by the same said Mr. Jim Cramer. From Wikipedia: TheStreet, Inc. is an American financial news and services website founded by Jim Cramer and Martin Peretz. How does a company like this get mixed up with a bunch of Ukranians of dubious repute?? Well, quite simply they don't. The ASN has been hijacked by AS57166 -- D2 International Investment Ukraine Ltd. As we speak, D2 International Investment Ukraine Ltd. is using this hijacked ASN, AS11695 -- TheStreet.Com for an ongoing set of hijacks, mostly of abandoned legacy IPv4 space belonging to various defunct U.S. companies, but with one Canadian block (69.171.160.0/19) and one Mongolian block (192.82.64.0/19) mixed in just to give this portfolio of hijacks a bit of an international flavor, I suppose. The list of blocks currently announced by AS11695, according to stat.ripe.net, is as follows: 24.137.0.0/20 24.137.0.0/19 24.137.16.0/20 24.236.0.0/19 52.128.192.0/19 66.219.64.0/19 68.232.96.0/20 69.171.160.0/19 70.34.192.0/20 70.34.192.0/19 70.34.208.0/20 98.143.176.0/20 163.123.192.0/20 163.123.192.0/18 163.123.208.0/20 163.123.224.0/20 163.123.240.0/20 192.82.64.0/19 192.254.32.0/19 198.40.192.0/19 204.195.192.0/18 206.15.32.0/19 206.54.128.0/20 206.125.0.0/19 206.127.224.0/19 206.190.160.0/19 206.222.128.0/19 206.246.32.0/19 207.183.64.0/19 209.182.0.0/20 209.182.0.0/18 209.182.16.0/20 209.182.32.0/20 209.182.48.0/20 This is quite an impressive list, even if it does fall a bit short of the recent and slightly more prodigious escapades of Bitcanal. I've run a few traceroutes on a few of the above routes and I've found them to have next-to-last hops within the same batch of Telcom Italia routers as were being used by the batch of hijacks that were easily tracable back to AS205869 - Universal IP Solution Corp. Not a real huge surprise there. AS205869 is peering with AS57166 and vise versa. They are both quite obviously working together on this grand hijacking scheme. Of course, I will shortly be initiating another friendly and, I hope, equally productive chat with my new friend @ Telecom Italia regarding these additional blatant and obvious hijacks. I have so far neglected to mention the forth and final peer of AS57166, i.e. AS8011 -- CoreComm Internet Services Inc. Based on my reading of he relevant RIPE records, this ASN appears to have been registered with RIPE on or about 2017-01-12 by whoever was in control of the RIPE handle "DATASTAR-MNT" as of that date. It appears to me that, with a few exceptions, such as the RIPE WHOIS record for this ASN, pretty much everything else that has been created and installed into the RIPE WHOIS data base by "DATASTAR-MNT" is fundamentally fradulent. Here is the full list of such stuff: https://pastebin.com/raw/DQbWe0gq By extension from this premise, I think that it may be reasonably assumed that any routes currently being announced by AS8011 are most likely also hijacks. As of now, this seems to be limited to only one single route: 216.127.0.0/19. This IPv4 block would seem to have been yet another abandoned IPv4 block that was just left lying around, and which has now been very effectively repurposed in service of the hijackers' preferred ends. Finally, as some may have noted, there is one rather glaring hole in the story it has been presented above, specifically, the true and verifiable identities of the hijackers, which remain cloaked in mystery. D2 International Investment Ukraine Ltd. historically used the domain name etthua.net as part of its contact email address, but that domain currently has no DNS, and data from archives suggests that it may have never had a functioning web site. RIPE NCC undoubtedly has the name of some specific individual to go along with this corporate front name, but even before the advent of the travesty that is GDPR, they almost certainly would refuse to divulge that to any party, based on their traditional strict contractual code of omerta. A page on virustotal seems to suggest a connection of some sort between D2 International Investment Ukraine Ltd. and the now notorious coinhive scam, but it is not at all clear how this connection was derived or even whether there actually is any real connection at all: https://www.virustotal.com/#/ip-address/94.130.90.152 Googling now, I see that I myself called out this crooked enterprise on a RIPE mailing list back on 2016-10-08. (I didn't really remember doing that, as it has been nearly 2 years ago now.) https://www.ripe.net/participate/mail/forum/anti-abuse-wg/PDMxNjk3LjE0NzU5N… I also have no specific recollection of this follow-up post by a rather outspoked fellow who goes by the name of Marilson, and who has frequently appeared to drink even substantially more coffee than I do: https://lists.ripe.net/pipermail/anti-abuse-wg/2016-October/003726.html I myself have no direct knowledge of the "Samuel Joel Nirushan" that Marilson spoke of, or about any of Mr. Marilson's specific allegations against him (including that this Mr. Nirushan is even connected in any way to D2 International Investment Ukraine Ltd.) but I did find that if one simply googles for "Samuel Joel Nirushan" or alternatively, for "D2 International Investments" (note: plural, rather than singular) one quickly comes upon a plethora of public postings made by -somebody- who was apparently quite angry at this guy, many most or all of which seem to date from October, 2011, and all of which contain many of the same unsubstantiated allegations of fradulent activities. As these allegations are not accompanied by any relevant documentation, then must be judged to only be worth even less that the electrons they were written on. Arguably more relevant is this archived RIPE WHOIS record that I found online and which appears to show that D2 International Investment Ukraine Ltd. was formerly granted a sub-allocation of IPv4 space which, at that time, and also currently, is registered to NetAssist, Ltd (Ukraine): https://pastebin.com/raw/95LRyvwv This, taken together with the fact that NetAssist, Ltd (AS57166) is currently peering with AS57166 - D2 International Investment Ukraine Ltd., ertainly suggest a strong business relationship between the Netassist and D2, whatever the hell it is. Returning briefly to the other obviously crooked actor in this drama, i.e. AS205869 - Universal IP Solution Corp., it is worth mentioning that this company, like D2 International Investment, also has a domain that is used as part of its contact email address, universalipsolution.bz (BZ -- Belize??) but this domain also, like etthua.net for D2, does not currently have any web site, and based on my reading of historical passive DNS data, it appears that it may have -never- have had one. Nontheless, both D2 International Investments and Universal IP Solution are both members in good standing of RIPE: https://www.ripe.net/membership/indices/data/ua.d2investukraine.html https://www.ripe.net/membership/indices/data/bz.universal.html So, you know, one wonders how these two crooked companies that are clearly colluding together to hijack lots and lots of IP space are then able to somehow turn around and make a profit by selling off bits and pieces of what they have stolen when neither of them even have any web site via which they could entice eager buyers of their stolen property. This is an enigma, but I have a theory that seems at least possible. RIPE provides many useful services to its members, but there is one in particular that I personally have become acquainted with only quite recently. RIPE NCC apparently maintains a list of what they call "Recognised IPv4 Transfer Brokers": https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/bro… As noted on the above page "there are no costs involved" in being admitted to this prestigious and exclusive club, "...however, you will need to agree to adhere to the relevant RIPE Policies and RIPE NCC procedural documents..." >From these public statements of the RIPE web site I infer that as long as one can fog a mirror, and as long as one is willing and able to raise one's right hand and swear on some sort of religious text, one can be and will be admitted into this special club of "recognised" IP brokers. One company listed on the above page that caught my eye is NetAssist LLC, formerly of Ukraine, but more recently re-incorporated in the jurisdiction of Gibraltar. (Why the company elected to up and change jurisdictions is not immediately obvious.) Whereas neither Universal IP Solution Corp. nor their apparent partners in crime, D2 International Investment Ukraine Ltd. have any web sites, and whereas they both thus have no apparent means of easily reselling/ offloading/fencing any or all of the IP space that the two of them together have stolen, it appears that D2's friend and peer, NetAssist LLC, is already well positioned to barter blocks of IPv4 space that may have unexpectedly gone walkabout. This is not to say that they have done so. I have no direct evidence of that. I just personally find NetAssist's formal registration, with RIPE, as an "recognized" IP broker to be a possibly relevant detail, and one that may perhaps be exceptionally convenient, under the curcumstances. Plesse note that Bitcanal, using its full, formal, and legal name of Ebonyhorizon Telecomunicacoes Lda., is also still a member in good standing of not only RIPE, but also of RIPE's cadre of "Recognised IPv4 Transfer Brokers". (See link above.) To reiterate, I have posted all of this information here on the NANOG list, not as a call to action... I'll be trying myself to contact any and all relevant providers and encouraging them to take appropriate action... but rather just because I felt that people here on this list might want to at least be aware of all of these convoluted shenanigans and schemes. Certainly, I encourage everyone reading this to be extra vigilant, in future, and especially if you are approached in the near future by any Ukrainian (or Gibraltarian) networks requesting peering. Regards, rfg P.S. It is left as an exercise for the reader as to why these sorts of large scale hijacking schemes always seem to originate somewhere within the RIPE geographical region and never elsewhere.

7 9

Definition/Classification of Bogon
by Aftab Siddiqui 25 Jul '18

25 Jul '18

Hi Everyone, Just wanted to understand something about Bogons. As per RFC3871 - A "Bogon" (plural: "bogons") is a packet with an IP source address in an address block not yet allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC...) as well as all addresses reserved for private or special use by RFCs. See [RFC3330] and [RFC1918]. Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but what about unallocated ASNs? Q - Is there any RFC (or even draft) which classify unallocated ASNs as Bogon as well? Additionally, Geoff Huston [1] explained all the possible classifications of "Bogon" in his blog post back in 2004 --> "Sometimes a bogon is just a case of keystroke error by a network operator, and the consequent bogons are entirely inadvertent, and other times it may be a disagreement between an end user and a registration authority" Q - In the above scenario when an RIR deregister a resource (IPv4/v6 or ASN) due to any disagreement (sometimes deregistration happens because of non-payment and can be resolved in a few days/weeks). How long should a service provider wait to mark them as bogon and stop advertising or accepting it? [1] - http://www.potaroo.net/ispcol/2004-04/2004-04-isp.htm

4 5

Re: using expect to log into devices
by Scott Weeks 25 Jul '18

25 Jul '18

Was out. Late reply... --- niels=nanog(a)bakker.net wrote: From: Niels Bakker <niels=nanog(a)bakker.net> * surfer(a)mauigateway.com (Scott Weeks) [Sat 21 Jul 2018, 22:38 CEST]: >I had already done this in PERL, but, even though we have PERL, we >are not allowed to download modules here. So, I'm redoing it in >Expect. I thought someone would say a "oh just <blah, blah> and >you're done" type of response. Well, what you're doing right here is reimplementing rancid. Which is wholly unnecessary because we already have rancid, and a more modern alternative named oxidized. And you've gotten that response already. Fine as a personal exercise, of course. The inability to download modules seems sadistic to me, though. -------------------------------------------------- It IS sadistic and I don't have a choice. Can't use rancid, either. Thus my comment of $next-job and personal exercise in prep for that. But, while I'm here I want something non-GUI I can use without losing my mind. scott

1 0

Question about bird RS config with BGP Community support
by Anurag Bhatia 24 Jul '18

24 Jul '18

Hello, We are running a small IX fabric (in Mumbai, India) and with multiple route servers based on a bird. There has been a demand of support of BGP communities from some of our members and I am trying to find a way to set it up in the bird. Idea is to provide a community say 0:123 where tagged routes with 0:123 do not reach AS123. I am new to the bird. Tried testing with config given here - https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base… and that results in no announcement peer where the route is going out. (No specific comms even used. Just applying the export config results in a drop of the route announcement). I also tried other config example given over there for putting routes of each peer in their table (as per https://gitlab.labs.nic.cz/labs/bird/wikis/Route_server_with_community_base…) and behaviour is same. No route announcement to peers. Was wondering if anyone can point to right config to support BGP communities? Thanks! -- Anurag Bhatia anuragbhatia.com

3 4

SP security knowledge build up
by Ramy Hashish 24 Jul '18

24 Jul '18

Hello All, I am planning to build up a security team of fresh engineers whom are "network oriented", any advice on the knowledge resources we can start with? We are looking forward to building a concrete foundation of a well-rounded security engineer, we are looking for vendor/operator agnostic resources. Thanks, Ramy

8 9