On Wednesday, November 27, 2013 11:24:34 AM Adam Vitkovsky
wrote:
> How I see it is that we all IP and Optical are gonna lose
> our jobs to SDN and we'll be only called to set it up
> initially or when things go fishy, though we'll make
> sure they won't so we'll be called in for the next setup
>
On Wednesday, November 27, 2013 09:50:16 PM Phil Bedard
wrote:
> Juniper is still pushing to put DWDM optics on the router
> itself, with their 2x100GE coherent tunable PIC out now.
> The muxing portion of their solution is yet to come but
> right now they partner with the Adva FSP gear and I kn
I needed to load an SDM template that supported v6. This was on C3750 and
C3650.
COR01.XXX#sh sdm prefer
The current template is "desktop IPv4 and IPv6 routing" template.
...
COR01.XXX#ping FD00:1:10:64:0:24::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD00:1:10:64:0:24:
You should try a link local ping across.
If that works then something is blocking the ICMP.
You need to make sure your ACLs are not blocking link local,
ND, ICMP echo, multicast, path MTU discovery or any of the
other critical ICMP messages.
You also need to make sure both end points have IPv6 ful
And you also may need to adjust sdm to support ipv6
> From: cisconsp_l...@hotmail.com
> To: svoll.v...@gmail.com; cisco-nsp@puck.nether.net
> Date: Thu, 28 Nov 2013 08:20:35 +1100
> Subject: Re: [c-nsp] IPv6 in the lab..
>
> Have you enabled ipv6 unicast-routing ?
>
> > Date: Wed, 27 N
Have you enabled ipv6 unicast-routing ?
> Date: Wed, 27 Nov 2013 10:06:51 -0800
> From: svoll.v...@gmail.com
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] IPv6 in the lab..
>
> So I may be dense or something, but if I have two devices on a Vlan with
> IPv6 addresses in the same network,
If they are on the same L2, and addressed on the same L3, you should be
able to ping unless you have a vACL/pAcL blocking IPv6/ICMPv6 ... can you
ping between their link-locals?
/TJ
/TJ
On Wed, Nov 27, 2013 at 1:06 PM, Scott Voll wrote:
> So I may be dense or something, but if I have two de
On 11/26/13, 10:18 PM, "Mark Tinka" wrote:
>On Tuesday, November 26, 2013 10:37:29 AM Gert Doering
>wrote:
>
>> If we're talking about the same thing, I think it's a
>> great idea, and the only problem is that vendors
>> charging extra for using it (and thus, many people are
>> not using it ev
So I may be dense or something, but if I have two devices on a Vlan with
IPv6 addresses in the same network, why would I not be able to ping them?
Is there something I have to do on layer 2 switches in order to allow the
icmpv6 to flow?
Switches are 3560's and nexus 5500/2k's
TIA
Scott
Il 27/11/13 19:01, Lukas Tribus ha scritto:
> 15M, 12.4, etc are ISR branches, while 15S or 12.2SR are 7600
> branches. On the 7200 you have the choice between the two, but they
> are fundamentally different
thank you, exactly what I meant by saying "different versions"
--
antonio
Hi!
> well, I tested on different IOS versions: actually it doesn't show on
> 151-4.M1 and 124-24.T8 and 123-21 for instance.
>
> just on 152-4.S4
15M, 12.4, etc are ISR branches, while 15S or 12.2SR are 7600 branches.
On the 7200 you have the choice between the two, but they are fundamentally
Hi,
I did encounter this message only with HSRP and there the problem was
that IPv6 requires version 2 and IPv4 works fine with version 1.
For GLBP...please let me know if you find the answer.
Thanks,
Calin
On 11/27/13 1:33 PM, Gerald Krause wrote:
Hi,
we need a FHRP that support IPv4 and IPv
On 26/11/13 21:11, Saku Ytti wrote:
> Interestingly, I don't believe this behaviour could be seen in IOS-XR or JunOS
> or such, since it's quite untypical for userland process to start processing
> packet before it's received. But IOS specifically has dedicated TCP/IP
> implementation for BGP and a
Yes, NAT Overload in a VRF is not supported on any Sup720 based system. It
might work on Sup2t, but I'm not sure.
On Wed, Nov 27, 2013 at 10:10 AM, Dan Benson wrote:
> Thanks Peter.
>
> I found that by simply removing the VRF from the interfaces I wished to do
> nat on (even though they were in
Thanks Peter.
I found that by simply removing the VRF from the interfaces I wished to do nat
on (even though they were in the same VRF) allowed my nat to overload. Is this
expected behavior?
All is working now.
Thanks all for your help.
db
On Nov 26, 2013, at 6:18 PM, Pete Lumbis wrote:
Hi,
we need a FHRP that support IPv4 and IPv6 one some ME3400s in our
network. The documentation state that GLBP would do that on the MEs but
it seems that it can not be configured on this systems, regardless
whether we are using link local or global unicast IPv6 addresses.
me3400g-2cs(config-if)
i told last time they cannot load-sharing traffic for mc-lag, not sure now
can support or not.
another thing is that if you previous have hsrp/vrrp between two asr9k, now
u must change the design.
On Wed, Nov 27, 2013 at 6:12 PM, Adam Vitkovsky wrote:
> I was told that if you'll buy the SE card
Eigrp default metric = 256*(1000/path-minBW + sum(delays/10))
BW is in Kbps
-so the formula does work for up to 10G links
However when comparing 10G an 1G int on me3600 I see following delay
sh int g0/2
.. DLY 10 usec,
sh int te0/1
.. DLY 1000 usec
Say what? Hahaha :)
Do your interfaces hav
I was told that if you'll buy the SE card +license than all the satellites'
ports fed of from that card can leverage the hierarchical QOS and VRFs
though I'm not sure how it works with the finite memory amount on the parent
card.
adam
-Original Message-
From: cisco-nsp [mailto:cisco-nsp-
> SDN will polish your nails also :-).
>
> Mark.
How I see it is that we all IP and Optical are gonna lose our jobs to SDN
and we'll be only called to set it up initially or when things go fishy,
though we'll make sure they won't so we'll be called in for the next setup
job.
Right the pre-fec
Looks like the want to be *_very_* sure there traffic flows through as174 :-)
M
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Mark Tinka
> Sent: 27 November 2013 04:26
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] %BGP-6-MSGDUMP_L
On Wednesday, November 27, 2013 10:46:24 AM Sander Steffann
wrote:
> +1!
The thing is, commercially, it is not always feasible to
deploy IPoDWDM everywhere.
In a network that has its own fibre (local and national), it
may make sense to run rings over dark fibre if you have
plenty of fibre, a
Op 27 nov. 2013, om 11:26 heeft Gert Doering het volgende
geschreven:
> Hi,
>
> On Wed, Nov 27, 2013 at 05:20:12AM +0200, Mark Tinka wrote:
>> One of the best applications for me, for this, would be
>> visibility into the fibre, and proactive failover when a
>> certain fibre error-rate is rea
On Wednesday, November 27, 2013 10:26:40 AM Gert Doering
wrote:
> Yeah, that. Want.
Last time I tested this on a CRS back in 2010, we managed
15ms failover across a simulated 1,200km span.
That said, I tested LFA and MPLS-TE on the Juniper MX2020 a
few months ago, and we managed some 20ms as
Hi,
On Wed, Nov 27, 2013 at 05:20:12AM +0200, Mark Tinka wrote:
> One of the best applications for me, for this, would be
> visibility into the fibre, and proactive failover when a
> certain fibre error-rate is reached, prior to complete
> service failure.
Yeah, that. Want.
gert
--
USENET i
25 matches
Mail list logo
