Archive

Category Archives for "Networking"

I Am “Cisco Man”

Hello. Let me begin by saying you have arrived. Pardon me, where are my manners? I am CiscoMan - the comforting presence at the top of a large number of Cisco documents such as configuration and installation notes for Catalyst switches. I’m here to tell you that everything is going to be alright - that it’s okay to be scared. CiscoMan is here to help you out. Believe me, you’re not my first.

Playing hide and seek with JunOS

JunOS has some commands which either are unsupported, do not work in platform you're using, undocumented or unnecessary for vast majority of operators, these commands are hidden in the UI so they are only accessible if you know what (and more importantly why) you want (them).

Today I was searching for a way to quiet my SRX210HE-POE as it makes annoyingly lot noise, I failed to find configuration way to force it to normal spinning speed, but I did notice that CLI exposes hidden commands. I've actually found same in IOS several years back and wrote little perl script to search for them (exec only), it proved bad idea as several of them purposely crash your system. If you want to dig deeper, in IOS difference is incomplete and invalid command, however actually some commands are truly hidden in IOS, particular example is the toggle for unsupported transceivers.

Neither the JunOS nor IOS issue are something you can blame vendor at, vendor isn't trying to stop you from using them, they just want to be very clear that if you use them TAC ain't go your back.

The code is quick 2h hack (running it takes longer, but I'm certain Continue reading

Where Did All The Time Go?!?

I woke up this morning and realized that I had broken my 3-week long streak of blog posting, where I had gotten in the habit of making a new post nearly every day of the week. Since I have been unemployed for the past three weeks and my primary priority was to study for the CCNP, it was easy to come up with new blog content at a relatively rapid pace.

Where Did All The Time Go?!?

I woke up this morning and realized that I had broken my 3-week long streak of blog posting, where I had gotten in the habit of making a new post nearly every day of the week. Since I have been unemployed for the past three weeks and my primary priority was to study for the CCNP, it was easy to come up with new blog content at a relatively rapid pace.

BGP: Weight and Local-Preference

It’s important to remember that since BGP is the routing protocol of the internet, there are quite a few attributes that it uses to give preference to a single route out of several redundant paths to a given destination. I was recently contemplating several of these and it occurred to me that two of these attributes in particular are pretty similar. I’d like to compare and contrast them and give reasoning for situations that call upon one or the other.

BGP: Weight and Local-Preference

It’s important to remember that since BGP is the routing protocol of the internet, there are quite a few attributes that it uses to give preference to a single route out of several redundant paths to a given destination. I was recently contemplating several of these and it occurred to me that two of these attributes in particular are pretty similar. I’d like to compare and contrast them and give reasoning for situations that call upon one or the other.

EIGRP Unequal-Cost Load-Balancing

In a previous post, I explored the basics of IP routing, and in the process, we discovered an interesting default feature of OSPF. When there were two OSPF routes in the routing table to a network, and both routes had the same cost, the router performed load balancing between the two. Take, for instance, the following route: 172.16.2.0 [110/12] via 1.1.1.13, 00:09:24, FastEthernet0/0 [110/12] via 1.1.1.2, 00:09:24, FastEthernet0/1 In this example, every packet sent would take one of two routes.

EIGRP Unequal-Cost Load-Balancing

In a previous post, I explored the basics of IP routing, and in the process, we discovered an interesting default feature of OSPF. When there were two OSPF routes in the routing table to a network, and both routes had the same cost, the router performed load balancing between the two. Take, for instance, the following route: 172.16.2.0 [110/12] via 1.1.1.13, 00:09:24, FastEthernet0/0 [110/12] via 1.1.1.2, 00:09:24, FastEthernet0/1 In this example, every packet sent would take one of two routes.

What’s a Steiner Tree?

Any of you who have worked with VPLS or NG-MVPNs are likely already familiar with using Point-to-Multipoint (P2MP) LSPs to get traffic from a single ingress PE to multiple egress PEs.  The reason that P2MP LSPs are desired in these cases is that it can reduce unnecessary replication by doing so only where absolutely required, for example where a given P2MP LSP must diverge in order to reach two different PEs.

However, typically the sub-LSPs which are part of a given P2MP LSP traverse the shortest-path from ingress to egress based on whatever user defined constraints have been configured.  While this is fine for many applications, additional optimizations might be required such that additional bandwidth savings can be realized.

We will take a look at something called a Steiner-Tree which can help the network operator to realize these additional savings, when warranted, reducing the overall bandwidth used in the network and fundamentally changing the way in which paths are computed.

Let's start by taking a look at a simple example in which RSVP is used to signal a particular P2MP LSP, but no constraints are defined.  All the links in this network have a metric of 10. Continue reading

Changing Gears: Virtual Networking

When it came to networking, my university classes didn’t teach me much more than the basics of network infrastructure, and a little bit of route/switch. Now that I’ve graduated, I continue to learn as I strive for the next steps. So far, it’s been CCNP ROUTE, since I knew I wanted to go for it soon after CCNA. Because of this trend, I’ve been pretty devoted to routing, with a small segway into security as I obtained my Security+ certification.

Changing Gears: Virtual Networking

When it came to networking, my university classes didn’t teach me much more than the basics of network infrastructure, and a little bit of route/switch. Now that I’ve graduated, I continue to learn as I strive for the next steps. So far, it’s been CCNP ROUTE, since I knew I wanted to go for it soon after CCNA. Because of this trend, I’ve been pretty devoted to routing, with a small segway into security as I obtained my Security+ certification.

Review: Ethernet Fabric Whitepaper by Brocade

I’ve been pretty deep into my CCNP ROUTE studies, which is mostly WAN and routing protocols, so I haven’t had much chance to dive any deeper when it comes to datacenter stuff. I’d seen several ads for the Brocade whitepaper titled “Five Reasons Classic Ethernet Switches Won’t Support the Cloud” and I figured I’d give it a shot. The whitepaper is not long, and is quite easy to understand. It contrasted well between traditional switches and Ethernet Fabric switches in terms of supporting SaaS application requirements, pointing out that while STP is a necessary evil in a classic Ethernet switched infrastructure, it creates several problems for “the cloud”.

Review: Ethernet Fabric Whitepaper by Brocade

I’ve been pretty deep into my CCNP ROUTE studies, which is mostly WAN and routing protocols, so I haven’t had much chance to dive any deeper when it comes to datacenter stuff. I’d seen several ads for the Brocade whitepaper titled “Five Reasons Classic Ethernet Switches Won’t Support the Cloud” and I figured I’d give it a shot. The whitepaper is not long, and is quite easy to understand. It contrasted well between traditional switches and Ethernet Fabric switches in terms of supporting SaaS application requirements, pointing out that while STP is a necessary evil in a classic Ethernet switched infrastructure, it creates several problems for “the cloud”.

EIGRP over NBMA Networks

Commonly used routing protocols like OSPF and EIGRP utilize multicast addresses to distribute hello messages, and routing information. In a broadcast-capable layer 2 network like Ethernet, EIGRP will send a packet containing a hello message to the address 224.0.0.10, which results in a corresponding layer2 destination 01:00:5e:00:00:0a. Something I used to wonder about all the time is how routing protocols work over Non-Broadcast Multi-Access networks like Frame Relay. In these networks, there are no broadcasts or multicasts.

EIGRP over NBMA Networks

Commonly used routing protocols like OSPF and EIGRP utilize multicast addresses to distribute hello messages, and routing information. In a broadcast-capable layer 2 network like Ethernet, EIGRP will send a packet containing a hello message to the address 224.0.0.10, which results in a corresponding layer2 destination 01:00:5e:00:00:0a. Something I used to wonder about all the time is how routing protocols work over Non-Broadcast Multi-Access networks like Frame Relay. In these networks, there are no broadcasts or multicasts.

Vyatta OSPF Designated Router Concepts

I was inspired by a (relatively) recent post by Jeremy Stretch at Packetlife.net that explained OSPF designated router configuration in Cisco IOS. I’d like to go into a bit more detail regarding the need for a designated router, and explore the same configuration steps on the Vyatta Core platform. I’ve already shown how easy it is to integrate a Cisco router with a Vyatta router using OSPF, so you can use a mix of Cisco and Vyatta gear if you wish.