WAN ECMP to Nexus 7K

Hi,
I have a Nexus 7K deployment with dual layer3 to 7600 WAN routers. One 7K switch is root for all Vlans and HSRP primary for all Vlans which is my understanding of best practices. My question is -
Will the secondary Nexus 7K ever be used for WAN communications? Since S01 is the default gateway, wont all traffic always use the first switch? I've attached a diagram below. The design practices say to configure ECMP and that will ensure loadbalancing across all WAN uplinks, but I do not quite get it.... I would think I would need to split the HSRP primaries for SVIs across nexus switch1 and switch2 to achieve this.
I appreciate any insite into this configuration.
/r
Rob

In N7K, HSRP in the vPC VLANs will forward traffic to its up stream if there are ECMP. ARP request will be handled by the HSRP primary, while both HSRP active and standby router will forward traffic to its upstream if the route is equal cost.
Please take a look at this link vPC Layer 3 Interaction section
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c11-516396.html
HTH,
jerry

Similar Messages

Windows 2008 R2 on Cisco UCS B200M networking problems

This is driving me completely nuts. Let me start by saying I am new to blade servers and Cisco UCS. I did take an introduction class, and it seemed straight-forward enough. I have a chassis with two B200M blades, on which I am trying to configure two Windows 2008 R2 servers, which I will eventually make Hyper-V servers. This is all in a test environment, so I can do anything I want to on them.
Right now I have installed W2008 directly on hard disks on the B200M hardware.
The problem is this: even though I think I've configured the network hardware correctly, using the Cisco VIC driver software, I cannot get networking to work in any reliable way. I cannot even get ping to work consistantly. I can ping my local server address, but I cannot ping my gateway (HSRP address). When I try, I get a "Reply from 10.100.1.x: Destination host unreachable (x being each particular server's last octet). I CAN, however, ping the individual IP addresses of the core switches. I can also ping some, but not all, the other devices that share the servers' subnet. There are no errors being generated, the arp tables (for those devices I can ping) look good, netstat looks OK. But I cannot get outside the local subnet...
Except when I can.
There are times when I can get all the way out to the Internet, and I can download patches from Microsoft. When it works, it works as expected. But if I reboot the server, oftentimes networking stops working. Yet another reboot can get things going again. This happens even though I've made no changes to either the UCS configs or the OS.
I cannot figure out any reason when it works at some times and not at others. I've made sure I have a native VLAN set, I've tried pinning to specific ports on the Fabric Interconnects. There is just no rhyme or reason to it.
Anyone know of where I can look? I'm very familiar with Windows on stand-alone boxes (although it's no longer my area of expertise), and I manage a global WAN (BGP, OSPF, Nexus 7k, etc.) so I'm no dummy when it comes to networking, but I am utterly stumped on this one.

The problem was this: while the NICs on the blade server are called vNIC0 and vNIC1, Windows was calling vNIC1 "Local Area Connection" and vNIC0 "Local Area Connection 2". So what I configured on UCS did not match what I was configuring in Windows. Completely, utterly ridiculous.
Anyway, networking is working now without any issues. Thanks for you suggestion; it did get me looking in the right direction.

Routing issue in Nexus 7009 due to vPC or hsrp

we have two site's, on first site we have two nexus 7009 switches (Nexus A & Nexus B) and other site is remote site having two 6500 switches. (design attached)
we are using hsrp on nexus switches and Active is Nexus A for all vlan’s
From one of my remote site user's (user's are in vlan 30 ) are not able to communicate with nexus site vlan 20 specially if host in vlan 20 take forwarding path from nexus switch B,
I can ping the vlan 20 both physical address's and gateway (vlan 20 configured in both nexus switch and using HSRP) from vlan 30 which configured on remote site 6500 switch
ospf with area 0 is the routing protocol running between both site.
vlan 10 we are using as a management vlan on both nexus switch that building neighbore ship with WAN router, it's means wan router have two neighbors nexus A and nexus B, but nexus B building the neigbhorship via a Nexus A because from WAN router we have single link which is terminated on Nexus A,
there is one layer 2 switch between nexus A and WAN router, nexus A site that switch port in vPC because we are planning to pull second link later to nexus B.
All user's are connected with edge switch and edge switch have a redundant uplink to nexus A and B with vPC configured
After troubleshooting we observe that if user in vlan 20 wants to communicate with vlan 30 (remote site), traffic is taking Nexus B is forwarding path, then gets drops.
I run the tracert from pc its showing route till SVI on Nexus B after that seems packets not finding route. Even vlan 30 routes are available in the routing table of Nexus B. we don’t have any access-list and Firewall between this path.

Hi,
I suspect in your scenario that traffic is being dropped due to the characteristics of vPC, the routing table on Nexus-B may reflect the next-hop address for the destination IP, however if that next-hop address is the address of the Nexus-A off of VLAN 20 then it will be forwarded across the vPC peer-link, this breaks the convention.
When you attach a Layer 3 device to a vPC domain, the peering of routing protocols using a VLAN also carried on the vPC peer-link is not supported. If routing protocol adjacencies are needed between vPC peer devices and a generic Layer 3 device, you must use physical routed interfaces for the interconnection.
You can configure VLAN Interfaces for Layer 3 connectivity on the vPC peer devices to link to Layer 3 of the network for such applications as HSRP and PIM. However, Cisco recommend that you configure a separate Layer 3 link for routing from the vPC peer devices, rather than using a VLAN network interface for this purpose.
Take a look at the following URL, this article helps to explain the characteristics of vPC and routing over the peer-link:
http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/
Regards
Allan.
Hope you find this is helpful.
Sent from Cisco Technical Support iPad App

Ask the Expert: Different Flavors and Design with vPC on Cisco Nexus 5000 Series Switches

Welcome to the Cisco® Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about Cisco® NX-OS.
The biggest limitation to a classic port channel communication is that the port channel operates only between two devices. To overcome this limitation, Cisco NX-OS has a technology called virtual port channel (vPC). A pair of switches acting as a vPC peer endpoint looks like a single logical entity to port channel attached devices. The two devices that act as the logical port channel endpoint are actually two separate devices. This setup has the benefits of hardware redundancy combined with the benefits offered by a port channel, for example, loop management.
vPC technology is the main factor for success of Cisco Nexus® data center switches such as the Cisco Nexus 5000 Series, Nexus 7000 Series, and Nexus 2000 Series Switches.
This event is focused on discussing all possible types of vPC along-with best practices, failure scenarios, Cisco Technical Assistance Center (TAC) recommendations and troubleshooting
Vishal Mehta is a customer support engineer for the Cisco Data Center Server Virtualization Technical Assistance Center (TAC) team based in San Jose, California. He has been working in TAC for the past 3 years with a primary focus on data center technologies, such as the Cisco Nexus 5000 Series Switches, Cisco Unified Computing System™ (Cisco UCS®), Cisco Nexus 1000V Switch, and virtualization. He presented at Cisco Live in Orlando 2013 and will present at Cisco Live Milan 2014 (BRKCOM-3003, BRKDCT-3444, and LABDCT-2333). He holds a master’s degree from Rutgers University in electrical and computer engineering and has CCIE® certification (number 37139) in routing and switching, and service provider.
Nimit Pathak is a customer support engineer for the Cisco Data Center Server Virtualization TAC team based in San Jose, California, with primary focus on data center technologies, such as Cisco UCS, the Cisco Nexus 1000v Switch, and virtualization. Nimit holds a master's degree in electrical engineering from Bridgeport University, has CCNA® and CCNP® Nimit is also working on a Cisco data center CCIE® certification While also pursuing an MBA degree from Santa Clara University.
Remember to use the rating system to let Vishal and Nimit know if you have received an adequate response.
Because of the volume expected during this event, Vishal and Nimit might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure Community, under the subcommunity LAN, Switching & Routing, shortly after the event. This event lasts through August 29, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

Hello Gustavo
Please see my responses to your questions:
Yes almost all routing protocols use Multicast to establish adjacencies. We are dealing with two different type of traffic –Control Plane and Data Plane.
Control Plane: To establish Routing adjacency, the first packet (hello) is punted to CPU. So in the case of triangle routed VPC topology as specified on the Operations Guide Link, multicast for routing adjacencies will work. The hellos packets will be exchanged across all 3 routers and adjacency will be formed over VPC links
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/operations/n5k_L3_w_vpc_5500platform.html#wp999181
Now for Data Plane we have two types of traffic – Unicast and Multicast.
The Unicast traffic will not have any forwarding issues, but because the Layer 3 ECMP and port channel run independent hash calculations there is a possibility that when the Layer 3 ECMP chooses N5k-1 as the Layer 3 next hop for a destination address while the port channel hashing chooses the physical link toward N5k-2. In this scenario,N5k-2 receives packets from R with the N5k-1 MAC as the destination MAC.
Sending traffic over the peer-link to the correct gateway is acceptable for data forwarding, but it is suboptimal because it makes traffic cross the peer link when the traffic could be routed directly.
For that topology, Multicast Traffic might have complete traffic loss due to the fact that when a PIM router is connected to Cisco Nexus 5500 Platform switches in a vPC topology, the PIM join messages are received only by one switch. The multicast data might be received by the other switch.
The Loop avoidance works little different across Nexus 5000 and Nexus 7000.
Similarity: For both products, loop avoidance is possible due to VSL bit
The VSL bit is set in the DBUS header internal to the Nexus.
It is not something that is set in the ethernet packet that can be identified. The VSL bit is set on the port asic for the port used for the vPC peer link, so if you have Nexus A and Nexus B configured for vPC and a packet leaves Nexus A towards Nexus B, Nexus B will set the VSL bit on the ingress port ASIC. This is not something that would traverse the peer link.
This mechanism is used for loop prevention within the chassis.
The idea being that if the port came in the peer link from the vPC peer, the system makes the assumption that the vPC peer would have forwarded this packet out the vPC-enabled port-channels towards the end device, so the egress vpc interface's port-asic will filter the packet on egress.
Differences: In Nexus 5000 when it has to do L3-to-L2 lookup for forwarding traffic, the VSL bit is cleared and so the traffic is not dropped as compared to Nexus 7000 and Nexus 3000.
It still does loop prevention but the L3-to-L2 lookup is different in Nexus 5000 and Nexus 7000.
For more details please see below presentation:
https://supportforums.cisco.com/sites/default/files/session_14-_nexus.pdf
DCI Scenario: If 2 pairs are of Nexus 5000 then separation of L3/L2 links is not needed.
But in most scenarios I have seen pair of Nexus 5000 with pair of Nexus 7000 over DCI or 2 pairs of Nexus 7000 over DCI. If Nexus 7000 are used then L3 and L2 links are required for sure as mentioned on above presentation link.
Let us know if you have further questions.
Thanks,
Vishal

Nexus 5K L3 Design (Best Practice)

Hi All,
I have a few questions regarding the L3 capabilities of the 5548UPs.
We have the enterprise licensing with the L3 Daughter card and want to route from our 4500-X VSS' to our Nexus 5548s running version: 6.0(2)N2(3)
Our design is that our data center traffic is kept isolated in the DC. Our users will route across the 4500Xs to the DC to access the server host.
What we have is 4 physical links from our VSS stack to our Nexus cluster, with 2 cables from VSS1 to N5K-1 and 2 cables from VSS2 to N5K-2. See below:
VSS1 ---------------- 2 x --------------N5K-1
    |                                      |
    |                                    |
VS Link                         PeerLink
    |                                        |
    |                                        |
VSS2 ----------------2 x ---------------N5K-2
What we also have in our topology is an IPS between the VSS and Nexus switches to complicate the design.
Talking to my Sales Engineer he suggested putting the 4 links in a VPC using SVIs at each end and HSRP. Looking further into this it seems that this is a supported design but not a recommended design. I believe this works for Unicast forwarding but doesn't work for multicast according to this doc which is for version 5.1.3.
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/operations/interfaces/513_n1_1/ops_interfaces/L3_w_vpc_5500platform.html
From what I read, I believe the recommended way is to use point to Point routed links (/30s) x 4 and use ECMP to load balance the traffic.
The other thing I am looking into is finding out whether the IPS units allow asymmetric routing, eg if it comes in on port 1, and goes out on port 4, will it understand the flows? I'm waiting to hear back on this.
Would this assumption be correct to use the Point to Poink /30s and use ECMP? Is this what I should be doing rather than the SVIs across a vPC?
Do I need to have a separate L3 links between the N5K's?
Is there any other considerations I should be making?

Just had an update on the IPS units - they support asymetric routing, which is good news.

VPC on Nexus 5000 with Catalyst 6500 (no VSS)

Hi, I'm pretty new on the Nexus and UCS world so I have some many questions I hope you can help on getting some answers.
The diagram below is the configuration we are looking to deploy, that way because we do not have VSS on the 6500 switches so we can not create only one Etherchannel to the 6500s.
Our blades inserted on the UCS chassis have INTEL dual port cards, so they do not support full failover.
Questions I have are.
- Is this my best deployment choice?
- vPC highly depend on the management interface on the Nexus 5000 for the keep alive peer monitoring, so what is going to happen if the vPC brakes due to:
     - one of the 6500 goes down
          - STP?
          - What is going to happend with the Etherchannels on the remaining 6500?
     - the Management interface goes down for any other reason
          - which one is going to be the primary NEXUS?
Below is the list of devices involved and the configuration for the Nexus 5000 and 65000.
Any help is appreciated.
Devices
·         2 Cisco Catalyst with two WS-SUP720-3B each (no VSS)
·         2 Cisco Nexus 5010
·         2 Cisco UCS 6120xp
·         2 UCS Chassis
     -    4 Cisco B200-M1 blades (2 each chassis)
          - Dual 10Gb Intel card (1 per blade)
vPC Configuration on Nexus 5000
TACSWN01
TACSWN02
feature vpc
vpc domain 5
reload restore
reload restore   delay 300
Peer-keepalive   destination 10.11.3.10
role priority 10
!--- Enables vPC, define vPC domain and peer   for keep alive
int ethernet 1/9-10
channel-group 50   mode active
!--- Put Interfaces on Po50
int port-channel 50
switchport mode   trunk
spanning-tree port   type network
vpc peer-link
!--- Po50 configured as Peer-Link for vPC
inter ethernet 1/17-18
description   UCS6120-A
switchport mode   trunk
channel-group 51   mode active
!--- Associates interfaces to Po51 connected   to UCS6120xp-A
int port-channel 51
swithport mode   trunk
vpc 51
spannig-tree port   type edge trunk
!--- Associates vPC 51 to Po51
inter ethernet 1/19-20
description   UCS6120-B
switchport mode   trunk
channel-group 52   mode active
!--- Associates interfaces to Po51 connected   to UCS6120xp-B
int port-channel 52
swithport mode   trunk
vpc 52
spannig-tree port   type edge trunk
!--- Associates vPC 52 to Po52
!----- CONFIGURATION for Connection to   Catalyst 6506
Int ethernet 1/1-3
description   Cat6506-01
switchport mode   trunk
channel-group 61   mode active
!--- Associate interfaces to Po61 connected   to Cat6506-01
Int port-channel 61
switchport mode   trunk
vpc 61
!--- Associates vPC 61 to Po61
Int ethernet 1/4-6
description   Cat6506-02
switchport mode   trunk
channel-group 62   mode active
!--- Associate interfaces to Po62 connected   to Cat6506-02
Int port-channel 62
switchport mode   trunk
vpc 62
!--- Associates vPC 62 to Po62
feature vpc
vpc domain 5
reload restore
reload restore   delay 300
Peer-keepalive   destination 10.11.3.9
role priority 20
!--- Enables vPC, define vPC domain and peer   for keep alive
int ethernet 1/9-10
channel-group 50   mode active
!--- Put Interfaces on Po50
int port-channel 50
switchport mode   trunk
spanning-tree port   type network
vpc peer-link
!--- Po50 configured as Peer-Link for vPC
inter ethernet 1/17-18
description   UCS6120-A
switchport mode   trunk
channel-group 51   mode active
!--- Associates interfaces to Po51 connected   to UCS6120xp-A
int port-channel 51
swithport mode   trunk
vpc 51
spannig-tree port   type edge trunk
!--- Associates vPC 51 to Po51
inter ethernet 1/19-20
description   UCS6120-B
switchport mode   trunk
channel-group 52   mode active
!--- Associates interfaces to Po51 connected   to UCS6120xp-B
int port-channel 52
swithport mode   trunk
vpc 52
spannig-tree port   type edge trunk
!--- Associates vPC 52 to Po52
!----- CONFIGURATION for Connection to   Catalyst 6506
Int ethernet 1/1-3
description   Cat6506-01
switchport mode   trunk
channel-group 61   mode active
!--- Associate interfaces to Po61 connected   to Cat6506-01
Int port-channel 61
switchport mode   trunk
vpc 61
!--- Associates vPC 61 to Po61
Int ethernet 1/4-6
description   Cat6506-02
switchport mode   trunk
channel-group 62   mode active
!--- Associate interfaces to Po62 connected   to Cat6506-02
Int port-channel 62
switchport mode   trunk
vpc 62
!--- Associates vPC 62 to Po62
vPC Verification
show vpc consistency-parameters
!--- show compatibility parameters
Show feature
!--- Use it to verify that vpc and lacp features are enabled.
show vpc brief
!--- Displays information about vPC Domain
Etherchannel configuration on TAC 6500s
TACSWC01
TACSWC02
interface range GigabitEthernet2/38 - 43
description   TACSWN01 (Po61 vPC61)
switchport
switchport trunk   encapsulation dot1q
switchport mode   trunk
no ip address
channel-group 61   mode active
interface range GigabitEthernet2/38 - 43
description   TACSWN02 (Po62 vPC62)
switchport
switchport trunk   encapsulation dot1q
switchport mode   trunk
no ip address
channel-group 62   mode active

ihernandez81,
Between the c1-r1 & c1-r2 there are no L2 links, ditto with d6-s1 & d6-s2. We did have a routed link just to allow orphan traffic.
All the c1r1 & c1-r2 HSRP communications ( we use GLBP as well ) go from c1-r1 to c1-r2 via the hosp-n5k-s1 & hosp-n5k-s2. Port channels 203 & 204 carry the exact same vlans.
The same is the case on the d6-s1 & d6-s2 sides except we converted them to a VSS cluster so we only have po203 with 4 *10 Gb links going to the 5Ks ( 2 from each VSS member to each 5K).
As you can tell what we were doing was extending VM vlans between 2 data centers prior to arrivals of 7010s and UCS chassis - which worked quite well.
If you got on any 5K you would see 2 port channels - 203 & 204 - going to each 6500, again when one pair went to VSS po204 went away.
I know, I know they are not the same things .... but if you view the 5Ks like a 3750 stack .... how would you hook up a 3750 stack from 2 6500s and if you did why would you run an L2 link between the 6500s ?
For us using 4 10G ports between 6509s took ports that were too expensive - we had 6704s - so use the 5Ks.
Our blocking link was on one of the links between site1 & site2. If we did not have wan connectivty there would have been no blocking or loops.
Caution .... if you go with 7Ks beware of the inability to do L2/L3 via VPCs.
better ?
one of the nice things about working with some of this stuff is as long as you maintain l2 connectivity if you are migrating things they tend to work, unless they really break

Nexus 5k connected to dual 4506-E w/VSS

We're in the process of several upgrades. Part of these upgrades include turning on VSS in our core on two 4506E and installing a Nexus 5k with UCS in the data center. I'm planning to configure the links between Nexus and 4506E as layer 3 port channels.
My question is will the 4506E pair appear as one switch to the Nexus 5k? I would like to have a pair of 10G uplinks from the Nexus 5K to each 4506E...40G total. I'm wondering how STP will interact with the 3 switches as well. thanks....
Sent from Cisco Technical Support iPad App

If they're L3 portchannels, spanning tree won't play into that as it is L2. You will rely on ECMP for your IGP to load balance and all port between the layers will potentially be forwarding.
If they were L2 portchannels and you had VPC for all the relevant VLANs, it would look like one big 40 Gbps link - also with all ports forwarding. In that case the portchannel load balancing algorithm would distribute the traffic.

Help with multiple nat translation on a Cisco Nexus 3548

Hi All,
I need a little help with a NAT configuration on a cisco Nexus 3548 version 6.0(2)A4(3).
What currently have is as follows:
internal network: 192.168.4.0/24
nexus router (routerA):
LAN Side: vlan104 interface 192.168.4.201/24
WAN Side: Eth1/48 interface 172.24.101.2/24
remote network: 159.43.48.32/27
remote gateway: 172.24.101.1/24
use ACL's to ensure that only specific traffic is allowed out and in.
allow a specific connection from a different internal network (192.168.3.0/24) to talk to port 159.43.48.34:1025
Clients on the internal network 192.168.4.0, need to be able to connect to services (port 14002, port 8101) running on 159.43.48.34, but they must be SNAT'ed through the WAN interface as coming from 159.43.65.81
Currently we have this working but the internal lan clients need to know how to get to 159.43.48.34/27 and therefore we need to route this network in our internal network.
What we really want is to do is provide an address such as 192.168.4.203 for internal clients to use for connectivity to the various services, and then this address would be SNAT'ed to 159.43.65.81 over the WAN. We still want to secure the traffic in both directions.
In the past i've been able to do this with inside and outside nat's and i haven't had to configure an interface on the router for the internal address, it has just been "stood up" by the nat rules. For example (this is how i've done it before):
LAN interface
ip nat outside
WAN interface
ip nat inside
ip nat inside source static159.43.65.81 192.168.4.203
ip nat outside source static 159.43.65.81 192.168.4.203
but, trying to implement this sort of config on the Nexus isn't working.
I am wondering if the Nexus behaves differently than ios based routers.
I'd appreciate any help to get this config working.
Thanks in advance,
Les

Les
The issue with an "ip nat outside ..." static is that from the inside routing is done before NAT.
So what happens is that the destination IP is 192.168.4.203 and the Nexus will do a route lookup, see it is directly connected so it won't forward the packet to the outside interface so it doesn't get translated.
If you enter "ip nat outside source static 159.43.48.34 192.168.4.203" then on IOS it adds a host specific route to the routing table for 192.168.4.203 as directly connected.
So you do a ping from a 192.168.3.x client it looks like it is working but actually the L3 device is simply responding and the packet never gets to the server.
Apologies for the long winded explanation but NXOS might behave differently and I wanted you to know what to look for.
So with IOS there is the "add-route" option at the end of the NAT statement and if you use this it would add a host specific route into the routing table like this -
192.168.4.203 255.255.255.255 159.43.48.34
this is a recursive route ie. the device must know how to get to 159.43.48.34 but your Nexus should.
What the above does is make sure any packets arriving at the Nexus for 192.168.4.203 get routed to the outside interface and so are translated.
So firstly see if that option is available with your NAT statement ie.
"ip nat outside source static 159.43.48.34 192.168.4.203 add-route"
if it isn't then try adding just the static statement without it and then have a look at the routing table. If it hasn't put in a host specific route showing as directly connected which it may not, as it may behave differently, then you can manually add a route ie.
192.168.4.203 255.255.255.255 <next hop IP>
note that the next hop IP doesn't have to be the server here it could just be the next hop from the Nexus switch. All you are trying to do is get the packet routed to the outside interface.
Hope that makes sense.
Edit - one thing I haven't tried is to use a different IP subnet for NAT ie. one that is still part of your internal range but unused and then having a route on the Nexus, in your case, pointing to the outside interface and you redistribute this subnet into your IGP. Then you add the NAT statement.
What may happen is it still adds a host specific route showing as directly connected but it may not because the Nexus wouldn't actually have a directly connected interface for that subnet.
I suspect it would though.
If it did work then it would still mean you didn't need to advertise the public IP internally.
If I get the chance I'll test it later today.
Jon

WAN Redundancy Setup

Hi,
I am trying to setup a redundant connection to WAN. I have two WAN routers but only one Nexus5k. Pls see attached (high level logical) concept diagram. By using N5k as L2 and implementing HSRP on the WAN routers, I am hoping to get desired redundancy, in case one WAN Link or Router goes down HSRP & OSPF would be able to take care of it and route traffic to secondary WAN path.
Do you have any other ideas or this will work in all possible failed scenario? (I know N5k is single point of failure)
Thanks.

This design option works
However keep in mind that your design has single point of failure in the nexus side if you need it end to end redundant you need to consider adding a second switch to the topology
Hope this help
Sent from Cisco Technical Support iPad App

5596UP killing Vcenter "heartbeat" packets on Lan and WAN

Just moved my entire off a 6509 to the dual 5596up's running version 6.0(2)N2(5) with UCS.
Now, Vcenter5 (physical machine not vm) is having problems with its "heartbeat" to tcp/udp 902.
It isn't a routing issue, not a "arp issue", not a issue with a lower switch having " ip device tracking " enabled. Not an access-list block, not a firewall block.
Every minute we can watch Vcenter lose contact with local VM's that are on the UCS which is connected by Four 10-Gig trunks.
All other protocols and devices have no issues. Its just Vcenter on the local lan and going out across our WAN.
Had zero issues with this when I had all my core routing running on a 6509 running 12.2sx code.
Nothing changed on the Vcenter side or on our UCS. The routing was just moved to the Nexus 5596UP's.

VM monitoring are the TCP/UDP probes that Vcenter sends out to the VM servers ever 20 seconds.
This lets vcenter know that the VM servers are working correctly. Without a VM heartbeat, Vcenter thinks the Esx server is down, so you can't manage any of the VM hosts on that ESX server or migrate over VM's from one ESX server to another.

WAN Acceleration Configuration

Hello all,
We have purchased WAAS WAE 674 WAN Accelerator's, and I have a question on placement in our network. I've just recently implemented redundant WAN Lines (DS3's), and now would like to move my WAE674's so that they are accelerating traffic across both WAN lines.
Is this configuration possible with the 2 WAE674's (no inline cards), and WCCP forwarding, and my HQ WAAS controller, or do I have to purchase an additional 2 WAE 674's to accelarate both WAN lines.
Attached is a drawing for what our WAN design network looks like, we are using EIGRP as our routing protocol, and using per destination load sharing, and redistributing our static routes out from our HQ 6509E.
Please let me know if there is more information needed.
Thanks,
Jon

Hi Jon,
Here are the details of GRE and L2 WCCP redirection.
GRE allows datagrams to be encapsulated into IP packets at the WCCP-enabled router and then redirected to a WAE (the transparent proxy server). At this intermediate destination, the datagrams are decapsulated and then handled by the WAAS software. If the request cannot be handled locally, the origin server may be contacted by the associated WAE to complete the request. In doing so, the trip to the origin server appears to the inner datagrams as one hop. The redirected traffic using GRE usually is referred to as GRE tunnel traffic. With GRE, all redirection is handled by the router software.
Layer 2 redirection is accomplished when a WCCP-enabled router or switch takes advantage of internal switching hardware that either partially or fully implements the WCCP traffic interception and redirection functions at Layer 2. This type of redirection is currently supported only with the Catalyst 6500 series switches and Cisco 7200 and 7600 series routers. With Layer 2 redirection, the first redirected traffic packet is handled by the router software. The rest of the traffic is handled by the router hardware. The branch WAE instructs the router or switch to apply a bit mask to certain packet fields, which in turn provides a mask result or index mapped to the branch WAE in the service group in the form of a mask index address table. The redirection process is accelerated in the switching hardware, making Layer 2 redirection more efficient than Layer 3 GRE.
More details here:
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v441/configuration/guide/traffic.html
Cisco WAAS Software Release 4.0.13 introduces flexibility when using WCCPv2 as the redirection method. It allows configuration of egress method that increases Cisco WAAS deployment alternatives in cases using WCCP iterception. From Cisco WAAS 4.0.13 onward, the WCCP negotiated return is also supported as the egress method. This method allows the Cisco WAE to be deployed on the same subnet as users or servers and provides better support for preservation of the routing path chosen by the network, because the optimized traffic is returned to the redirecting router. The negotiated return egress method also helps ensure compatibility with asymmetric routing, equal-cost multipath (ECMP) load-balancing, and Hot Standby Router Protocol (HSRP) environments. The return traffic egress method is negotiated based on the WCCPv2 configuration on the router and the egress method configuration on the Cisco WAE.
You will find more information here:
http://www-europe.cisco.com/en/US/prod/collateral/contnetw/ps5680/ps6870/prod_white_paper0900aecd806d976a_ps6474_Products_White_Paper.html
Regards.

Uplinks to Nexus 7K as backup uplinks

I have my pair of Fabric Interconnect connected to 2 Nexus5000. There is a flaw in this design that if both Nexus 5000 are down, my UCS is cut off from the network.
Is there a way that I can run another pair of connection to the Core Switches Nexus 7000, but set it up so the traffic only flows through the 5000 and if both 5000s down, then flow to the core Nexus 7000 ?
Thank you.

The design I mention has no single point of failure, is bandwith and hop count optimized. Why are you so concerned about both N5k failing ? there are hundreds or thousands of such installations in the field working without a problem. In principle I could be paranoid, and raise the same issue for N7k, although they have 2 Sup's.
The UCS N5K vPC will only be used for intra VLAN traffic, e.g. server 1, vnic 1 connected to fabric A talking to server 2, vnic2, connected to fabric B, where vnic 1 and 2 are in the same vlan.
The traffic will be sent to N7K, for South-North traffic to WAN/Campus, resp. UCS inter Vlan traffic.
see eg.
http://www.cisco.com/cdc_content_elements/flash/dcap/6/#/enterprise/system-level-designs/virtualized-multi-tenant-data-center

FCIP on Nexus

Hi,
I have to provide a solution to my customer on disaster recovery and SAN-to-SAN Storage Replication Part. (The second DC will be around 400Km far from the main DC)
Q-1)
I have Nexus 7010 and 5596UP in the DC solution. I would like to know whether Nexus can do FCoIP or do i need a MDS switches for this?
If Nexus can do this then whic model, what modules required, what typr of trancevers, and what are the license requried to do the same.
If not, what type of MDS switche? what modules required, what typr of trancevers, and what are the license requried to do the same.
Q-2)
Do we require any specific link? do we require a dedicated link for this? or can i use my exisitng WAN link for this (Bandwidth is <40 Mb only)
if yes, what type of link requried? if yes what would be the suggested bandwidth? (3k-5k users accsing the data, 7-15 Tera data will be on storage)
is there any module on any wan router can accomplish the task? i read cisco 7200 / 7400 series router has FCIP Module (PA-FC-1G). If it support still i need a FCoE swith to convert the FC to IP? or i can directly connect the SAN port to the router module?
regards
Sunny

Can you please post the proper show commands for the fcip interfaces, resp. pc.
what is the error message of the fcip interfaces (also show logging log in general)

DCNM compatibilty with nexus 2000 and 5000 series

Hi,
I would to know if the DNCM can manage a Data Center composed with Nexus 2000 & 5000 series only!
Kind regards

Hi reswaran,
The features are:
- Automatic network discovering and real- time topology.
- Network anomaliy detection (threshold, alarms, errors, ...)
- Use email or aletrs to notify notify operations staff of critical outages thant may be service-imapcting
- Centralized administration interface, with acces via web
- Securised acces and rights managment
- Stock of data in an exportable database
- Quick, simple qnd transparent deployment
- Monitoring WAN bandwith usage
- Configurable report generation
- Generation of the performance reports
- Provide network map
- Support several network unit
- Intergrated Syslog server
- Polling andt monitoring SNMP trap alarms
- Secure config distribution
- Support 200 devices
What kind of NMS can you recommend?
thanks a lot

Script language for LAN, WAN, wireless?

which scripting language are used for LAN, WAN, wireless to automate things etc? python, shell scripting? is there a tutorial available to i can refer to?

It depends on what you are trying to do.
Shell scripting is quite limited in what it can do when compared to a more general purpose scripting language such as Perl or Python. Nothing wrong with that and I have used shell scripts a lot when I was a Unix admin but for networking most of what I have seen in terms of script languages has been TCL, Perl and Python.
You can use scripts to automate logging on to devices and executing commands, basically the script does what you would type in. To do this you can use Expect and Perl, Python and TCL all have Expect functionality (Expect was originally an extension to TCL).
But you are still just basically automating what you yourself would type and you would run these scripts from a server, PC etc although if you have a lot of devices you need to update with the same details it can save a considerable amount of time and just as importantly if the script works it removes the human error element of configuring multiple devices and perhaps getting a few wrong.
The next step is EEM where the device has an inbuilt TCL interpreter which means you can write applets or scripts that are stored on the device and can respond to specific things happening eg. if an interface goes up or down or the routing table is changed you can execute a set of commands.
There is an EEM forum on here.
I believe also that Nexus switches have an inbuilt Python interpreter which allows pretty much the same thing.
The advantages of the interpreter being on the device is that it saves a lot of extra coding and you can get more information because Cisco have added libraries to those interpreters which are specific to the device and which provide you with a standard set of APIs which your script can use.
As I said scripting can save a lot of time and there is an argument that all network engineers should at least now some scripting and this has become more of a hot topic with the promise of what SDN can achieve in the future although it has to be said there are already configuration management tools out there which make use of the above languages.
It really depends on what you are trying to do and how much you want to automate things.
In terms of tutorials etc. for all the major scripting languages there are a lot of online tutorials and books you can use.
In addition there are sites where you can run your scripts online but to be honest it is easier to simply download the interpreter to your PC, laptop etc. and you should be able to find a compiled version of the interpreter for whatever OS you are running.
Jon

WAN ECMP to Nexus 7K

Similar Messages

Maybe you are looking for