0

Redundant Default Gateway solutions in IPv4 networks

How does the internet work - We know what is networking

This article is an introduction to different default gateway solutions. Those technologies are enabling devices on IPv4 local subnets to have more than one Default gateway configured or at least some configuration that make them work half the way of ideal redundant solution. Idea behind this article is to be an introduction to a set […]

Redundant Default Gateway solutions in IPv4 networks

0

ICMP – Internet Control Message Protocol

How does the internet work - We know what is networking

ICMP protocol is a bunch of error, queries and response messages that are helping us every day to troubleshoot and manage our networks. At least if you found yourself in a networking engineer role. Network protocol “ICMP” is known as a control protocol because it is used for the purpose of administration and management within an […]

ICMP – Internet Control Message Protocol

0

The 5 Year Plan

I was recently asked what my 5 year career plan was and whether I wanted to go down the architect route. It threw me a little bit because I’ve never really been a 5 year type person. I have real trouble seeing where I’ll be beyond a year to 18 months.

So, this is my attempt to try and put something together. It doesn’t hurt to have a plan right?

Ideally, you need a short, medium and long term plan. A couple of these could be tech related (e.g: get to CCIE), but the pace technology moves at means the longest term one (if it’s longer than 3 years could well have moved goalposts, or died out). So, without ado, I give you the 3 – 6- 12 – 24 – 36 plan. Or 3,6,1,2,3 plan. This is my way of putting down what I want to have achieved in the next 3-6 months, year, 2 and 3 years.

3-6 months: Get my CCNP Security finished with, and maybe another associate level non-Cisco vendor certification.

1 year: Complete my CCIE written and be on my way to lab revision.

2 years: Completed, or have attempted the CCIE lab once.

Continue reading

0

Why you should want metered INET?

When people think about metered, they may think about mobile roaming or old outrageous per minute PSTN billing. Those are not fair prices, they are not what I'm talking about.

Also INET should be always on, billing should take this into consideration, maybe once you exceed your paid capacity, your connection is policed to 256kbps unless you pay for more. You could get notice when this limit is nearing by SMS and Email.

Flat-rate billing is based on assumption that on average INET is not used much at all, in such scenario it works. Consumers get flat-rate stove-gas in Helsinki, because its use is almost non-existing. But services like Youtube and Netflix which are relatively new can alone be 2/3 of all your traffic, meaning what ever average use you planned for, it's not true, average use is increasing as more services users care for appear.

---

1. Quality

When you pay flat rate there is financial incentive for your operator not to provide you bits, every bit not provided improves your margins. Operators today regularly keep some ports congested, because it would be expensive to upgrade, instead they try get someone else to pay for it, if they have the Continue reading

0

#NFD7 Real Time SDN and NFV Analytics for DDoS Mitigation

Today, at Networking Field Day 7, Ramki Krishnan of Brocade Networks demonstrated how the sFlow and OpenFlow standards can be combined to deliver DDoS mitigation as a service. Ramki is a co-author of related Internet Drafts: Large Flow Use Cases for I2RS PBR and QoS and Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks.
The talk starts by outlining the growing problem of DDoS attacks and the market opportunity for mitigation solutions, referencing the articles, Prolexic Publishes Top 10 DDoS Attack Trends for 2013, World's largest DDoS strikes US, Europe.
The diagram shows the unique position occupied by Internet Service Provider (ISP) and Internet Exchange (IX) networks, allowing them to filter large flood attacks and prevent them from overwhelming Enterprise customer connections - provided they can use their network to efficiently detect attacks and automatically filter traffic for their customers.
This diagram shows how standard sFlow enabled in the switches and routers provides a continuous stream of measurement data to InMon sFlow-RT, which provided real-time detection and notification of DDoS attacks to the DDoS Mitigation SDN Application. The DDoS Mitigation SDN Application selects a mitigation action and instructs the SDN Controller to push the action to Continue reading

0

Faking an ASA as a DNS Forwarder

I came across a good tip the other day that was very helpful during a small site firewall migration. Here’s the back story:

I was migrating a small single-site customer that had, up to this point, been using a FIOS-provided consumer-type router/firewall/access point to some Cisco gear including an ASA firewall for better firewall/VPN capabilities. This is fairly common with small businesses that start out with essentially consumer-style connectivity and finally begin to grow to a point of needing business-grade capabilities. My preparation went fine, and when the time came I swapped the ASA firewall in place of the FIOS-provided one. Then everything broke.

I had meticulously prepared the ASA to take over immediately from the old FIOS router, even going so far as to spoof the FIOS router’s MAC address on the ASA’s inside interface for now so as not to disrupt the 60-or-so clients that were all on the single attached internal subnet while their ARP caches timed out since we were doing the install and cut-over during working hours. I had set up a DHCP scope on the ASA as well, which instructed clients to use some public DNS resolvers as this small business has, so far, Continue reading

0

Is CPU or ASIC responsible for forwarding?

I received the question below from reader Ned as a comment on my 24-port ASIC post and thought that the discussion was worth a post of it’s own. …Would you be able to speak a bit about the actual physical path … Continue reading →

The post Is CPU or ASIC responsible for forwarding? appeared first on The Network Sherpa.

0

Hardware – What’s the ‘holdup’?

This post discusses power supply ‘holdup’, and how it can impact network or server hardware uptime. The holdup time or ‘output holdup time’ is the length of time that a given power supply can maintain output power to the switch … Continue reading →

The post Hardware – What’s the ‘holdup’? appeared first on The Network Sherpa.

0

Goodbye Snowpocalypse, Hello Networking Field Day 7!

I’m excited to rub elbows and network with the exceptional delegate list. I have met nearly all of this event’s delegates before and I respect the expertise and experience of every single participant. I feel I have learned so much and made so many valuable connections through TFD events and I’m grateful to Gestalt IT and the TFD community for another opportunity to participate.

Sponsors

0

BGP in 2013 – The Churn Report

When looking at the Internet's Inter-domain routing space, the number of routed entries in the routing table is not the only metric of the scale of the routing space – it’s also what the routing protocol, BGP, does with this information that matters. As the routing table increases in size do we see a corresponding increase in the number of updates generated by BGP as it attempts to find a converged state? What can we see when we look a the profile of dynamic updates within BGP, and can we make some projections here about the likely future for BGP?

0

25 – Why the DC network architecture is evolving to fabric?

The Datacenter network architecture is evolving from the traditional multi-tier layer architecture, where the placement of security and network service is usually at the aggregation layer, into a wider spine and flat network also known as fabric network ( ‘Clos’ type), where the network services are distributed to the border leafs.

This evolution has been conceived at improving the following :

• Flexibility : allows workload mobility everywhere in the DC
• Robustness : while dynamic mobility is allowed on any authorised location of the DC, the failure domain is contained to its smallest zone
• Performance: full cross sectional bandwidth (any-to-any)  – all possible equal paths between two endpoints are active
• Deterministic Latency : fix and predictable latency between two endpoints with same hop count between any two endpoints, independently of scale.
• Scalability : add as many spines as needed to increase the number of servers while maintaing the same oversubscription ratio everywhere inside the fabric.

If most of qualifiers above have been already successfully addressed with traditional multi-tier layer architecture, today’s Data centres are experiencing an increase of East-West data traffic that is the result of:

• Adoption of new software paradigm of highly distributed resources
• Server virtualization and workload mobility
• Migration to IP Continue reading

0

The Power of a Programmable Abstraction Layer

0

Cisco Nexus 9000 NX-API

A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS. ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.

0

Cisco Nexus 9000 NX-API

A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS. ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.

0

Show 180 – The Art of Network Architecture: Business-Driven Design

In this show, host Ethan Banks is joined by Russ White & Denise Donohue, co-authors of the soon-to-be-released CiscoPress title, The Art of Network Architecture: Business Driven Design. Orhan Ergun reviewed the book and also shares his perspectives. This isn’t just a book review, though. Really, the show uses the book as a springboard to […]

Author information

The post Show 180 – The Art of Network Architecture: Business-Driven Design appeared first on Packet Pushers Podcast and was written by Ethan Banks.

0

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

0

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

0

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

0

Programmatically Configuring Interface Descriptions from Phone Descriptions

I wrote some Python code that allows you to do the following:

1. Query a Catalyst switch CDP neighbor table from its HTTPS interface,
2. Extract the device names of the attached IP phones,
3. Query Communications Manager for the IP phone device description, 
4. Apply the device description as the switch interface description.

Obviously, this makes it much easier to see whose phone is attached to a switch port.

I hope that this example saves someone the head-banging that I incurred while trying to figure out the AXL XML/SOAP API for Communications Manager.

I haven't tested this extensively; all my testing has been on Catalyst 3560 and 3750 switches and CUCM version 8.6. Using the --auto switch to automatically configure the switch is quite slow; this is a limitation of the HTTPS interface rather than the script code. It may be faster to leave that option off and manually copy/paste the printed configuration if you're in a hurry.

Note that your switch must be configured to allow configuration via the HTTPS interface; you may need to modify your TACACS/etc. configurations accordingly.

All the relevant info is in the Github repo.

0

Programmatically Configuring Interface Descriptions from Phone Descriptions

I wrote some Python code that allows you to do the following:

1. Query a Catalyst switch CDP neighbor table from its HTTPS interface,
2. Extract the device names of the attached IP phones,
3. Query Communications Manager for the IP phone device description, 
4. Apply the device description as the switch interface description.

Obviously, this makes it much easier to see whose phone is attached to a switch port.

I hope that this example saves someone the head-banging that I incurred while trying to figure out the AXL XML/SOAP API for Communications Manager.

I haven't tested this extensively; all my testing has been on Catalyst 3560 and 3750 switches and CUCM version 8.6. Using the --auto switch to automatically configure the switch is quite slow; this is a limitation of the HTTPS interface rather than the script code. It may be faster to leave that option off and manually copy/paste the printed configuration if you're in a hurry.

Note that your switch must be configured to allow configuration via the HTTPS interface; you may need to modify your TACACS/etc. configurations accordingly.

All the relevant info is in the Github repo.