3 days ago traffic started showing up on the trunk port connecting my top of
rack switches. Each of these switches has it's own better trunk path to the
root bridge. I can't see why any traffic at all would traverse these links
unless the other trunk on g0/45 was down, which it isn't. Also,
On Fri, Mar 26, 2010 at 11:47 PM, Cord MacLeod cordmacl...@gmail.comwrote:
3 days ago traffic started showing up on the trunk port connecting my top
of rack switches. Each of these switches has it's own better trunk path to
the root bridge. I can't see why any traffic at all would traverse
On 2010-03-24 16:47, Gert Doering wrote:
- some of the cat4000-family devices do IPv4 in hardware and IPv6 in
software (we have no 4k, so others will help clarify that)
All Sups up until Sup6E and Sup6E-Lite are doing IPv6 in software.
As Catalyst 4900M is based off the Sup6E it also
Unless the other side of Gi0/46 is blocked, i don't think it's an issue
to see traffic on a designated port.
On the other hand, if this switch has dual uplinks to the pri/sec root
switches, then somewhere else there must be a blocked port.
--
Tassos
Cord MacLeod wrote on 27/03/2010 08:47:
3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/03/2010 21:52, Peter Rathlev wrote:
http://www.cisco.com/en/US/customer/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml
(Login required for some reason.)
I found that removing the /customer part from these
Are you sure this is actually fixed?
When entering the command:
mls rate-limit unicast cef glean 5000 250
I get:
12.2(18)SXF14 and 12.2(33)SXI3: The following is sent the console only, but
not logged:
%Packets requiring ARP resolution will be subject to the output ACLs of the
input VLAN
On Wednesday 24 March 2010 10:36:54 am Charles Mills wrote:
Older Layer 3 gear being what it is I'm already aware does everything
in software if it supports it at all.
Oh, I ran across a quote yesterday while doing some additional research into
the IPv6 capabilities and caveats with hardware I
Cord,
You are not providing enough details to help you troubleshoot the issue.With
the information
you have provided is unfortunately not enough. We can only make assumptions
at this point.
How many switches are involved in this STP Domain, what is the status of all
links to the Root
Bridge.
PfR takes care of the rerouting on a site basis. The site is monitoring
reachability to a particular prefix. The key issue with a single cloud, is
that you don't control the end to end path. If it is two clouds then you can
monitor end to end via each cloud, and choose which one is better to use
I have a pair of 7200s at two locations with a 155mbit radio link between
them. We're hooking up PA-POS across this and I am wondering how to best
bridge across the link.
Yes, I have to bridge. I've looked at it every which way, we're replacing
a metro fiber transport for another provider so
On Saturday 27 March 2010 05:22:35 pm neal rauhauser wrote:
I have a pair of 7200s at two locations with a 155mbit radio link between
them. We're hooking up PA-POS across this and I am wondering how to best
bridge across the link.
See Bridging Control Protocol (BCP) (
I believe the feature that should match your requirement are
1. To counter IOS deficiency where BGP is not event-driven, use BGP
Selective Address Tracking - introduce in 12.4(4)T, 12.2(33)SRB
http://www.cisco.com/en/US/docs/ios/12_4t/ip_route/configuration/guide/brbadv.html
2. To install backup
On Sat, 27 Mar 2010, neal rauhauser wrote:
Yes, I have to bridge. I've looked at it every which way, we're replacing
It'd probably make more sense to use xconnect over either IP or MPLS in
your case, than trying to bridge the traffic. This will do the same thing
but will avoid having to
I found on internet
MPLS VPN LOCAL LABEL - with BGP
basically this is via advertising same label on primary PE for prefix for
both primary and secondary paths.So that if primary path fails then same
label can be used to Primary PE ( primary PE CE link down) ,,, then Primary
PE route traffic to
14 matches
Mail list logo
