When we started planning a VMware NSX-focused podcast episode with Dmitri Kalintsev, I asked my readers what topics they’d like to see covered. Two comments that we really liked were “how do I get started with VMware NSX?” and “how do I troubleshoot this stuff?”

Read more ...

Juniper does it again.

We are back after the Christmas Break with the Networking News.

Guest blogger Alex Hoff is the VP of Product Management at Auvik Networks, a cloud-based SaaS that makes it dramatically easier for small and mid-sized businesses to manage their networks. Our thanks to Auvik for sponsoring the Packet Pushers community blog today. It’s January and the network industry pundits are calling for 2015 to be the […]

Author information

The post SDN: What Small and Mid-Sized Businesses Need to Know in 2015 appeared first on Packet Pushers Podcast and was written by Sponsored Blog Posts.

Time for another annual roundup from the world of IP addresses. What happened in 2014 and what is likely to happen in 2015? This is an update to the reports prepared at the same time in previous years, so lets see what has changed in the past 12 months in addressing the Internet, and look at how IP address allocation information can inform us of the changing nature of the network itself.

As network security engineers have attempted to categorize blocks of IP addresses associated with spam or malware for subsequent filtering at their firewalls, the bad guys have had to evolve to continue to target their victims.  Since routing on the global Internet is based entirely on trust, it’s relatively easy to commandeer IP address space that belongs to someone else.  In other words, if the bad guys’ IP space is blocked, well then they can just steal someone else’s and continue on as before.

In an attempt to cover their tracks, these criminals will sometimes originate routes using autonomous system numbers (ASNs) that they don’t own either.  In one of the cases described below, perpetrators hijacked the victim’s ASN to originate IP address space that could have plausibly been originated by the victim.  However, in this case, the traffic was misdirected to the bad guy and an unsophisticated routing analysis would have probably shown nothing amiss.

The weakness of all spoofing techniques is that, at some point, the routes cross over from the fabricated to the legitimate Internet — and, when they do, they appear quite anomalous when compared against historical data and derived business relationships and markets, a key data source for our products like Dyn’s IP Transit Intelligence.

In this blog post, I review six examples of entities with bogus routing announcements within the past few months—some of which are ongoing—and I discuss some possible remedies in the conclusions. These examples help to illustrate a few things.  First, these are not isolated incidents.  These bogus routes are being circulated at a near constant rate and many separate entities are engaged in this practice, although with subtle differences in approach.  Second, these techniques aren’t solely for the (relatively benign) purpose of sending spam.  Some of this host address space is known to circulate malware.

Finally, these techniques offer the perpetrator the ability to communicate on the Internet without revealing his or her true source.  Security analysts should proceed with extreme caution when using IP addresses as identifiers of a bad actor.  In a world where routing hijacking is becoming increasingly common, IP addresses are simply not reliable for attribution.

And with that introduction, I present the following six sources of bogus routing on the Internet.

Case 1: Petersburg Internet Network (AS44050)

The IP-squatting operation I mentioned on the NANOG list back in August has continued unabated into the New Year.  Not surprisingly, the ASNs have changed since I noted the last change on this blog in September.  The latest format for their bogus routes is as follows:

... 44050 131788 198596 (hijacked prefix)


Also new is the fact that the Romanian AS198596 is now being legitimately utilized in Romania and since December 17^th has been getting transit from Romanian ISPs Dial Telecom (AS6910) and Teen Telecom (AS34304) — yes, that’s their actual name.

A couple of weeks ago, the IP-squatters in Saint Petersburg, Russia hijacked routed address space of the Italian National Institute of Nuclear Physics (Istituto Nazionale di Fisica Nucleare), a popular target of theirs.  Pictured below are the timelines of AS198596’s originations of 192.135.33.0/24 and 192.84.129.0/24, which are more-specific hijacks of 192.135.32.0/23 and 192.84.128.0/20, respectively — both normally originated by AS137 (GARR, the Italian Research & Education Network).

90% of our peers see hijacks from AS198596 across AS adjacency 174_39792, namely, Cogent’s transit service (AS174) for its customer Anders Telecom (AS39792). If Cogent started blocking routes from the Petersburg Internet Network Ltd.(AS44050) until they clean up their act, it might save everyone a lot of hassles.

This is because those brief hijacks coming from AS198596 aren’t the only sketchy thing coming through the Petersburg Internet Network (AS44050) these days. Since December 5^th, AS44050 has also been transiting routes from Medix Direct (AS263171): 179.60.128.0/20 and 200.59.208.0/20, which is ostensibly Panamanian address space (commercial geolocation providers take note). This address space hosts hundreds of suspicious mail domains likely used for spam generation such as

mx01.mx.addediam.net. mail.mx.adenteam.net. mx01.mx.adipoinc.net. mx01.mx.afterero.net. mail.mx.aleniter.net. mail.mx.algomico.net.

mail.mx.altigalt.net. mail.mx.alunicsc.net. mx01.mx.amblippe.net. mail.mx.amesiati.net. mail.mx.anadilet.net. mx01.mx.analodyn.net.

mx01.mx.ancystor.net. mail.mx.angentvi.net. mail.mx.annabuse.net. mx01.mx.apelleye.net. mail.mx.aprionet.net. mail.mx.arcotell.net.

mail.mx.areconsi.net. mail.mx.asquirin.net. mx01.mx.ateliell.net. mail.mx.athawker.net. mx01.mx.auctiont.net. (and many more)

Prior to appearing out of Saint Petersburg, Russia in early December, this AS and its prefixes were transited by Petersburg Internet Network USA (AS54985) in Florida. However, AS54985 and its transit relationship to Level 3 (AS3356) vanished on October 27^th of last year.

Additionally, from December 12^th to January 16^th, AS44050’s customer AS201593 (Technologii svyazi, LLC) originated a prefix (192.72.27.0/24) which was a more-specific hijack of 192.72.16.0/20 — a prefix originated by Digital United (AS4780) out of Taiwan. And starting January 8^th, another AS44050 customer, namely, Trast Ltd. (AS198747) has been very briefly announcing various ranges of unused IP address space such as 103.17.148.0/22 (Dougenzaka, JP), 196.43.200.0/24 (Sybaweb Internet, ZA), and 203.19.233.0/24 (Chinanet, CN), pictured below.

 

 

While all this makes AS44050 perhaps the leading contender for being named the Mos Eisley of the Internet, it isn’t the only candidate.

Case 2: Bitcanal (AS197426)

Then there is Bitcanal (AS197426) of Portugal, which we mentioned in September as an outfit announcing the address space of the State Attorney General of Texas (206.218.64.0/22), as well as unused Syrian address space (95.212.192.0/18).  They have kept busy routing suspicious routes in the months since.

In the past couple of weeks, AS197426 gained a new downstream customer, AS18254, which routes a lot of address space from Asia.  For several days it announced more-specific hijacks of routes typically announced by Tata’s domestic ASN, AS4755.

115.116.98.0/24 and 115.116.99.0/24 were also routed in a similar manner and were hijacks of routed Indian address space.  To someone familiar with BGP routing, it might seem odd that these routes were only seen by about 40% of our BGP sources.  Given that they are more-specifics, it would be reasonable to expect global propagation.  However, a quick analysis of AS paths reveals that for these prefixes, AS197426 didn’t announce them to its transit providers, namely, NTT (AS2914), Colt (AS8220), Level 3 (AS3549) and Refer Telecom (AS29003).  It only announced them to peers, allowing for more limited propagation and non-corrupt paths out to its transit providers.

More recently, Bitcanal gained a new customer with very similar proclivities towards hijacking IP space (both routed and unrouted): Indonesian AS 24196 (PT Global Cibubur Access).  Over the course of four days in the past week, AS24196 announced several suspicious routes, including 61.80.160.0/20 (a more-specific hijack of 61.80.0.0/14, originated by Korea Telecom, AS4766) and 27.110.80.0/20 (unused address space registered to an organization in Kuching, Malaysia) pictured below. Like the routes originating from AS18254, these prefixes were only announced through Bitcanal’s peers and not their transit providers resulting more limited propagation.

Other routes originated by AS24196 in the past week include:

27.111.224.0/20 Equinix Singapore Pte Ltd Singapore
58.181.96.0/20  Pakistan Telecommuication company limited Karachi
103.237.0.0/20  Asia Pacific Network Information Centre
103.48.48.0/20  Asia Pacific Network Information Centre


Case 3: H3S median services (AS59790), Sky Capital Investments Ltd. (AS201509), Marcel Edler (AS197043), Andreas Sebastian Fahl (AS197890)

Unlike the examples above, this group generally prefers to briefly announce unrouted AfriNIC address space, such as some recent route originations depicted below by AS59790.

However, squatting on unused African IP address space isn’t all AS59790 does.  It also hijacks IP address space of major US carriers as well.  In November, it routed unused IP address space from AT&T and a more-specific hijack of Comcast’s 73.0.0.0/8 route.

In December, a downstream ASN of AS59790 appeared for a few days (AS201509, Sky Capital Investments Ltd) and began announcing some of the same bogus routes that AS59790 had been announcing.  It was ostensibly passing these routes through AS59790 in the following form.

… 174 59790 201509 {hijacked prefix}

AS201509 only existed downstream of AS59790 from 14 — 27 December 2014.  Then, on December 27^th, it reappeared announcing more bogus African routes through AS197043 (Marcel Edler), an ASN with a well established reputation for circulating malware.  In fact, Google’s Safe Browsing diagnostic page for AS197043 states that it hosted “content that resulted in malicious software being downloaded and installed without user consent” and that “this network has hosted sites that have distributed malicious software in the past 90 days”. AS201509 then disappeared on 6 January.

Since then, Andreas Sebastian Fahl (AS197890) began briefly announcing this unused AfriNIC address space, albeit through AS197043 (Marcel Edler) to a much smaller set of providers.

Case 4: Business Torg (AS60937)

I’m not the only one to encounter AS60937 circulating some suspicious routes. On and off for several weeks last year, they announced 12 prefixes along an unlikely AS path:

… 60937 12389 16509 6461 1273 {prefixes}

This sequence would suggest that AS1273 (Cable & Wireless, now Vodafone) was originating these routes, passing them to AS6461 (Abovenet), then to Amazon (AS16509), Rostelecom (AS12389), Business Torg (AS60937) and on to those who were peering with AS60937.  Two of the routes were hijacks of routed address space, shown in red below.

Several others were squatting on unused IP address space:

Also announced in a similar manner were the following ranges of unrouted IP address space:

200.236.64.0/18 (Axtel, MX) 187.191.128.0/17 (Axtel, MX) 201.162.128.0/17 (Pegaso PCS, MX) 201.161.64.0/18 (Triara.com, MX)

41.209.128.0/18 (AfriNIC Ltd) 196.49.128.0/17 (AfriNIC Ltd) 197.158.128.0/18 (Microlink Technologies Ltd, ZM) 177.190.0.0/18 (Datora Telecomunicações, BR)

Of course, AS1273 never really originated these prefixes.  Otherwise, we would have seen more sensible AS paths for them — not one whose sequence requires us to believe that Amazon (AS16509) is leaking these routes from Abovenet to Rostelecom only.  This case illustrates how difficult it can be to assign reputations to ASNs, since AS paths seen in routing announcements are easily manipulated.  If AS1273 were tagged as an unsafe ASN as a result of these forged paths, would the world then start blocking legitimate traffic from Vodafone?  Any simplistic approach taken by defenders will surely be circumvented by the attackers to continue operations and perhaps even be exploited to attack victims.  Inferring legitimacy from the complex global routing table is a difficult undertaking.

Case 5: FOP Obuhov Oleg Gennadiyovich (AS197923)

The previous example wasn’t the only case of falsifying origins in routing announcements. On June 30^th of last year, we saw AS197923 appear as the first and only customer of LLC Telecontur (AS47951) — a provider in Ufa, Russia that typically originates three prefixes.  Beginning on August 1^st of last year, we saw AS197923 begin to transit prefixes from some unlikely sources.  On that day, AS3300 (BT Infonet) first appeared downstream of AS197923 transiting 205.248.0.0/16 (BT Infonet). 205.248.0.0/16 is unused IP address space that is registered to the same company employing AS3300, namely, British Telecom’s BT Infonet.  This represented a real escalation in the war on Internet routing, namely, a falsified but quite plausible origin for hijacked routes.

Over the next couple of months until November, AS197923 routed more prefixes from plausible origins.  This phenomenon illustrates that the hijackers have upped their game and that simply checking that the origin of a route appears valid isn’t good enough.  These routes were originated by very reasonable origins.  It was their transit pattern that jumped out at us.  British Telecom routes aren’t transited through a small provider from Ufa, Russia.  That just doesn’t happen.

Falsely originated by AS3300 (BT Infonet), AS197923 transited the following prefixes.

148.188.32.0/20  Boehringer Ingelheim Pharmaceuticals, Inc. Ridgefield CT US
148.188.48.0/20  Boehringer Ingelheim Pharmaceuticals, Inc. Ridgefield CT US
195.184.128.0/19 British Telecommunications plc BE
195.90.64.0/19   British Telecommunications plc NL
198.207.64.0/18  INFONET Services Corporation El Segundo CA US
204.79.0.0/17    INFONET Services Corporation El Segundo CA US
206.182.0.0/17   INFONET Services Corporation El Segundo CA US
207.209.128.0/18 INFONET Services Corporation El Segundo CA US
207.209.32.0/19  INFONET Services Corporation El Segundo CA US

Falsely originated by AS5400 (British Telecom‘s primary ASN), AS197923 transited the following prefixes.

144.95.32.0/19   Akzo Nobel Coatings NL
144.95.96.0/19   Akzo Nobel Coatings NL
160.211.0.0/16   KIS Information Services GmbH DE
196.207.128.0/19 African Network Information Center - (AfriNIC Ltd) Lagos Lagos NG

Of the routes above, 160.211.0.0/16 is a less-specific of an existing route — 160.211.126.0/24 originated by Interoute (AS8928).  In the month of October last year, a handful of suspicious domains appeared:

physicsjournals8.com autosborevitalize.com

seriouspwinitiate.com biglcfind.com

architecturehumodify.com diamondnameplan.com

These domains resolved to 160.211.0.2, an IP in the /16, but not in the /24. This while 160.211.0.0/16 was being routed along 197923_5400.

Falsely originated by AS5427 (Primus Telecommunications Europe), AS197923 transited the following prefixes.

193.203.160.0/19 Primus Telecommunications Europe DE
195.214.64.0/19  Primus Telecommunications Europe DE
195.35.0.0/18    Primus Telecommunications Europe DE

Except for 195.214.79.0/24, which is originated by AS15968 and is a more-specific of 195.214.64.0/19, all three prefixes are unrouted IP address ranges.

Falsely originated by AS20570 (T-Systems International GmbH), AS197923 transited the following prefixes.

142.39.208.0/20  CAE Electronics Saint-Laurent QC CA
193.97.240.0/21  Actebis Holding GmbH Frankfurt Am Main Hessen DE
194.55.48.0/20   TNT Express GmbH Frankfurt Am Main Hessen DE
78.140.104.0/21  T-Systems International GmbH Frankfurt Am Main Hessen DE
78.140.112.0/21  T-Systems International GmbH Frankfurt Am Main Hessen DE
78.140.120.0/21  T-Systems International GmbH Hannover Niedersachsen DE
78.140.64.0/18   T-Systems International GmbH Frankfurt Am Main Hessen DE
93.122.0.0/18    T-Systems International Frankfurt-Niederrad Hessen DE
93.122.96.0/19   T-Systems International GmbH Frankfurt Am Main Hessen DE

And finally, falsely originated by AS37053 (RSAWEB of South Africa), AS197923 transited 41.71.0.0/17, unused routed address space registered to RSAWEB.

All of the routes involved in this route squatting operation took the following form (AS3216 is Vimpelcom of Russia):

… 3216 47951 197923 {3300, 5400, 20570, 5427, 37053} hijacked_prefix

Unlike some of the other Russian IP squatting operations, these routes stayed up for days or weeks at a time. On November 5^th of last year, I had seen enough of this behavior and started investigating it in earnest.  I began using Dyn Internet Intelligence to launch on-demand traceroutes from all over the world into the hijacked routes to help explore where hijacked traffic ended up.  The results confirmed that the traffic to these routes was being redirected into Russia.  However, while I was running these traceroutes, AS197923 and all its bogus routes disappeared.  It has not returned since.

Case 6: Comfort Air (AS200080) and 2Slink GmbH (AS60025)

These ASNs have had an interest in routing Iranian address space in the past year.  During December, AS200080 originated 188.253.79.0/24 out of Bulgaria for about two weeks.  This route is a more-specific hijack of 188.253.64.0/20 (Parsun Network Solutions) that is typically originated by AS31732 out of Iran.  Based on our DNS logs, between 22 — 28 December we observed DNS queries to the following suspicious FQDNs resolving to a single IP (188.253.79.27) in this range from a few hosts in the United States.

barehuva.uyqwiewqeou.rocks 2014-12-22 hedamuva.uyqwiewqeou.rocks 2014-12-22 u8a4aja2.uyqwiewqeou.rocks 2014-12-22 vuza4enu.uyqwiewqeou.rocks 2014-12-22 yhalajed.uyqwiewqeou.rocks 2014-12-22 yjege5ym.uyqwiewqeou.rocks 2014-12-22 zyzujy4u.uyqwiewqeou.rocks 2014-12-22 4are8avu.uyqwiewqeou.rocks 2014-12-23 5a9uqesy.uyqwiewqeou.rocks 2014-12-23 5urygebu.uyqwiewqeou.rocks 2014-12-23 8umuhamy.uyqwiewqeou.rocks 2014-12-23 apuzydy2.uyqwiewqeou.rocks 2014-12-23 dygavu5e.uyqwiewqeou.rocks 2014-12-23 e5e5ezu8.uyqwiewqeou.rocks 2014-12-23 etyju3u5.uyqwiewqeou.rocks 2014-12-23 ezadutud.uyqwiewqeou.rocks 2014-12-23 gyhugyze.uyqwiewqeou.rocks 2014-12-23 lezezu9a.uyqwiewqeou.rocks 2014-12-23 qyhe6yzy.uyqwiewqeou.rocks 2014-12-23

sy3yny6e.uyqwiewqeou.rocks 2014-12-23 ugygeweq.uyqwiewqeou.rocks 2014-12-23 uqe5y9e5.uyqwiewqeou.rocks 2014-12-23 y4y3avys.uyqwiewqeou.rocks 2014-12-23 yxese4y7.uyqwiewqeou.rocks 2014-12-23 yzeqyvep.uyqwiewqeou.rocks 2014-12-23 zuveqyva.uyqwiewqeou.rocks 2014-12-23 uvu2ubu7.uyqwiewqeou.rocks 2014-12-26 xyvulabu.uyqwiewqeou.rocks 2014-12-26 e8ymy8as.uyqwiewqeou.rocks 2014-12-27 esetesap.uyqwiewqeou.rocks 2014-12-27 gyja4amy.uyqwiewqeou.rocks 2014-12-27 te7ydy5u.uyqwiewqeou.rocks 2014-12-27 vu4y4esy.uyqwiewqeou.rocks 2014-12-27 ydegygyl.uyqwiewqeou.rocks 2014-12-27 5erupavy.uyqwiewqeou.rocks 2014-12-28 hytuguva.uyqwiewqeou.rocks 2014-12-28 te7ydy5u.uyqwiewqeou.rocks 2014-12-28 ujymymeq.uyqwiewqeou.rocks 2014-12-28

While these *.uyqwiewqeou.rocks FQDNs still resolve to 188.253.79.27 as of this writing, Dyn has not handled any queries for these FQDNs since the hijack disappeared.  What these FQDNs delivered to these hosts in the United States is unknown.  However, Vince Berk of Flowtraq (a network traffic flow analytic tool) informed me that one of their customers observed the following pattern taken from a packet capture:

[8b chars].uyqwiewqeou.rocks/[something]/[something]?sqi=[integer]


Conclusions

As lengthy as this blog post is, the list of hijacking examples given here is in no way exhaustive.  Our point in providing all of this detail is to illuminate a now constant and worrying trend on the Internet.  The criminals have discovered route hijacking and are exploiting this high-ground of global Internet trust on a daily basis. Having shown that, what is there to do?

Network operators like Cogent could consider dropping routes to entities like AS44050 that have a long history of being the source of spam and malware. Additionally, if you are peering with Business Torg (AS60937), Bitcanal (AS197426) or Marcel Edler (AS197043), you might want to review the routes you are receiving through them, or reconsider having the connections at all.

For security analysts reviewing alert logs, it is important to appreciate that the IP addresses identified as the source of incidents can and are regularly spoofed. For example, an attack that appeared to come from a Comcast IP located in New Jersey may have really been from a hijacker located in eastern Europe, briefly commandeering Comcast IP space. It is interesting to note that all six cases discussed above were conducted from either Europe or Russia.

Also, it is important to recognize that naive approaches for detecting nefarious routing behavior that rely on origin validation simply aren’t enough anymore.  The Ufa, Russia example shows that the perpetrators have advanced to the point of using plausible AS origins for their IP squatting.  A cryptographic solution like BGPSEC is needed, but progress is slow going. Since routing isn’t going to be secured any time soon, consider that the same Dyn Internet Intelligence that tracks Internet performance around the world also offers extensive and detailed real-time BGP routing alarms as one of its many features. Ultimately the solution must include the routing community. Last year’s Mutually Agreed Norms for Routing Security (MANRS) document is worth everyone’s attention and should grow to include thousands of additional signatories.

I will be reviewing these and other routing-based incidents at the Kaspersky Security Analysts Summit in sunny Cancun, Mexico next month. If you are in attendance at that event, please stop by and introduce yourself.

The post The Vast World of Fraudulent Routing appeared first on Dyn Research.

Cloud builders are often using my ExpertExpress service to validate their designs. Tenant onboarding into a multi-tenant (private or public) cloud infrastructure is a common problem, and tenants frequently want to retain the existing network services appliances (firewalls and load balancers).

The Combine Physical and Virtual Appliances in a Private Cloud case study describes a typical solution that combines per-tenant virtual appliances with frontend physical appliances.

Hi Guys!

Wow It's been a while since i've done a "new product" post! There has been so much slideware stuff being bounced around these days (COUGH *SDN COUGH COUGH) it's nice to see some honest to goodness, "solving a REAL problem, right NOW!" type products like new switches and new access points.

802.11AC Wave 2 is almost upon us, promising speeds of up to 6.8 Gigabit per second and a new method of allocating bandwidth so that CSCA (carrier Sense Collision Avoidance) algorithims traditionally used in the shared media of wireless can be avoided.

While our existing 802.11AC Wave 1 access points can get away with a 1 gig connection (because although the physical radio rate is slightly higher, the actual data rate is less than 1 gig) with these access points obviously that is no longer going to be an option.

I know what your thinking:  "OK time to go and pull out all my Cat5E cable I guess then and replace it all, that will be super cost effective! Hey Boss! Know how we just got all that cabling put in when we moved into this office? Yeah it's redundant now we need to run all new cabling."

The disruption to the office, the cost and the justification for the above scenario will be difficult for quite a few customers.

So, Cisco and other concerned internet citizens banded together to introduce a standard (awaiting approval from the IEEE) called NBase. (note: their is a competing standard being proposed by another smaller networking vendor alliance. It is difficult to predict which standard will emerge at this point)


NBase allows you to use Cat5E and Cat6 cable all the way to 100m (the original spec) with speeds of either 2.5gigabit per second or 5 gigabit per second!

This is going to be a great stop-gap measure for a lot of people!


Let's take a look at some of the switches/devices they introduced to support this:

Like the 3850X these models support NBase technology, Universal POE and in certain models 10 gigabit uplinks, all in a completely silent and fanless switch!

What's more, the new models can be used as instant access switches, allowing you to centralize the configuration on your 6800 switches. Depending on what your network topology looks like, this could be a huge boon!


I hope you found this interesting and are as excited as I am to see if the products live up to the hype!

Today, user privacy is a huge concern. Check out the seven ways to protect yourself and your identity while connected to the network. 

Big Switch Networks has released version 2.5 of their Big Cloud Fabric SDN offering. Read the full press release here. What’s Big Cloud Fabric? BCF is an SDN-based IP fabric where you manage all of the individual switches as one “big switch.” In other words, you manage the fabric as a whole, and not individual switches. Big […]

This is a continuation from Part 2 Fast Reroute Why Fast Reroute? Many NSP’s like ACME have traffic with tight SLAs. For instance below is an ITU delay recommendation for Voice. One Way Delay Characterization of Quality 0-150ms Acceptable for most applications 150-400ms May impact some applications Above 400ms Unacceptable ITU G.114 delay recommendations Having […]

Author information

The post MPLS TE Design -Part 3 appeared first on Packet Pushers Podcast and was written by Diptanshu Singh.

This is a continuation from Part 1 Case for LDPoRSVP As we mentioned at the very beginning that ACME provides L3VPN and L2VPN services, which requires end to end LSP between the PEs. But due to scaling reasons, ACME decided not to extend RSVP to the edge routers. This creates a problem as there is […]

Author information

The post MPLS TE Design -Part 2 appeared first on Packet Pushers Podcast and was written by Diptanshu Singh.

In this post we will be exploring different aspects of Traffic Engineering (RSVP-TE) from a design perspective using fictional ISP as a reference. The intent of the post is to not necessarily recommend a particular solution, but to bring up different aspects involved in the design. I am assuming that the reader already has somewhat […]

Author information

The post MPLS TE Design -Part 1 appeared first on Packet Pushers Podcast and was written by Diptanshu Singh.

Listening to some SDN pundits one gets an impression that SDN brings peace to Earth, solves all networking problems and makes networking engineers obsolete.

Cynical jokes aside, and ignoring inevitable bugs, is controller-based networking really more reliable than what we do today?

Read more ...

Margaret Chiosi, president of the OPNFV project hosted at the Linux Foundation, discusses OPNFV in a briefing with Ethan Banks.

As whitebox switching starts coming to the forefront of the next buying cycle for enterprises, decision makers are naturally wondering about the advantages of buying cheaper hardware. Is a whitebox switch going to provide more value for me than buying something from an established vendor? Where are the real savings? Is whitebox really for me? One of the answers to this puzzle comes not from the savings in whitebox purchases, but the capability inherent in rapid deployment.

Ten Thousand Spoons

When users are looking at the acquisition cost advantages of buying whitebox switches, they typically don’t see what they would like to see. Ridiculously cheap hardware isn’t the norm. Instead, you see a switch that can be bought for a decent discount. That does take into account that most vendors will give substantial one-time discounts to customers to entice them into more lucrative options like advanced support or professional services.

The purchasing advantage of whitebox doesn’t just come from reduced costs. It comes from additional unit purchases. Purchasing budgets don’t typically spell out that you are allowed to buy ten switches and three firewalls. They more often state that you are allowed to spend a certain dollar amount on devices of a specific type. Savvy shoppers will find deals or discounts to get more for their dollar. The real world of purchasing budgets means that every dollar will be spent, lest the available dollars get reduced next year.

With whitebox, that purchasing power translates into additional units for the same budget amount. If I could buy three switches from Vendor X or five switches from Whitebox Vendor Y, ceteris paribus I would buy the whitebox switches. If the purpose of the purchase was to connect 144 ports, then that means I have two extra switches lying around. Which does seem a bit wasteful.

However, the option of having spares on the shelf becomes very appealing. Networks are supposed to be built in a way to minimize or eliminate downtime because of failure. The network must continue to run if a switch dies. But what happens to the dead switch? In most current cases, the switch must be sent in for warranty replacement. Services contracts with large networking vendors give you the option for 4-hour, overnight, or next business day replacements. These vendors will even cross-ship you the part. But you are still down the dead switch. If the other part of the redundant pair goes down, you are going to be dead in the water.

With an extra whitebox switch on the shelf you can have a ready replacement. Just slip it into place and let your orchestration and provisioning software do the rest. While the replacement is shipping, you still have redundancy. It also saves you from needing to buy a hugely expensive (and wildly profitable) advanced support contract.

All You Need Is A Knife

Suppose for a moment that we do have these switches sitting around on a shelf doing nothing but waiting for the inevitable failure in the network. From a cost perspective, it’s neutral. I spent the same budget either way, so an unutilized switch is costing me nothing. However, what if I could do something with that switch?

The real advantage of whitebox in this scenario comes from the ability to use non-switching OSes on the hardware. Think for a moment about something like a network packet monitor. In the past, we’ve needed to download specialized software and slip a probing device into the network just for the purposes of packet collection. What if that could be done by a switch? What if the same hardware that is forwarding packets through the network could also be used to monitor them as well?

Imagine creating an operating system that runs on top of something like ONIE for the purpose of being a network tap. Now, instead of specialized hardware for that purpose you only need to go and use one of the switches you have lying around on the shelf and repurpose it into a sensor. And when it’s served that purpose, you put it back on the shelf and wait until there is a failure before going back to push it into production as a replacement. With Chef or Puppet, you could even have the switch boot into a sensor identity for a few days and then provision it back to being a data forwarding switch afterwards. No need for messy complicated software images or clever hacks.

Now, extend those ideas beyond sensors. Think about generic hardware that could be repurposed for any function. A switch could boot up as an inline firewall. That firewall could be repurposed into a load balancer for the end of the quarter. It could then become a passive IDS during an attack. All without moving. The only limitation is the imagination of the people writing code for the device. It may not ever top the performance of a device running purely for the purpose of a given function, but the flexibility of having a device that can serve multiple functions without massive reconfiguration would win out in the long run for many applications. Flexibility is more key than overwhelming performance.

---

Tom’s Take

Whitebox is still finding a purpose in the enterprise. It’s been embraced by webscale, but the value to the enterprise is not found in massive capabilities like that. Instead, the additional purchasing power that can be derived from additional unit purchases for the same dollar amount leads to reduced support contract costs and even new functionality increases from existing hardware lying around that can be made to do so many other things. Who could have imagined that a simple switch could be made to do the job of many other purpose-built devices in the data center? Isn’t it ironic, don’t you think?

 

Last spring I ran an IPv6 High Availability webinar which started (not surprisingly) with a simple question: “which network components affect availability in IPv6 world, and how is a dual-stack or an IPv6-only environment different from what we had in the IPv4 world?”

This part of the webinar is now available on ipSpace.net content web site. Enjoy the video, explore other IPv6 resources on ipSpace net, and if you’re from Europe don’t forget to register for the IPv6 Security Summit @ Troppers in mid-March.

The technology that gives me a “nerd hard-on” this month is SDN WAN. Here is why.

The post 2015 is all about SDN WAN appeared first on EtherealMind.

Continue reading · 4 comments

In one of the discussions on v6ops mailing list Matthew Petach wrote:

The probability of us figuring out how to scale the routing table to handle 40 billion prefixes is orders of magnitude more likely than solving the headaches associated with dynamic host renumbering. That ship has done gone and sailed, hit the proverbial iceberg, and is gathering barnacles at the bottom of the ocean.

Is it really that bad? Is simple renumbering in IPv6 world just another myth? It depends.

Read more ...

0.05 level" and hope no one notices." />0.05 level" and hope no one notices." alt="If all else fails, use "significant at a p>0.05 level" and hope no one notices." />

A technical interviewer, or technically an interviewer. I was interviewed quite a few times since I set of to join the networking crowd, 12 years ago. I also had opportunity to sit on the opposite side, and interviewed people on multiple occasions. Some of my fondest memories of working for my current employer are connected […]

Author information

The post Confessions of technical interviewer appeared first on Packet Pushers Podcast and was written by Marcin Latosiewicz.

Brocade VCS fabric has one of the most flexible multichassis link aggregation group (LAG) implementation – you can terminate member links of an individual LAG on any four switches in the VCS fabric. Using that flexibility is not always a good idea.

2015-01-23: Added a few caveats on load distribution

Read more ...

Hi Guys!

Quick and handy way if you THINK you know the cluster password to verify it, just login to the CLI and execute:

set password security (you may or may not need the user keyword depending on if your on version 8 or above)

This will prompt you for the old password, so you have chance to test what you THINK the old cluster password is before continuing!


More detail here:
https://supportforums.cisco.com/document/65041/how-reset-passwords-cucm#Security_password

In the last video from the Network Programmability webinar Matt Oswalt answered numerous questions from the audience.

Here is the scenario: There is a public server on the internet that you have requested access to. The “admins” that control the server agree to allow a single public IP from your entity/company to access the server. The issue arises due to the fact that you “luckily” have more than 1 Public IP at […]

Author information

The post Destination Based NAT appeared first on Packet Pushers Podcast and was written by Korey Rebello.

Doug Hanks and Moloy Chatterjee join Packet Pushers host Ethan Banks to discuss the OpenClos project.

A Poster for your desk on building a "single pane of glass" network management system.

The post Poster: How To Make a Single Pane of Glass appeared first on EtherealMind.

I’m going to start out by telling you something you probably already know. Every vendor has their own way of doing things. Sometimes it makes perfect sense, and other times you end up scratching your head wondering why that particular vendor implemented this feature or product. Since I have been spending a lot more time on wireless these days, I came across an issue that forced me to reconsider how transmit power control(TPC) actually works in a Cisco wireless deployment. I thought I would impart some of this information to you, dear reader, in the hopes that it may help you. If you spend a lot of time inside Cisco wireless LAN controllers, this may not be anything new to you.

The Need For TPC

If you have been around wireless long enough, you have probably dealt with wireless installs where all of the access points(AP) were functioning autonomously. While this isn’t a big deal in smaller environments, consider how much design work goes into a network with autonomous access points that number into the hundreds. It isn’t as simple as just deciding on channels and spinning all the access points up. You also have to consider the power levels of the respective access points. Failure to do so can result in the image below where the AP is clearly heard by the client device, but the AP cannot hear the client since it is transmitting at a higher power level than the client can match.

 

Now consider the use of a wireless LAN controller to manage all of those APs. In addition to things like dynamic channel assignment, you can also have it adjust the transmit power levels of the APs. This can come in handy when you have an AP fail and need the other APs to increase their transmit power to fill the gap that exists since that failed AP is no longer servicing clients. I should point out that proper design of a wireless network with respect to the client transmit power capabilities should NEVER be overlooked. You ALWAYS want to be aware of what power levels your clients can transmit at. It helps to reduce the problem in the image above.

There’s also the problem that can arise when too many APs can hear each other. It isn’t just about the clients. Wireless systems which adhere to the IEEE 802.11 standard are a half duplex medium. Only one device can talk at a time on a given channel. Either a client or the AP will talk, but not both at once. If an AP can hear another AP on the same channel at a usable signal, the airtime must be shared between those APs. Depending on the number of SSID’s in use, this can dramatically reduce the amount of airtime available for an AP to service a client. You can see some actual numbers with regard to SSIDs and APs in this blog post by Andrew von Nagy.

As you can see from two quick examples, there is a need to control the power level in which an AP will transmit. On controller based wireless networks(and even on the newer controller-less solutions), this is done automatically. I wouldn’t advise you turn that off unless you really know what you are doing and you have the time to plan it all out beforehand.

The Cisco Approach

On wireless LAN controllers, TPC is a function of Radio Resource Management(RRM). The specifics can be found here. I’ll spare you the read and give you the high points.

• The TPC algorithm is only concerned with reducing power levels. Increases in power levels are covered by Coverage Hole Detection and Correction algorithm.
• TPC runs in 10 minute intervals.
• A minimum of 4 APs are required for TPC to work.

It is the last point that I want to focus on, because the first two are pretty self explanatory. The reasoning behind the 4 AP minimum for TPC is as follows:

“For TPC to work ( or to even have a need for TPC ) 4 APS must be in proximity of each other.  Why? Because on 2.4 GHz you only have three channels that do not overlap… Once you have a fourth AP you need to potentially adjust power down to avoid co channel interference.   With 3 APS full power will not cause this issue.”

Those are not my words. They came from someone within Cisco that is focused on wireless. Since that person didn’t know I would publish that, I will not name said person. The explanation though, makes sense.

***Update – It appears that the Cisco documentation regarding TPC is a bit murky. Jeff Rensink pointed out in the comments below that TPC will also increase power levels. Although CHD will increase based on client information, I didn’t use any clients in my testing, as Jeff rightly assumed. The power increases I saw once I started removing AP’s from the WLC could not have been attributed to CHD adjustments. Read his comment below as he makes some very valid points. The NDP reference and accompanying link in his comment is fairly interesting.

Let’s see it in action to validate what Cisco’s documentation says.

TPC Testing

I happen to have a Cisco WLC 2504 handy with 4 APs. I set it up in my home office and only maintained about 10 feet separation from the APs. Ideally, I would test it with the APs a lot farther apart, but I did put some barriers around the APs to give some extra attenuation to the signal. I also only did testing on the 5GHz band. I disabled all of the 2.4GHz radios because I don’t need to give any of my neighbors a reason to hate me. Blasting 5GHz is less disruptive to their home wireless networks than 2.4GHz is due to the signals traveling farther/less attenuation of 2.4GHz vs 5GHz signals/antenna aperture.

Here you can see the available settings for TPC in the WLC GUI. This particular controller is running 7.6 code, so your version may vary.

Some notes on options:

• You can either set TPC to run automatically, on demand, or at a fixed power rate on all APs. TPC is band specific, so if you want different settings for 2.4GHz and 5GHz respectively, you can have that.
• Maximum and minimum settings for transmit power are available. The defaults are 30dBm for maximum power and -10dBm for minimum power.
• The power threshold is the minimum level at which you need to hear the third AP for the TPC algorithm to run. The default is -70dBm. You can set it higher or lower depending on your needs. High density environments might require a level stronger than -70dBm, with -50dBm being the strongest level supported. If you don’t necessarily need to run things like voice, you might be able to get away with a weaker threshold, but you cannot go beyond -80dBm.

A Quick Sidebar on Maximum Transmit Power in 5GHz

I set up the WLC with 3 APs active on 5GHz only. You can see that the power levels on the 3 APs are set to 1 in the image further down, which is maximum power according to Cisco. While it seems odd that max power would be a 1 and not some higher number, consider the fact that there are multiple maximum transmit power levels depending on which UNII band you are using in 5GHz. As a general reference, 20dBm would be 100mW and 14dBm would be 25mW. You could get 200mW(23dBm) of power using a UNII-3 channel vs UNII-1, which is maxed out 32mW(15dBm). That is a HUGE difference.

• UNII-1 power levels for channels 36-48:
  • 1 – 15dBm
  • 2 – 12dBm
  • 3 – 9dBm
  • 4 – 6dBm
  • 5 – 3dBm
• UNII-2 power levels for channels 52-64(I didn’t test UNII-2 Extended, but I suspect it is the same:
  • 1 – 17dBm
  • 2 – 14dBm
  • 3 – 11dBm
  • 4 – 8dBm
  • 5 – 5dBm
  • 6 – 2dBm
• UNII-3 power levels for channels 149-161:
  • 1 – 23dBm
  • 2 – 20dBm
  • 3 – 17dBm
  • 4 – 14dBm
  • 5 – 11dBm
  • 6 – 8dBm
  • 7 – 5dBm

To see the supported power levels in terms of dBm on 5GHz, you can run the following command on the CLI of the WLC:

show ap config 802.11a <ap name>

The output will look something like this after you go through a handful of screens showing other stuff:

 

 

***Update – Brian Long wrote a blog post on this very thing! You can read it here.

Back To The Testing…

You can see in the image below that with 3 APs active, they are all running at power level 1, which is the default when the radios come online.

So let’s see what happens when I add the fourth AP. If our understanding of TPC is correct, we should see the power levels come down since the APs are so close to each other and will have a signal strength of well above -70dBm between each other.

The fourth AP now shows up, but the power levels are still maxed out at 1. The AP’s are also using channels on all 3 UNII bands, so there is a huge disparity in output power right now. After a few minutes, the following shows up in the WLC:

Now we can see TPC working. It has reduced all 4 APs to a power level of 2. Once the TPC algorithm kicks in, it will run every 10 minutes until it reaches a level where the fourth AP is just within the power threshold of -70dBm. Let’s see if it keeps reducing power.

Now we are at a power level of 3. Ten more minutes pass and I see the following:

Two of the APs have been reduced to a power level of 4. Ten more minutes passed and power levels reduced even further. At that point, I powered off one of the APs to see if the power levels would go back to 1 since there was no longer a fourth AP. I didn’t get a screen shot in time to see all 4 APs at an even lower power level, but when I did grab a screen shot of the 3 remaining APs, one of them had been dropped to a power level of 5. I believe this happened prior to my unplugging the fourth AP.

Note – Power level decreases happen in single increments only, every time the TPC algorithm runs(every 10 minutes). To put it another way, it downgrades by 3dB max each cycle. Sam Clements pointed out to me via Twitter that when power levels increase, it can happen much more rapidly since the Coverage Hole Detection(CHD) and Correction algorithm is responsible for power increases.

I waited for at least 30 minutes to see if the power levels would return to 1 for the remaining 3 APs, but they didn’t move at all. They stayed just like the above image.

If you want to see this work on the CLI in real time, you can issue the following command:

debug airewave-director power enable

After I had waited for over half an hour, I decided to power off one more AP. When I brought it back online, I saw all 3 of the APs slowly go back to a power level of 1. Here’s the first change I saw in the 3 remaining APs:

And then shortly afterward, I saw them back at max power.

 

It’s All In The Details

For wireless surveys, my company uses the Ekahau Site Survey product. It is a really neat survey tool and we use it for on site assessments as well as predictive surveys. When you define the requirements of the project, you can choose from a bunch of different vendor specific scenarios, or general wireless scenarios. I can apply those requirements to a predictive survey, or an on site survey where I am trying to determine if the existing coverage/capacity is good enough for the business needs.

Here’s a screen shot of the default requirements for the “Cisco Voice” scenario found in version 7.6.4 of Ekahau’s Site Survey program:

Pay careful attention to the “Number of Access Points” field. By default, it shows 2 APs with a minimum signal strength of -75dBm. If I am building a predictive survey for Cisco voice, I would need to have all of my coverage areas to see 2 APs at a signal of -75dBm or better. That’s perfectly fine, but I also have to consider the APs and how they determine, you guessed it, transmit power. If I change the value in the “Number of Access Points” field to 3 APs at -70dBm or better, I can build my predictive survey around inter-AP communication as well. In that scenario, I am not looking to cover the entire floor or building to that standard. I just need to make sure that all of my APs can see 3 or more APs at -70dBm or better. Of course, if I am not using Cisco wireless to support a Cisco voice implementation, I need to figure out how that other wireless vendor determines transmit power. Just something to consider when interpreting the results of an actual or predictive survey. It isn’t entirely about the clients and their relationship to the AP. AP to AP communication matters as well!

Closing Thoughts

Understanding how the TPC function works is pretty important when designing Cisco wireless networks. Failure to consider what all is involved in regards to transmit power on your APs could(not WILL, but COULD) lead to problems in the wireless network’s operation. However, if you want to manually set transmit power, that’s an option as well. Opinions differ on running RRM. I’m not sure there is a right or wrong answer. It depends. I will say that I almost never see Cisco wireless implementations where RRM is not being used.

I don’t want to end this post without mentioning that some networks may be perfectly fine running APs at max power, especially on the 5GHz side. Your coverage may be enough to where there is minimal channel overlap(easily achievable in 5GHz with 20MHz channels and the use of all 3 UNII bands), and each AP can hear one or two neighboring APs at a decent level due to good cell overlap. You just might not have enough APs to trigger the TPC algorithm to run. That doesn’t mean “you are doing it wrong”. If it works for the business and all your users are fine, who am I to tell you that you need to “fix” it.

Hopefully this was beneficial to you if you needed a clearer understanding of how Cisco’s TPC function works. If you already have a good understanding of TPC and managed to read this far, feel free to shame humiliate correct me in the comments.

Load sharing in MPLS networks is always an interesting topic, and we couldn’t possibly avoid it during our MPLS-focused Tech Talks – watch the video.

After discussing the load sharing intricacies we briefly dabbled with the concept of entropy labels.

Ken Gott, Product Line Manager, joins Chris Young, Senior Solutions Architect, for a discussion about HP's Intelligent Management Center (IMC) with Packet Pushers Greg Ferro and Ethan Banks.