Role Based Access Control in IOS
I don't believe this is well known: Cisco IOS has Role Based Access Control (RBAC) which can be used to create and assign different levels of privileged access to the device. Without RBAC there are two access levels in IOS: a read-only mode with limited access to commands and no ability to modify the running config (also called privilege level 1) and enable mode with full administrative access. There is no middle ground; it's all or nothing. RBAC allows creation of access levels somewhere between nothing and everything. A common use case is creating a role for the first line NOC analyst which might allow them to view the running config, configure interfaces, and configure named access-lists.
GNS3 Bridge to ESXi Environment using GNS3.
Hello Once Again! Here is another blog post I decided to create where I bridge my GNS3 environment with my entire ESXi Environment.Analysis: Marriot Court Case Highlights the Problems of WiFi Services
Customers who pay for WiFi expect it to work. Marriott wanted to make that guarantee. But wireless spectrum is shared, uncontrolled, unregulated and unpredictable. You can't give a viable guarantee. Then you add lawyers ......
The post Analysis: Marriot Court Case Highlights the Problems of WiFi Services appeared first on EtherealMind.
Cumulus Networks Support — Community Style
Sometimes, it’s not what you know, it’s who you know. Today we launch a new method of support to the Cumulus Networks family, a community question and answer site. This is a place where you can ask either a simple question for which you couldn’t find an answer, or maybe something you’ve always wanted to know. It’s also a place to engage in conversation with other users that may be experiencing things you have seen in the past or may encounter in the future.
To be sure, Cumulus Networks employees will be on hand to assist and direct you to the documentation and knowledge base as appropriate. If a question is too complex, we will assess your needs based upon your support entitlements and work with you to open a ticket so our excellent support team can assist you in figuring out your issue. The community portal is a supplement to the support team, not a replacement.
Our growth is directly related to you, our community, and in that vein, we want to offer more ways that you can be involved — this is just the beginning. Look for more to come in upcoming blog posts.
The post Cumulus Networks Continue reading
BGPMon Joins OpenDNS
Dear BGPmon.net user,
I’m excited to announce that BGPmon has been acquired by OpenDNS. OpenDNS is a leading cloud-delivered network security company known for engineering predictive intelligence technology that stops malicious activity before it can threaten a network.
Over the last few years BGPmon has grown from a community service into a successful business that helps thousands of network engineers from around the world monitor their networks. Throughout this journey, we’ve developed close relationships with many of you and together, worked on some truly fascinating cases.
Becoming a part of OpenDNS is a logical next step for BGPmon. With its engineering resources, massive scale and cloud delivery model, OpenDNS is the right direction to continue growing the BGPmon service. I’m confident that moving forward BGPmon will only get better.
The transition plan is straightforward. OpenDNS will invest in building out the service even more but also is committed to keeping the free features free. Simply put, nothing regarding the service will change other than we’ll continue adding new functionality.
On a personal note, I’d like to thank all of you for your continued support and encouragement. I am excited for the changes ahead and personally being a part of Continue reading
Network Break 31
Over-opinionated analysis on data network and IT Infrastructure. And virtual doughnuts.
Author information
The post Network Break 31 appeared first on Packet Pushers Podcast and was written by Greg Ferro.
Topology Challenge Winners
Firstly on behalf of the entire GNS3 team - WOW! We are always so impressed with how far people are pushing the software but thisProduction Designs Are Compromise – And That’s Okay
During a bout of stress & jet lag induced insomnia, I logged onto Twitter in the wee hours to see what folks were saying. I found a number of twitpisses in my timeline. Twitpisses are arguments in which people assert that Someone On The Internet Is Wrong in 140 characters or less. After […]Routing Leak briefly takes down Google
This morning, users of Google around the world were unable to access many of the company’s services due to a routing leak in India. Beginning at 08:58 UTC Indian broadband provider Hathway (AS17488) incorrectly announced over 300 Google prefixes to its Indian transit provider Bharti Airtel (AS9498).
Bharti in turn announced these routes to the rest of the world, and a number of ISPs accepted these routes including US carriers Cogent (AS174), Level 3 (AS3549) as well as overseas incumbent carriers Orange (France Telecom, AS5511), Singapore Telecom (Singtel, AS7473) and Pakistan Telecom (PTCL, AS17557). Like many providers around the world, Hathway peers with Google so that their customers have more direct connectivity with Google services. But when that private relationship enters the public Internet the result can be accidental global traffic redirection.
Last fall, I wrote two blog posts here and here about the issues surrounding routing leaks such this one. Routing leaks happen regularly and can have the effect of misdirecting global traffic. Last month, I gave a talk in the NANOG 63 Peering Forum entitled “Hidden Risks of Peering” that went over some examples of routing leaks like this one.
Below is a graph showing the Continue reading
What the *, traceroute?
If you’ve ever done a traceroute from one IOS box to another, you’ve undoubtedly seen output like this:
R8# traceroute 192.168.100.7
Tracing the route to 192.168.100.7
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.0.1 4 msec 3 msec 4 msec
2 192.168.100.7 4 msec * 0 msecThat “msec * msec” output. Why is the middle packet always lost?? And why only on the last hop??
This was always something curious to me but not something I ever bothered to learn about. Well it turns out that IOS has a rate limiter that meters the generation of ICMP Unreachable messages. The default setting for the rate limiter is 1 ICMP Unreach every 500ms. Since IOS’s traceroute doesn’t put a delay between its probe packets, the delay between when 192.168.100.7 receives the first and second probe packets is much less than 500ms. The second packet violates the rate limiter and so 192.168.100.7 drops it.
Why isn’t the third packet also dropped? Because the traceroute command waits for 3 seconds (by default) before deciding that a probe packet was lost and Continue reading