Friday, March 23, 2012
Thursday, March 22, 2012
Monday, March 19, 2012
#Cisco #EIGRP ... your fathers routing protocol
So many current things have roots deep in the past... take EIGRP.
You have to time travel back to when routers were just starting to come into vogue in enterprise networks. Back to the period of 1990-1996 when most enterprise networks were a hodgepodge of protocols: ipx, ip, appletalk, decnet, sna, and others. In fact...back then...IP was typically only used by engineering departments within companies...typically as Sun workstations were popular for autocad.
There were two dominant router manufacturers in this small but growing market: Wellfleet & Cisco. Both were appliance based..but definitely different architectures. Wellfleet used a sleek, but buggy, operations tool called Site Manager. Cisco was just CLI based. But..the real big difference that stood out was that Wellfleet was a multi-processor architecture when you got to their chassis based solutions, like the BCN. Cisco was single processor across the product line. Because of the multi-proc architecture, Wellfleet was quite good at running OSPF. Processors were alot slower compared to now....based in 10's of megahertz...not several gigahertz like they are today. If Cisco was going to beat Wellfleet, they were going to have to come up with something clever to make the most of their weak hardware.
The issue is kinda obvious..but I'll point it out. OSPF is a link state routing protocol. Which means that every router builds a view of the network based on the state of each link. Each router understands whats up and what is down, it sees multiple paths between points, it understands how much bandwidth on those links. The exchange that goes on between routers...is an exchange of links. This is key.
EIGRP is a distance vector routing protocol. This means that routers get their view of the network from other routers, they dont compute their own view. The exchange that goes on between routers is the change of routing tables. Key difference.
To sum it up, each OSPF router forms its own best view of the network. EIGRP is based on "heresay", or rumor. It trusts the routes another router gives to it.
That means in a OSPF network, each node has to be able to calculate the full routing table. In a EIGRP network, once I receive my picture of the network from other routers, i dont need to calculate anything. I just need to decide what path I take if I have multiple routes for the same destination.
I like to think of analogies to more easily describe things. Say you're driving in a car from Milwaukee to Chicago. You could ask someone for directions and they could say, get on I94 and take that south. It would work, it would get you there. But, you didnt use any data to come up with how to get there. There could have been a shorter way, a way with less traffic, a way with higher speed roads. Or, you could have gotten out your smartphone with Google Maps on it, it would have allowed you to figure out the best route to Chicago based on multiple factors including how much traffic was on the freeway. Possibly avoiding that traffic jam on 294. Which would you choose?
OSPF is more computational, EIGRP is less computational. But, this isnt 1993 any longer. Routing devices (whether a router or a l3 switch) have multi-processors and high speed ASICs. Computing Dykstra on hundreds of routes and doing it in milliseconds is easy. So, why run EIGRP? Cisco told you so? Cisco convinced you that EIGRP is actually Link State? Cisco convinced you that EIGRP is just easy and it scales?
EIGRP is not link state, its distance vector. The state of links are not exchanged. Each router does not calculate its own routing table. The only thing advanced that EIGRP does is pick a feasible successor. There are few other things different about EIGRP than other distance vector protocols, but that doesnt make EIGRP a link state protocol.
EIGRP does have issues with scaling. Get into a large EIGRP network and you'll find that routers often get into a condition called Stuck In Active. If you get into larger networks, you'll find that to make EIGRP scale, you need to break up the network into multiple parts and seperate them with protocols like BGP. Its common, we see it often.
True, EIGRP is fairly easy to run. But, OSPF is not that hard. Even someone juggling multiple IT hats can get a OSPF network up and running. A lot of small networks might be run with just one area....which that is no harder than setting up EIGRP. One other fallacy about OSPF is that it you have to keep area's small....which leads to that factor of complexity that folks are worried about. Actually, that is a old rule that is based on hardware long ago that is now in a garbage compactor. In fact, talking with one of my co-workers, Khalid Raza, area's can be sized quite large...with no given rules as to their size. He's seen networks with areas with 400 routers in them.
There's no downside to OSPF or for that matter IS-IS. They are supported by multiple vendors, they scale, they're easy to use. EIGRP is only supported by one company. It has scaling issues. It gives you a view of the network that is not optimized. Its based on 1993 assumptions of networks.
You can do better.
You have to time travel back to when routers were just starting to come into vogue in enterprise networks. Back to the period of 1990-1996 when most enterprise networks were a hodgepodge of protocols: ipx, ip, appletalk, decnet, sna, and others. In fact...back then...IP was typically only used by engineering departments within companies...typically as Sun workstations were popular for autocad.
There were two dominant router manufacturers in this small but growing market: Wellfleet & Cisco. Both were appliance based..but definitely different architectures. Wellfleet used a sleek, but buggy, operations tool called Site Manager. Cisco was just CLI based. But..the real big difference that stood out was that Wellfleet was a multi-processor architecture when you got to their chassis based solutions, like the BCN. Cisco was single processor across the product line. Because of the multi-proc architecture, Wellfleet was quite good at running OSPF. Processors were alot slower compared to now....based in 10's of megahertz...not several gigahertz like they are today. If Cisco was going to beat Wellfleet, they were going to have to come up with something clever to make the most of their weak hardware.
The issue is kinda obvious..but I'll point it out. OSPF is a link state routing protocol. Which means that every router builds a view of the network based on the state of each link. Each router understands whats up and what is down, it sees multiple paths between points, it understands how much bandwidth on those links. The exchange that goes on between routers...is an exchange of links. This is key.
EIGRP is a distance vector routing protocol. This means that routers get their view of the network from other routers, they dont compute their own view. The exchange that goes on between routers is the change of routing tables. Key difference.
To sum it up, each OSPF router forms its own best view of the network. EIGRP is based on "heresay", or rumor. It trusts the routes another router gives to it.
That means in a OSPF network, each node has to be able to calculate the full routing table. In a EIGRP network, once I receive my picture of the network from other routers, i dont need to calculate anything. I just need to decide what path I take if I have multiple routes for the same destination.
I like to think of analogies to more easily describe things. Say you're driving in a car from Milwaukee to Chicago. You could ask someone for directions and they could say, get on I94 and take that south. It would work, it would get you there. But, you didnt use any data to come up with how to get there. There could have been a shorter way, a way with less traffic, a way with higher speed roads. Or, you could have gotten out your smartphone with Google Maps on it, it would have allowed you to figure out the best route to Chicago based on multiple factors including how much traffic was on the freeway. Possibly avoiding that traffic jam on 294. Which would you choose?
OSPF is more computational, EIGRP is less computational. But, this isnt 1993 any longer. Routing devices (whether a router or a l3 switch) have multi-processors and high speed ASICs. Computing Dykstra on hundreds of routes and doing it in milliseconds is easy. So, why run EIGRP? Cisco told you so? Cisco convinced you that EIGRP is actually Link State? Cisco convinced you that EIGRP is just easy and it scales?
EIGRP is not link state, its distance vector. The state of links are not exchanged. Each router does not calculate its own routing table. The only thing advanced that EIGRP does is pick a feasible successor. There are few other things different about EIGRP than other distance vector protocols, but that doesnt make EIGRP a link state protocol.
EIGRP does have issues with scaling. Get into a large EIGRP network and you'll find that routers often get into a condition called Stuck In Active. If you get into larger networks, you'll find that to make EIGRP scale, you need to break up the network into multiple parts and seperate them with protocols like BGP. Its common, we see it often.
True, EIGRP is fairly easy to run. But, OSPF is not that hard. Even someone juggling multiple IT hats can get a OSPF network up and running. A lot of small networks might be run with just one area....which that is no harder than setting up EIGRP. One other fallacy about OSPF is that it you have to keep area's small....which leads to that factor of complexity that folks are worried about. Actually, that is a old rule that is based on hardware long ago that is now in a garbage compactor. In fact, talking with one of my co-workers, Khalid Raza, area's can be sized quite large...with no given rules as to their size. He's seen networks with areas with 400 routers in them.
There's no downside to OSPF or for that matter IS-IS. They are supported by multiple vendors, they scale, they're easy to use. EIGRP is only supported by one company. It has scaling issues. It gives you a view of the network that is not optimized. Its based on 1993 assumptions of networks.
You can do better.
#Cisco cant make up its mind on #SDN and #OpenFlow
Poor Cisco...so distraught. Its always is about whats best for Cisco... or maybe just those Cisco execs that matter.
All the rage, because of HP, is OpenFlow which is a software defined network (sdn) technology. Customers are starting to talk about it...some are doing trials. Everyone but Cisco has got on the bandwagon. Problem is... OpenFlow wasnt invented at Cisco and therefore they cant put their proprietary vendor lockin spin on it.
Yes, Cisco does have LISP which is a SDN technology...but for some reason, they're not pushing it hard.
Now, they're funding a startup:
http://www.networkworld.com/news/2012/031612-cisco-insiemi-257381.html?hpg1=bn
Its really all about protecting revenue flow of certain product lines. Thats why you're going to see Cisco do things that are in their best interest, not customers.
All the rage, because of HP, is OpenFlow which is a software defined network (sdn) technology. Customers are starting to talk about it...some are doing trials. Everyone but Cisco has got on the bandwagon. Problem is... OpenFlow wasnt invented at Cisco and therefore they cant put their proprietary vendor lockin spin on it.
Yes, Cisco does have LISP which is a SDN technology...but for some reason, they're not pushing it hard.
Now, they're funding a startup:
http://www.networkworld.com/news/2012/031612-cisco-insiemi-257381.html?hpg1=bn
Its really all about protecting revenue flow of certain product lines. Thats why you're going to see Cisco do things that are in their best interest, not customers.
Thursday, March 15, 2012
#khalidraza speaking with one of customers in milwaukee
Khalid who works at hp is one of three cisco certified architects in the world
Tuesday, March 13, 2012
#Harris gets out of #cloud data center business... business plan not supportable with #VCE
http://www.datacenterknowledge.com/archives/2012/02/28/harris-exits-cloud-hosting-will-sell-data-center/
#HP #Wisconsin Spring Update...in a city near you
One seminar...all technologies! Get updates on printing, desktop/notebooks, servers, storage, network, and services:
http://hpbroadband.com/program.aspx?key=PLJROQDIJG
http://hpbroadband.com/program.aspx?key=PLJROQDIJG
#Dell to buy #Sonicwall.. not good for customers
Dell continues to hobble together a network practice..peice by peice. First..Force10, now Sonicwall.
They're still missing routers, a really good network management system, and wireless.
I think when they are done... customers will be able to buy multiple solutions from one vendor... but they'll end up with a solution that is mired in multiple operating systems and dis-contiguous feature sets!
http://www.networkworld.com/news/2012/031312-dell-sonicwall-257213.html?hpg1=bn
They're still missing routers, a really good network management system, and wireless.
I think when they are done... customers will be able to buy multiple solutions from one vendor... but they'll end up with a solution that is mired in multiple operating systems and dis-contiguous feature sets!
http://www.networkworld.com/news/2012/031312-dell-sonicwall-257213.html?hpg1=bn
#HPN Routing Preferences (aka Administative Distance)
If you're looking to understand the Adminstrative Distance on HP... its called Routing Preference in Comware.
Here's the breakdown:
Routing approach Preference
DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 255
EBGP 255
UNKNOWN 256
If you want to change the preference for static routes:
ip route-static default-preference default-preference-value
If you want to change the preference for rip routes:
rip {process id}
preference [ route-policy route-policy-name ] value
If you want to change the preference for ospf routes:
ospf {process id}
preference [ ase ] [ route-policy route-policy-name ] value
If you want to change the preference for ISIS routes:
isis {process id}
preference [ ase ] [ route-policy route-policy-name ] value
If you want to change the preference for BGP routes:
bgp as-number
preference { external-preference internal-preference local-preference | route-policy route-policy-name }
Here's the breakdown:
Routing approach Preference
DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 255
EBGP 255
UNKNOWN 256
If you want to change the preference for static routes:
ip route-static default-preference default-preference-value
If you want to change the preference for rip routes:
rip {process id}
preference [ route-policy route-policy-name ] value
If you want to change the preference for ospf routes:
ospf {process id}
preference [ ase ] [ route-policy route-policy-name ] value
If you want to change the preference for ISIS routes:
isis {process id}
preference [ ase ] [ route-policy route-policy-name ] value
If you want to change the preference for BGP routes:
bgp as-number
preference { external-preference internal-preference local-preference | route-policy route-policy-name }
Friday, March 9, 2012
#HP #MSR #L2TP router config sample
#
l2tp enable
#
domain default enable system
#
ike local-name h3c
#
acl number 2000
description NAT OUTBOUND ACL
rule 0 permit source 192.168.1.0 0.0.0.255
rule 10 permit source 172.16.1.0 0.0.0.255
#
domain system
authentication ppp local
access-limit disable
state active
idle-cut disable
self-service-url disable
ip pool 1 10.10.10.5 10.10.10.10
#
ike peer remote
exchange-mode aggressive
pre-shared-key simple sprig1234
id-type name
remote-name remote
#
ipsec proposal remote
#
ipsec policy remote 1 isakmp
ike-peer remote
proposal remote
#
local-user hp
password simple hphp1234
authorization-attribute level 1
service-type ppp
#
l2tp-group 1
mandatory-chap
undo tunnel authentication
allow l2tp virtual-template 0
tunnel name remote
#
interface Virtual-Template0
ppp authentication-mode chap domain system
remote address pool 1
ip address 10.10.10.254 255.255.255.0
#
interface NULL0
#
interface GigabitEthernet0/0
port link-mode route
description LAN_ZONE_INTERFACE
ip address 192.168.1.254 255.255.255.0
#
interface GigabitEthernet0/5
port link-mode route
nat outbound 2000
ip address dhcp-alloc
ipsec policy remote
#
Wednesday, March 7, 2012
Tuesday, March 6, 2012
#Gartner posts new report on #Cisco.. a must read
While I cant copy n paste that the report says...if you're a subscriber, you should download. The link is:
http://my.gartner.com/portal/server.pt?open=512&objID=249&mode=2&PageID=864059&resId=1938914&ref=Alerts
or.. its report id: G00225511
They lay out the risks fairly succinctly.
http://my.gartner.com/portal/server.pt?open=512&objID=249&mode=2&PageID=864059&resId=1938914&ref=Alerts
or.. its report id: G00225511
They lay out the risks fairly succinctly.
#Openflow training
Care to learn more about OpenFlow and Software Defined Networks?
check out ipspace.net's sessions:
http://demo.ipspace.net/bin/list?id=OpenFlow
check out ipspace.net's sessions:
http://demo.ipspace.net/bin/list?id=OpenFlow
Monday, March 5, 2012
Is #BRCD dead money?
Seems that Blackstone has walked away...
http://www.bloomberg.com/news/2012-02-17/blackstone-said-to-end-talks-to-buy-brocade-communications-amid-stock-gain.html
http://www.bloomberg.com/news/2012-02-17/blackstone-said-to-end-talks-to-buy-brocade-communications-amid-stock-gain.html
Q of the day? How real is the 10K number of #Cisco #UCS customers?
Congrats to Cisco by going from zero to 10,000 UCS customers in a fairly short amount of time. It is fairly amazing.
But... what I would like to know... is how many of those customers are using UCS for real compute purposes...or how many just switch to UCS to power their Cisco voice infrastructure?
Is Cisco counting that base of customers when it tallies? I'd love to hear if their market share is based on this captive audience.
But... what I would like to know... is how many of those customers are using UCS for real compute purposes...or how many just switch to UCS to power their Cisco voice infrastructure?
Is Cisco counting that base of customers when it tallies? I'd love to hear if their market share is based on this captive audience.
#HP #IMC v5.1 upgrade tip
Hey
If you are about to upgrade your IMC to v5.1. One thing to point out... if you have QOS Policy Manager... the sub-component SLA Manager has not been upgraded to v5.1 yet. It will not be out until v5.1 SP1 due out in the next quarter. So...to do the upgrade, you need to deinstall the SLA Manager.
Our install manager in IMC is very smart and it wont let you startup IMC unless all of the software dependencies are met.
If you are about to upgrade your IMC to v5.1. One thing to point out... if you have QOS Policy Manager... the sub-component SLA Manager has not been upgraded to v5.1 yet. It will not be out until v5.1 SP1 due out in the next quarter. So...to do the upgrade, you need to deinstall the SLA Manager.
Our install manager in IMC is very smart and it wont let you startup IMC unless all of the software dependencies are met.
Are you up to speed on Dr. Multicast? #MCMD
http://www.cs.cornell.edu/projects/quicksilver/public_pdfs/dr-multicast-tr.pdf
Scalable multicast for data centers
Scalable multicast for data centers
Friday, March 2, 2012
#LOL Its always funny to read old proclamations about technology
Here's an article from four years ago that proclaims that iSCSI is dead and FCOE is going to replace it.
Time always does tell!
http://www.theregister.co.uk/2008/10/15/fcoe_io_kill_iscsi/
Time always does tell!
http://www.theregister.co.uk/2008/10/15/fcoe_io_kill_iscsi/
#Save $300 on #HP #Discover
If you use the following registration code: PSLS
you'll save $300 when signing up for HP Discover. Go here:
www.hp.com/go/discover
to sign up! There over 800 different sessions currently to go to!!!!
you'll save $300 when signing up for HP Discover. Go here:
www.hp.com/go/discover
to sign up! There over 800 different sessions currently to go to!!!!
Subscribe to:
Posts (Atom)