Hi
It is probably also worth looking at RFC5735 for other IP addresses that
could be filtered.
Ivan
On 24/Jun/2012 10:37 a.m., Randy wrote:
--- On Sat, 6/23/12, Mike mike-cisconspl...@tiedyenetworks.com wrote:
From: Mike mike-cisconspl...@tiedyenetworks.com
Subject: [c-nsp] ip access list
Hi,
I know the ME3600X has come up quite a lot recently on this list, but as
far as I recall and can find, it has been a while since there have been
any comments regarding the best/most stable version.
I am currently running 151-2.EY but will deploying some more hardware
shortly and would
I'd recommend 15.2(2)S1. 15.1(2)EY is a branch release which probably
won't have a long lifespan now that these switches have been integrated
into mainline S code.
15.2(2)S1 has been solidly stable for us with the exception of what
appears to be a cosmetic bug in that these messages are
Consider this PIM-SM scenario
Designated Router has two paths towards the Source and RPF has chosen one
The m-cast traffic will flow via the RPF interface down to the interested
receivers as long as the DR will be sending the periodic Join messages up
the Source-Tree
Now when the RPF
Hi experts,
The obvious difference between 6PE and 6VPE is as follow:
6PE will just establish IPv6 neighbor between PE router?
6VPE will establish VPNv6 neighbor between PE router, then exchange the VPN
routes between 6VPE router?
Will appreciate for any comments.
Best regards,
Hu Xu.
Consider this PIM-SM scenario
Designated Router has two paths towards the Source and RPF has chosen one
The m-cast traffic will flow via the RPF interface down to the interested
receivers as long as the DR will be sending the periodic Join messages up
the Source-Tree
Now when the RPF
If the intermediary routers are ipv6 capable don't omit placing an ipv6 address
on interfaces. 6pe should only be a stopgap until the devices can do native.
Jared Mauch
On Jun 25, 2012, at 6:01 AM, Oliver Boehmer (oboehmer) oboeh...@cisco.com
wrote:
All iBGP sessions between the 6PE or 6VPE
You mean the intermedia routers just support IPv6 situation?
Xu Hu
On 25 Jun, 2012, at 18:16, Jared Mauch ja...@puck.nether.net wrote:
If the intermediary routers are ipv6 capable don't omit placing an ipv6
address on interfaces. 6pe should only be a stopgap until the devices can do
AFIK as I know though, there is no native support for MPLS within IPv6,
LDP still runs over IPv4
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Xu Hu
Sent: 25 June 2012 11:26
To: Jared Mauch
Cc: cisco-nsp@puck.nether.net
Thank you very much Oli
it will send a join after a new RPF intf. has been identified for a given
source.
I see, so if I'll run IP FRR/LFA it will be almost immediately right please?
IIRC, there is/was some interdependency with pim query-interval and link-up
I see, so I'll definitely need to
Yeah la, LDPv6 is still during draft.
Xu Hu
On 25 Jun, 2012, at 18:36, Steve McCrory smccr...@gcicom.net wrote:
AFIK as I know though, there is no native support for MPLS within IPv6,
LDP still runs over IPv4
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
6pe should only be a stopgap until the devices can do native.
If you run 6PE on L2TPv3 core than maybe, otherwise I don't see any added
value in running IPv6 in the MPLS core
adam
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On
It's hard to say, we're still waiting for right release. :(
We already tried all this versions but all of them have serious bugs.
Even with new 15.2(2)S1 we hit a bug with Multicast Traffic Failure on EVC
Interface
In general, if you have EVC on interface configured with IPTV VLAN (mostly
If the intermediary routers are ipv6 capable don't omit placing an ipv6
address on interfaces. 6pe should only be a stopgap until the devices can do
native.
ack :-)
oli
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
it will send a join after a new RPF intf. has been identified for a given
source.
I see, so if I'll run IP FRR/LFA it will be almost immediately right please?
well, no, IP-FRR/LFA will not protect multicast traffic (at least not yet), RPF
interface update needs to follow regular IGP
On Mon, 25 Jun 2012, Harry Hambi wrote:
I have a faulty card in a live network ( 16 SFM-capable 16 port
10/100/1000mb RJ45 ), I have found a 48 port version of this card. Hope
this is not a stupid quesation, will the 48 port card work in this
chasis?,
Without knowing the specifics, the
On Mon, 25 Jun 2012, adam vitkovsky wrote:
If you run 6PE on L2TPv3 core than maybe, otherwise I don't see any
added value in running IPv6 in the MPLS core
The added value is that you have the choice of not labelswitching IPv6 at
all, ie running it native.
--
Mikael Abrahamssonemail:
Yes please what I meant was router wouldn't need to wait for IGP to compute
the RPF interface -as that would already be in place as LFA -so the router
can send Join out that interface immediately
Since you mentioned it already -are there any plans for sort of IP FRR for
m-cast please?
-where each
But that might require lot of work like configuring all the P-core routers
with BGP and update all the RRs with additional sessions to P-core routers
and update BGP on all ASBRs with AFI 2
I still fail to see the added value if the same service can be achieved with
BGP free core
adam
Adam,
you are missing the fact that you may have ICMPv6 error generation be
suppressed or dropped. Traceroute and other things are valuable tools
to diagnose what is going on. Having an indicator of where the device
sits that generates the error within the MPLS Core is important.
Those that do
You might also want to think about port groups and oversubscription,
depending on the models of both of the cards. If you just put the 16
connections on the first 16 ports on the 48 port card, there might be
more oversubscription if the 48 port card isn't line rate, depending
on how the port
Hello,
We would like to configure track option for static route.
e.g. ip route 0.0.0.0/0 *.*.*.* track
^ here!
However, there are no option...
Does nexus 3k not support track option for static route?
Are there any workaround?
Regards,
Hiromasa
If the MPLS backbone doesn't have the TTL propagation enabled than the ICMP
can fail only on Ingres PE or on Egress PE
If you trace from San Fran to NY do you really need to see all the P-core
nodes along the path sitting there not caring about IP at all just switching
labels all day?
In the old
I am with you on the Linux approach but for some of my clients I have had good
luck with Infoblox appliances as well, especially in enterprise network
scenarios, serving both DNS and NTP...
Anyone else use these?
--Scott
On Jun 23, 2012, at 6:38 PM, Nick Hilliard wrote:
On 23/06/2012
And guess what the Infoblox appliances run? :)
Josh
On Mon, Jun 25, 2012 at 10:39 AM, Scott Keoseyan sc...@labyrinth.orgwrote:
I am with you on the Linux approach but for some of my clients I have had
good luck with Infoblox appliances as well, especially in enterprise
network scenarios,
Lol... yep. But nice friendly gui for those enterprises lacking *nix
skillsets. :-)
Basically get the same result with a few handy edits to /etc/ntp.conf
--Scott
On Jun 25, 2012, at 10:50 AM, Josh Baird wrote:
And guess what the Infoblox appliances run? :)
Josh
On Mon, Jun 25, 2012
On (2012-06-25 10:50 -0400), Josh Baird wrote:
And guess what the Infoblox appliances run? :)
Earlier poster also wondered why waste money on NTP appliance'. Some of
these appliances have hardware timestamping, which will significantly
increase accuracy, if your network is low-jitter and
Hello,
I recently just received a few ASR-9001 routers and was surprised to find they
did not come with the required IOS-XR 4.2.1 image at all and are effectively
paperweights. As far as I've determined, it seems like there might have been an
error in the ordering process which omitted this.
On 6/25/12 17:23 , Vinny Abello wrote:
Hello,
I recently just received a few ASR-9001 routers and was surprised to find
they did not come with the required IOS-XR 4.2.1 image at all and are
effectively paperweights. As far as I've determined, it seems like there
might have been an error
On Jun 25, 2012, at 11:23 AM, Vinny Abello wrote:
I recently just received a few ASR-9001 routers and was surprised to find
they did not come with the required IOS-XR 4.2.1 image at all and are
effectively paperweights.
I had observed something similar to this in the past. If it was
Just be aware that the Windows Time service isn't terribly accurate, so it may
not be suitable for some environments:
http://support.microsoft.com/kb/939322
-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jared Mauch
Heh, 99% certain the config won't port over.
A 16 port ESW card has the config in the router section. 24/36/48 port
switches are managed as a completely different chassis, sharing
basically power, and a single 1gb backplane connection.
And like Justin says, it's a huge 'it depends' on a large
I'm using a VWIC3-1MFT-T1/E1 on a 2911, running
c2900-universalk9-mz.SPA.150-1.M5.bin.
At the cisco website the literature on this card says it can do loops
and BERT testing.
I can loop up remote (NIU) but I can't find the commands to do BERT
testing. The cisco website is not being any help
open a bug for FTP support.
On Mon, Jun 25, 2012 at 11:34 AM, Jared Mauch ja...@puck.nether.net wrote:
On Jun 25, 2012, at 11:23 AM, Vinny Abello wrote:
I recently just received a few ASR-9001 routers and was surprised to find
they did not come with the required IOS-XR 4.2.1 image at all
Without going into all the detail, Cisco developers have no concept of remote
management of their hardware. I've tried to educate the various teams, but I'm
not going to spend all that time for zero ROI as they need to ship the new
ROMMON from mfg, and instead they could just fix the mfg
There was discussion about NIC HW timestamping on the NTP mailing list
recently.
I didn't read the whole thing, but one of the issues that was brought up
was How accurate is the clock on the nic?.
For very high precision, you'd have to discipline the NIC clock as well,
so then you get twice the
On (2012-06-25 12:02 -0400), Aaron wrote:
open a bug for FTP support.
HTTP please. Even IOS-XR is missing HTTP. FTP is much more complex
protocol, and you'll often run into problems with passive/active and
authentication and whatnot. Either on server side, or device itself.
IMHO HTTP should be
Sure, but it may be usable for some that already have windows servers vs a *nix
systems.
Getting within a few seconds is a major feat for some folks i've observed :)
-- (myself included at times)
There are other people who have built win32 binaries of the xntp software, e.g.:
We are looking at OTV to mainly eliminate the tromboning of packets between out
two data centers which will soon both have 7013 nexus (only one 7018 the other
a 6513 soon to be upgraded).
The two data centers each have many L3 subnets and are extended to the other
data center using L2 trunks.
The 9001 at least comes with a USB port. Sometimes it's easier to ship a USB
stick than deal with loading software via remote.
Phil
On Jun 25, 2012, at 11:34 AM, Jared Mauch ja...@puck.nether.net wrote:
On Jun 25, 2012, at 11:23 AM, Vinny Abello wrote:
I recently just received a few
On 6/25/12 7:50 AM, Josh Baird wrote:
And guess what the Infoblox appliances run? :)
They run with vendor support. =) You can, of course, DIY fancy NTP
server solutions:
http://www.febo.com/pages/soekris/index.html
Assuming its not a new site.
Is the USB port accessible via ROMMON? I seem to recall it is not based on my
prior experience. This was part of my frustration.
- Jared
On Jun 25, 2012, at 12:45 PM, Phil Bedard wrote:
The 9001 at least comes with a USB port. Sometimes it's easier to ship a
On (2012-06-25 12:54 -0400), Jared Mauch wrote:
Is the USB port accessible via ROMMON? I seem to recall it is not based on
my prior experience. This was part of my frustration.
If only we have some sort of out-of-band processor in the router, which ran
its own operating system, to which we
I thought it was accessible but maybe it's not... I do not have first hand
experience myself. Didn't we just have this conversation?
Phil
On 6/25/12 1:23 PM, Saku Ytti s...@ytti.fi wrote:
On (2012-06-25 12:54 -0400), Jared Mauch wrote:
Is the USB port accessible via ROMMON? I seem to
Hi,
On Sun, Jun 24, 2012 at 08:34:06PM +0100, Nick Hilliard wrote:
On 24/06/2012 18:08, chris stand wrote:
Let them get time from your edge device(s) and let the windows clients
get it from them - which I think they are already doing.
I got the impression that the OP had ~10k network
Hi,
On Mon, Jun 25, 2012 at 04:37:55PM +0200, adam vitkovsky wrote:
If the MPLS backbone doesn't have the TTL propagation enabled
... then you're already harming your customers by taking away useful
diagnostic capabilities.
I *did* mention that we terminated our contract with one of our
Hi,
On Mon, Jun 25, 2012 at 10:40:54AM +0100, Harry Hambi wrote:
Hi experts,
I have a faulty card in a live network ( 16 SFM-capable 16 port
10/100/1000mb RJ45 ), I have found a 48 port version of this card. Hope
this is not a stupid quesation, will the 48 port card work in this
chasis?,
On (2012-06-25 22:16 +0200), Gert Doering wrote:
... then you're already harming your customers by taking away useful
diagnostic capabilities.
(Now we're with a new provider that gives us best of both worlds - a working
network, *and* the ability to verify that :-) ).
This really depends
On Jun 25, 2012, at 4:16 PM, Gert Doering wrote:
On Mon, Jun 25, 2012 at 04:37:55PM +0200, adam vitkovsky wrote:
If the MPLS backbone doesn't have the TTL propagation enabled
... then you're already harming your customers by taking away useful
diagnostic capabilities.
This isn't the
I am out of the office until 06/30/2012.
I am currently out of the office.
If the issue is urgent, please contact the help desk at extension 1853
Note: This is an automated response to your message cisco-nsp Digest, Vol
115, Issue 61 sent on 6/25/2012 10:39:41 AM.
This is the only
hey,
If the intermediary routers are ipv6 capable don't omit placing an
ipv6 address on interfaces. 6pe should only be a stopgap until the
devices can do native.
Doesn't make any sense before we have IPv6 MPLS implementation. We MPLS
switch all IPv4 packets (QOS based on EXP, so we don't
So you can't source errors either :-)
Jared Mauch
On Jun 25, 2012, at 4:46 PM, Tarko Tikan ta...@lanparty.ee wrote:
hey,
If the intermediary routers are ipv6 capable don't omit placing an
ipv6 address on interfaces. 6pe should only be a stopgap until the
devices can do native.
Doesn't
As Gert said, it does vary what is 'reasonable'.
Reasonably accurate for a stratum 2 is going to depend more on latency than the
server.
Particularly if the server is any appreciable distance away from its stratum 1
sources.
Within 1 millisecond is usually pretty good.
More than 5 milliseconds
I'm trying to help troubleshoot a really odd multicast issue on a 3750
that involves intermittent dropped packets. The problem seems to be
related to the overall traffic level on the multicast content vlan,
but we can find no explanation for it. There are multicast sources and
receivers in the
54 matches
Mail list logo
