Too Long

Sorry about no posts in forever, life/work have been crazy.

I did pass my CCNP-Route so I might have a few posts from notes to bring, but will probably start focusing on SWITCH topics.

Let me know if anyone has a topic request.

dt-lacp Distributed Trunking

Distributed Trunking -

Now everyone understands how two switches connected logically (stacked) can balance an aggregate link between them with a shared logical backplane, as cisco does, but what about HP who doesn't have stacked switches, where just a few higher end switches have the ability to do distributed trunking. A server (as it is not supported for switch to switch) can connect to two separate switches and create a single LACP trunk to both.

*note - the two switches must be directly connected, and it is a little unclear but it sounds like they have to have a dedicated link between them as the dt-trunk link, apart from the regular link. (now this does not have to be aggregated, could be a single gig connection, but as you will see in a moment it should be of equivalent bandwidth to each switch's lacp link.

Now this seems simple but what happens under the hood? With HP's usual lack of documentation it took me a while to dig up, but basically, create a non-negotiating trunk. (eg. lacp auto will not work), and connect the server. The server sends a frame to switch A which learns the mac and forwards it to the destination. Switch B also learns the mac as being on switch A. Switch B receives a frame and, having learned the mac as being on switch A, forwards the frame to switch A to send to destination.

So in essence, you are creating redundancy, but as for doubling bandwidth, ALL traffic will proceed through a single switch so both the inter-switch link and EACH switch's core uplink must be able to support the full server lacp bandwidth, for all it's links.

Eg. Server has 2gigs to switch A and 2gigs to switch B. Switch A needs at minimum 2gigs to switch B. Switch A and Switch B both need at minimum 4 gigs up to the uplink/core. (assuming you want the server to have 4gigs of bandwidth to the core) This is of course on top of any other traffic the switches will be forwarding from other devices.

Of course spanning tree is going to have to block a link somewhere anyway, so all traffic forwarding through a single switch may be the expected outcome anyway.

Cheers!

Oh ya, the config:

ProCurve Switch 1(config)# switch-interconnect a1
ProCurve Switch 2(config)# switch-interconnect a1
 ProCurve Switch 2(config)# trunk b20-b21 trk99 dt-lacp
ProCurve Switch 1(config)# trunk c10-c11 trk99 dt-lacp

 and of course if you needed an aggregate link between switches, replace a1 with trk5 and add whatever ports you needed to trk5 just like a regular trunk port.

  show lacp distributed is your show command to see the lacp status of BOTH switches

IP Source Guard

So, after saying I would post about IP source guard in my DHCP Snooping Post I neglected to post much of anything for six months BUT I'm back to fulfill my promise.

IP source guard is basically a dynamic per port access list that will be applied to make sure the device is using the IP address (and mac address if configured) that the computer received during it's DHCP handshake.


As mentioned in the previous article, DHCP snooping is going to keep track of what IP address the device gets from the server.  Then IP source guard ensures that address, stored in the dhcp snooping database, is the only IP allowed to communicate out the port, thereby defeating IP spoofing and some man in the middle attacks.

Picture a malicious user who connects to the network, and receives an IP address.  They then listen to broadcast traffic and ARPs and determine another user's IP/Mac address.  The malicious user could then either send out packets with the neighboring device's IP and pretend to be them, possibly bypassing ACLs that grant the attackee extra access.  Attack two could be that the malicious user simply responds to request's by using the gateway's IP address and appears to be legitimate traffic.

Both of these could be mitigated by IP source guard, as the malicious user, sending any packets out with an IP (or mac) not included in the dhcp snooping database will be dropped.

NOTE* If you configure source guard on a port that doesn't have an entree either learned dynamically by dhcp snooping or manually entered in the ip source binding table, all packets will be dropped

Source guard is not allowed on routed interfaces or etherchannels



Configuration:

Step one -
A. ensure dhcp snooping is enabled on the vlan you intend to use IP source guard on (or you have manually entered all IP/Mac bindings in the ip source binding table)
B. If you enable IP source guard on a trunk interface (multiple vlans) then all vlans are filtered, ensure dhcp snooping is enabled for ALL vlans on the trunk.

Step two -
Determine if some or all of your addresses need to be manually entered:


ip source binding mac-address vlan vlan-id ip-address inteface interface-id


Step three -
Determine if you just want to use source guard based on IP addresses, or both IP and Mac addresses.  If you want to check Mac addresses as well, ensure your DHCP server supports option 82.

interface interface-id

          For just checking IP addresses:

               ip verify source

          For both IP and Mac addresses:

               ip verify source port-security


Step Four -
Verify Config

show ip verify source [interface interface-id]

Verify Bindings

show ip source binding


Step Five -
Save if everything looks good

wri mem

(or if you are studying for an exam)
copy running-config startup-config

Curious what the Openflow stuff is you are hearing all over? Check Out Ivan Pepelnjak's links to recorded versions of OPENFLOW AND SOFTWARE DEFINED NETWORKING 101 type introduction session on the technology causing all the buzz. Interesting stuff, even if I am very very weary of taking the "brains" out of my switches and placing it in a controller or software situation, if it works well it could very well change the hole concept of networking as we know it.

OSPF Feasible Successors

OSPFv2 Loop-Free Alternate Fast Reroute - Once OSPF has calculated SPF and installed routes in the routing table, it calculates a successor route to destinations, much as EIGRP does. Greatly reduce your down time during re-convergence.

You can find it in the Cisco 15.1 release notes.

 Cisco - Yep
Juniper - Yep
HP - As usual, they probably will get around to it in a couple years...