Hi all,
We're deploying some ASR9001's for VXLAN to QinQ translation, and all is
good... but supply is weak at the moment.
I am wondering if the ASR1K series - 1001, 1002, etc... can do the same
thing - just slower? Might need to roll-out some in the interim.
...Skeeve
*Skeeve Stevens - Founde
Hi all,
We use a 7600 with a sup720xl and we receive 3 full bgp tables, some partial
transit and some peering.
According to sh bgp sum bgp is using:
ipv4 ~250MB
ipv6 ~30MB
But the 1GB dram is almost full.
sh memory summary
Head Total(b) Used(b) Free(b) Lowest(b) Larges
Yes its a sub720-3bxl with IOS 12.2SRE. We are not using soft-reconfig.
Why is the "sh bgp all sum" around 300MB and the sh prec mem shows bgp is using
90%, or around 800MB.
I just applied a filter for a default route only on one of the transits.
I can see i receive only 1 route but the mem us
On 11/03/2015 12:45, Erik Klaassen wrote:
> But the 1GB dram is almost full.
correct - this is a long time coming for the sup720/rsp720 platform. If
you have soft-reconfiguration inbound, you'll need to drop that from the
configuration.
If you can downgrade to IOS 12.2SR, that will also help RA
I would've expected to see 1F4 or 500 of which I should've been under. I am
anticipating needing to be around 550 before too long.
Because we have multiple circuits with said upstream, I can't rule out they
modified the wrong session, and will have to press them later today.
> From: mack.mcbr.
On (2015-03-10 20:29 +0100), Job Snijders wrote:
> "^64500+ [^64500]"
>
> This junos beauty will match for example: "64500 64500 123 123 444", but
> not "64500 64500" or "64500".
>
> Can any of you come up with a single line regex that works on IOS or XR
> (ios-regex) to mimick the above des
On 11/03/2015 13:45, Erik Klaassen wrote:
> Yes its a sub720-3bxl with IOS 12.2SRE. We are not using soft-reconfig.
> Why is the "sh bgp all sum" around 300MB and the sh prec mem shows bgp is
> using 90%, or around 800MB.
probably memory fragmentation.
> I just applied a filter for a default r
There is no back tracking in the junos regex nor would backtracking really help.
Doing this is complicated on cisco due to the lack of negating a full as.
However loop avoidance should prevent 64500 from occurring twice with an
intervening AS.
If you have turned off loop avoidance with allowas-in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Cisco Security Advisory: Multiple Vulnerabilities in Cisco TelePresence Video
Communication Server, Cisco Expressway and Cisco TelePresence Conductor
Advisory ID: cisco-sa-20150311-vcs
Revision 1.0
For Public Release 2015 March 11 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Cisco Security Advisory: Cisco Intrusion Prevention System MainApp Secure
Socket Layer Denial of Service Vulnerability
Advisory ID: cisco-sa-20150311-ips
Revision 1.0
For Public Release 2015 March 11 16:00 UTC (GMT
On 11/Mar/15 18:49, Nick Hilliard wrote:
running full dfz on this platform has not been a good thing to do for
several years.
This.
Mark.
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
arch
On 11/Mar/15 21:55, Chuck Church wrote:
And since when isn't a 3BXL large enough for a full
table assuming you can live with the CPU issues.
You said it :-)...
Mark.
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mail
On (2015-03-11 17:28 +), Mack McBride wrote:
Hey,
> There is no back tracking in the junos regex nor would backtracking really
> help.
> Doing this is complicated on cisco due to the lack of negating a full as.
There definitely is backtracking, the reason (64500_)+.+ doesn't work, and
match
Hi Folks,
is there any other possibility to create a demo/eval license for an nexus
9505 chassis. We can (on the portal) crate any demo license including for
all nexus switches, except for nexus 9000 series.
any help is welcome
Regards Gregor
__
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Cisco Secure Access Control System SQL Injection Vulnerability
Advisory ID: cisco-sa-20150211-csacs
Revision 2.0
For Public Release 2015 February 11 16:00 UTC (GMT)
Last Updated 2015 March 11 19:34 UTC (GMT)
+
On Wed, 11 Mar 2015, Erik Klaassen wrote:
Hi all,
We use a 7600 with a sup720xl and we receive 3 full bgp tables, some partial
transit and some peering.
According to sh bgp sum bgp is using:
ipv4 ~250MB
ipv6 ~30MB
But the 1GB dram is almost full.
sh memory summary
Head Total(b)
We've long had some feature requests open against JunOS for
as-path matching. The challenges faced are they don't treat these
AS numbers as strings, and certainly not in the case of some elements
like a paren (confed) or { for AS_SET.
In IOS-XR you can much more easily match again
On 11/03/2015 17:46, Jared Mauch wrote:
> In IOS-XR you can much more easily match against the origin-asn
> in a policy as well which isn't quite as easy in other routing operating
> systems.
this is the fundamental issue: ios/ios-xe policy management grammar is
unfit for purpose. A subset
On 11/03/2015 23:41, Cydon Satyr wrote:
> I understand a proper maintenance window should be ordered, but, could
> this be done with no downtime (or at least near 0, just so hosts update arp
> table)? Any ideas?
Have you labbed this up?
You haven't, because you haven't yet run into the problem t
On Wednesday, March 11, 2015, Cydon Satyr wrote:
> Hello guys. We have a bunch of redundant router Cisco pair routers, that
> are running HSRP, that needs to be migrated to VRRP.
>
> The question is, could this be down with 0 downtime?
>
> My guess is, if we replace backup HSRP router to run VRRP
The junos expression in question DOES NOT involve backtracking.
After a match there is no need to backtrack.
The expression in question goes character by character excluding the 64500.
Note the last part matches 6 digit ASNs that start with 64500.
Mack McBride | Network Architect | ViaWest, Inc.
On 12/Mar/15 02:43, Matt Addison wrote:
Assuming your platform lets you configure HSRP and VRRP simultaneously on
the same interface, change the HSRP address to a new address, then set up a
new VRRP group on a different group number for the original IP. Any ARPs
before you get the new group es
Top posting and answering OP's original-question:
NO. A change to FHRP; regarless of FHRP protocol-used(hrspv1/v2/vrrp)will
result in at_the_least packetloss(be cognizant of STP-interactions in your
env)while the change is being implemented.
Hint:
vitrual-mac for hsrpv1: 00:00:0c:07:ac:xx
vir
23 matches
Mail list logo
