<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Virtual Router Redundant VIP redundency problem in Application Networking</title>
    <link>https://community.cisco.com/t5/application-networking/virtual-router-redundant-vip-redundency-problem/m-p/250063#M3597</link>
    <description>&lt;P&gt;hello&lt;/P&gt;&lt;P&gt;We have the setup similar to the sample in cisco docu:&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-custom" href="http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_500/advcfggd/vipredun.htm#72959" target="_blank"&gt;http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_500/advcfggd/vipredun.htm#72959&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Each css has one uplink to the core switches. However when the inter-css link down, the network is not working! after some study, we realised it is because the two css can still see each other via the core switches, so VRRP never fail over. The servers patched on the backup css can not reach the master css, so they are not functioning!&lt;/P&gt;&lt;P&gt;&lt;/P&gt;</description>
    <pubDate>Wed, 22 Oct 2003 10:53:39 GMT</pubDate>
    <dc:creator>zhichao</dc:creator>
    <dc:date>2003-10-22T10:53:39Z</dc:date>
    <item>
      <title>Virtual Router Redundant VIP redundency problem</title>
      <link>https://community.cisco.com/t5/application-networking/virtual-router-redundant-vip-redundency-problem/m-p/250063#M3597</link>
      <description>&lt;P&gt;hello&lt;/P&gt;&lt;P&gt;We have the setup similar to the sample in cisco docu:&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-custom" href="http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_500/advcfggd/vipredun.htm#72959" target="_blank"&gt;http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/css_500/advcfggd/vipredun.htm#72959&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Each css has one uplink to the core switches. However when the inter-css link down, the network is not working! after some study, we realised it is because the two css can still see each other via the core switches, so VRRP never fail over. The servers patched on the backup css can not reach the master css, so they are not functioning!&lt;/P&gt;&lt;P&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 22 Oct 2003 10:53:39 GMT</pubDate>
      <guid>https://community.cisco.com/t5/application-networking/virtual-router-redundant-vip-redundency-problem/m-p/250063#M3597</guid>
      <dc:creator>zhichao</dc:creator>
      <dc:date>2003-10-22T10:53:39Z</dc:date>
    </item>
    <item>
      <title>Re: Virtual Router Redundant VIP redundency problem</title>
      <link>https://community.cisco.com/t5/application-networking/virtual-router-redundant-vip-redundency-problem/m-p/250064#M3598</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I would not recommend patching servers directly into the CSS's because there are scenarios where a CSS failure kills all servers plugged into that CSS.  In addition to the condition that you have already seen, you have the case where a CSS itself could crash, and those servers would be unreachable.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If you plug your servers into a back end switch or VLAN and use the CSS as the default gateway for that subnet, you can use VIP/Interface redundancy, and eliminate the inter-css connection.  In VIP/Interface redundancy, the only reason for the css-css connection would be if you wanted to do ASR.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 22 Oct 2003 13:14:50 GMT</pubDate>
      <guid>https://community.cisco.com/t5/application-networking/virtual-router-redundant-vip-redundency-problem/m-p/250064#M3598</guid>
      <dc:creator>d.parks</dc:creator>
      <dc:date>2003-10-22T13:14:50Z</dc:date>
    </item>
  </channel>
</rss>

