Pretty straight forward question....L3 device with equal cost paths to destination.  Both next hops are equal distance in terms of AD and metric (think shared segment with 3 devices).  Traceroute will show both next hops when in the reply.  Now, how does the router determine the first probe to send to?  And how do you change this behavior?    For example, traceroute 8.8.8.8 will send probe to both 10.1.1.1 and 10.1.1.2 (equal cost next hops).  Now, was 10.1.1.1 the first probe sent simply because its lower?  How do you change this behavior such that 10.1.1.2 will be sent the first probe first? Reply.... 1    - 10.1.1.1         10.1.1.2     ... View more

Im having issues understanding a way to get around the a dual site, dual ISP scenario with firewalls/NAT.  A couple issues that come to play:      -outbound-if each site were to route out of their local firewall with their local Public IP, then no worries.  If you have a shared Public IP block between both ISPs, then traffic might route back to the other ISP and your other site, eventually hitting your other site and firewall.  Without a session already created, the firewall would drop the packets      - inbound - how do you protect for static services such as a web server or email.  If your mx record is pointing to ISP1 and ISP1 goes down, yea you could have another record point to your other public IP.  However, many are going to have this record cached so they will try to be going to your ISP1 public ip for your smtp.  Even if its not cached, how will your outside DNS server or a hosted DNS solution know that site is down?       One could argue that you could have another link between sites, where all traffic would be routed to the main firewall (unless it went down), but then you have all inbound traffic going to one site/one firewall, not to mention you have to come up with this other link between them. Surely, there has to be a solution to this. ... View more

First, to verify are vn-link and VM-fex one in the same and simply mean you are using vntagging to extend the vnic to the actual VM, not the host. Two, UCS inherently is able to create vnics from service profiles that can then be applied to blades.  This form of vnics is again native to ucs.  These vnics however arent vm vnics but rather host vnics that in the case of esxi are used simply for uplinks from your VS. This brings up the question.  Can these inherent UCS vnics be extended further to the VMs instead of to the esxi hosts.  Is this actually what vn-link is doing? Or is there a difference between  server (host) vnics and vm vn-link vnics.  If this is the case though, then why does all vn-link documentation point at needing a palo physical nic on your blade when UCS can create vnics inherently.  The documentation also says the palo nics are also the only physical nics that support vnics yet UCS can do this anyways on any blades.  Why do you need the palo alto if you have ucs? ... View more

GSS is used to load balancing/redundancy method that can be used if you have two different sites and two public ip blocks.  However, I'm not quite understanding how GSS accomplishes this based on a couple of issues. Even with GSS, arent we still relying on the global DNS to provide redundancy?  In other words, if we register a GSS as our authoritative name servers instead of a true DNS servers so they can do the load balancing/failover based on their configurations/algorithms, its still the global DNS servers that determine which GSS to go to for primary or secondary GSS.  Hence, take an example where I have two datacenters and two different ISPs.   I point everything to my primary GSS at ISP1 to handle the load balancing of dns requests, whether it does it itself or redirects it to another GSS at datacenter2 on ISP2.  That primary datacenter loses connection and hence that primary GSS becomes unresponsive.  The secondary global DNS record would then point to the secondary GSS at a secondary IP address.  The secondary GSS has been synced with the primary and everything is good to go.  However, if you notice we are relying on the global dns to failover to the secondary GSS.  The problem I see here and correct me if my understanding is wrong, the global dns will send the request to the primary, it wont receive a reply, then send the request to the secondary name server (GSS).  It will do this for every request. It wont know to stop querying the primary and start going to the secondary.  This creates a constant delay as it always try the primary first.  Another issue with this is many DNS servers have already cached our primary name server (primary GSS). and hence the cache has to be updated before they will send the request to the secondary name server( secondary GSS).  Again, this could create huge delays similar to te 24-48 hour delay when changing name server ip addresses. ... View more

ip source-guard seems like a real handy simple l2 port security feature, yet I hardly ever see or hear of anyone using it.  Is there a performance hit taken when enabling this feature or some other issues that arise?  I've seen port-security turned on more often than this feature and that can have a lot of complications.  However, there doesnt seem like there would be a lot of complications for source guard other than static devices. ... View more

When configuring a host port with private vlans, you specify it as a private vlan host port and then you do the association.  However, my question is there any changes on the actions of the ports if you configure the access vlan (switch access vlan x).  When doing a "show int x/x switchport", it shows the access vlan as either isolated or community, however the associate seems to be the real determinign factor to how communication is achieved.  For instance, lets vlan 10 is my primary, 11 my commun, 12 my isolated.  If I do sw mode private-vlan host, sw private-vlan assoc 10 11 on both of my ports, YET configure "sw access vlan 12" on the port, i get the below.  My two devices communicate which im assuming is because of the private vlan association.  All is working well.  However, does configuring the access vlan and does the line below access mode vlan"12 (isolated) mean anything? Administrative Mode: private-vlan host Operational Mode: private-vlan host Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 12 (isolated) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: 10 (VLAN00010) 11 (VLAN00011) Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk associations: none Administrative Mode: private-vlan host Operational Mode: private-vlan host Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 12 (isolated) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: 10 (VLAN00010) 11 (VLAN00011) Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk associations: none ... View more

I keep running into issues with MTU and TCP MTU, yet I'm not following why it causes so many problems ie.  For mpls, you need to decrease the MTU to account for the MPLS labels. ie.. For tunnel encapsulation (ipsec, GRE, etc), you need to decrease the mtu to account fro the additional overhead.. ie...BGP..if the mtu somewhere along the path is lower than what is negotiated, the peering will fail The logic makes sense on why to lower the mtu to prevent fragmentation. However, it would seem if these settings weren't set, the router/L3 device would just fragment.  Other than the extra processing power to reassemble, it would still seem like fragmentation wouldn't cause so many connectivity issues. If most hosts sent packets with the DF bit set, then I could easily see why fragmentation would cause issues.   Most packets dont have the df bit set though so fragmentation shouldnt cause an issue. ... View more