I find this highly unlikely.
I think you have a burden of proof that what you claim is actually
what is happening.
Do you have packet capture to show absence of stated traffic? And
existence of the expected packet in its stead?
On Wed, 19 Jun 2024 at 08:45, Hank Nussbacher via cisco-nsp
wrote:
I don't think there is enough information here to understand the problem.
So you have
RouterA - RouterB
RouterA is 192.0.2.1/24
RouterB is 128.139.197.146
RouterB advertises bunch of /32s to routerA, with next-hop 192.0.2.1?
This seems nonsensical to me, where is routerA supposed to send the
And your problem is, you get multiple default routes?
route-map FOO permit 100
match extcommunity 100
match ip address prefix-list DEFAULT
route-map FOO deny 200
match ip address prefix-list DEFAULT
route-map FOO permit 300
in your VRF_SHARED_SERVICE, so that you only import DEFAULT
On Sat, 8 Jun 2024 at 18:26, Arne Larsen via cisco-nsp
wrote:
> Yes, it'd with route-target I'm trying to get it to work, and what I'm
> trying to get rid off is the default route from the IOT vrf to be
> imported into the SHARED vrf.
Ok so the problem is not sharing routes between VRF, problem
On Mon, 6 May 2024 at 15:53, james list via cisco-nsp
wrote:
> The question: since the PO remains up, why we see this behaviour ?
> are BDPU sent just over one link (ie the higher interfac e) ?
Correct.
> how can we solve this issue keeping this scenario ?
> moving to RSTP could solve ?
No.
On Mon, 12 Feb 2024 at 09:44, james list wrote:
> I'd like to test with LACP slow, then can see if physical interface still
> flaps...
I don't think that's good idea, like what would we know? Would we have
to wait 30 times longer, so month-3months, to hit what ever it is,
before we have
On Sun, 11 Feb 2024 at 17:52, james list wrote:
> - why physical interface flaps in DC1 if it is related to lacp ?
16:39:35.813 Juniper reports LACP timeout (so problem started at
16:39:32, (was traffic passing at 32, 33, 34 seconds?))
16:39:36.xxx Cisco reports interface down, long after
On Sun, 11 Feb 2024 at 15:24, james list wrote:
> While on Juniper when the issue happens I always see:
>
> show log messages | last 440 | match LACPD_TIMEOUT
> Jan 25 21:32:27.948 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp
> current while timer expired current Receive State: CURRENT
Hey James,
You shared this off-list, I think it's sufficiently material to share.
2024 Feb 9 16:39:36 NEXUS1
%ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface
port-channel101 is down (No operational members)
2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_DOWN:
port-channel101:
I want to clarify, I meant this in the context of the original question.
That is, if you have a BGP specific problem, and no FCS errors, then
you can't have link problems.
But in this case, the problem is not BGP specific, in fact it has
nothing to do with BGP, since the problem begins on
I don't think any of these matter. You'd see FCS failure on any
link-related issue causing the BGP packet to drop.
If you're not seeing FCS failures, you can ignore all link related
problems in this case.
On Sun, 11 Feb 2024 at 14:13, Havard Eidnes via juniper-nsp
wrote:
>
> > DC technicians
On Sun, 11 Feb 2024 at 13:51, james list via juniper-nsp
wrote:
> One think I've omit to say is that BGP is over a LACP with currently just
> one interface 100 Gbs.
>
> I see that the issue is triggered on Cisco when eth interface seems to go
> in Initializing state:
Ok, so we can forget BGP
Open JTAC and CTAC cases.
The amount of information provided is wildly insufficient.
'BGP flaps' what does that mean, is it always the same direction? If
so, which direction thinks it's not seeing keepalives? Do you also
observe loss in 'ping' between the links during the period?
Purely
On Jun, 21 Jan 2024 at 03:17, Ross Halliday
wrote:
> Moving to qos-group for egress classes got me the result I was looking for.
> Thank you very much!
I'm happy that you got the results you wanted, but that shouldn't have
fixed it. The 'priority level 3' is the only thing that I can think of
On Fri, 19 Jan 2024 at 05:10, Ross Halliday via cisco-nsp
wrote:
> We've inherited some older ASR9000 systems that we're trying to support
> in-place. The software version on this one router is fairly old at 6.1.4.
> Driving it are a pair of RSP440-SE. The line cards are A9K-MOD160-SE with
>
On Thu, 21 Dec 2023 at 09:21, Hank Nussbacher via cisco-nsp
wrote:
> It used to be TAC was a main selling card of Cisco vs competitors. Not
> any longer :-(
Don't remember them ever being relatively or absolutely good.
Having one support channel for all requests doesn't work, because >99%
On Sat, 16 Dec 2023 at 18:38, Charles Sprickman via cisco-nsp
wrote:
> > There are hundreds of GRE tunnels.
>
> I have nothing to offer, and I'm mostly out of the ISP game, but I am so
> curious what the use-case is here, especially the "BGP to each CPE". I
> understand this might be private
On Mon, 2 Oct 2023 at 13:22, Dobbins, Roland via cisco-nsp
wrote:
> cache timeout inactive 15
> Kentik recommends 15s:
>
> This is an old, out-of-date recommendation from Cisco should be retired.
>
> 5s is plenty of time for inactive flows.
What is the basis for this recommendation? With 1:10k
On Mon, 2 Oct 2023 at 09:14, Hank Nussbacher via cisco-nsp
wrote:
> Does this make sense to go 1:1 which will only increase the number of
> Netflow record to export? Everyone that does 1:1000 or 1:1
> sampling, do you also seen a discrepancy between Netflow stats vs SNMP
> stats?
Both
Your output says the JNPR side is still fast/1s.
I'd actually prefer to look at the LACP PDU from the wire 'monitor traffic '
Flap would be expected if CSCO sends every 30s, JNPR sends every 1s.
We should expect JNPR to be happy about 3s after receiving PDU from
CSCO. I thoroughly recommend
You've changed JNPR from 30s to 1s, but not CSCO. I'm not sure if this
is the only problem, as insufficient data is shown about the state and
LACP PDUs.
I believe the command is 'lacp rate fast' or 'lacp period short', to
reduce risk of operators getting bored, In your case, the former.
On Sun,
On Sun, 12 Mar 2023 at 20:50, Mark Tinka via cisco-nsp
wrote:
> ASR9K1 has more routes with better paths toward destinations via its
> upstream than ASR9K2 does.
Or at worst, race.
You might want add-path or best-external for predictability and
improved convergence time.
--
++ytti
On Wed, 1 Mar 2023 at 02:41, Phil Bedard via cisco-nsp
wrote:
> With XR7 the idea was to mimic how things are done with Linux repos by having
> a specific RPM repo for the routers and the patches which is managed similar
> to Linux and that’s how all software is packaged now. Dependencies are
On Tue, 14 Feb 2023 at 02:21, Lee Starnes via cisco-nsp
wrote:
> So attempted to just remove the ACL and try. Still nothing. Lastly, I
> enabled telnet and tried to connect via telnet. Still nothing. I really
> don't want to restart the switch if there is any other way to resolve this.
>
>
On Wed, 8 Feb 2023 at 09:48, Hank Nussbacher via cisco-nsp
wrote:
> So how does one escalate such an issue within TAC? Is there some secret
> email like escalati...@cisco.com or vp-...@cisco.com that one can contact?
You call your account team, express your grief and set expectations.
Then you
On Thu, 8 Dec 2022 at 11:40, Marcin Kurek wrote:
>
> > https://www.rfc-editor.org/rfc/rfc8654.html
>
> Thanks!
>
> > But it was [8936, 1240].min - so it was 'negotiated' here to the
> > smallest? If you change the 8936 end to 1239, then that will be used,
> > regardless who starts it.
>
> Yes,
On Thu, 8 Dec 2022 at 11:25, Marcin Kurek wrote:
> Interesting, but why would 'sh run' or 'write' raise an interrupt?
> Isn't this a branch in code that handles the CLI?
Maybe to access NVRAM? I don't know for sure, I didn't pursue it, I
just know I could observe it.
> I'm not sure if I'm
On Wed, 7 Dec 2022 at 22:20, Marcin Kurek wrote:
> > I've seen Cisco presentations in the 90s and early 00s showing
> > significant benefit from it. I have no idea how accurate it is
> > today,nor why it would have made a difference in the past, like was
> > the CPU interrupt rate constrained?
>
Hey Marcin,
> XR without enabled PMTUD (default setting) means ~1240 bytes available
> for TCP payload.
>
> That seems to be a bit small, did you perform any kind of performance
> testing to see the difference between defaults and let's say 9000 for BGP?
I am embarrassed to say, but I _just_
> Assuming typical MPLS network running L2VPNs and L3VPNs, how do you
> configure MTU values for core interfaces? Do you set interface (L2) MTU,
> MPLS MTU and IP MTU separately?
We set the 'physical' MTU (In IOS-XR+Junos L2 but no CRC is in this
humber) as high as it went when the decision was
How would you imagine it works, in a world without any limitations?
This seems like a day1 building ethernet LANs question, unless I'm
missing something.
Comcast learns the 1701 now from every site.
Frame comes in with DMAC 1701
Where does Comcast send it? Should it balance between three sites?
On Fri, 14 Oct 2022 at 23:32, Gert Doering via cisco-nsp
wrote:
> For a true time geek, the time the rPIs provide is just not good
> enough (fluctuates +/- 20 usec if the rPI has work to do and gets
> warm) :-)
Meinberg does not do HW timestamping, nor does NTP. Almost every NIC
out there
On Sat, 6 Aug 2022 at 05:27, Paul via cisco-nsp
wrote:
> Storm control pps is bugged on the 10g ports on the older 4900
> platforms, 4948E , 4900M, sup6 platforms.
When you say 'bugged', what do you specifically mean? Do you mean the
platform can do PPS accounting in HW and there is DDTS or do
Are you sure packet based storm-control is even supported in the platform?
What does 'show storm-control' say?
It is interesting that all packets are multicast packets in the Ten
interfaces, but the packet count is so low, I don't think we can put a
lot of weight into it.
On Thu, 4 Aug 2022 at
On Thu, 4 Aug 2022 at 02:06, Joe Maimon via cisco-nsp
wrote:
> I have a vendor trying to turn up a 10gb link from their juniper mx to a
> cisco 4900M, using typical X2 LR.
>
> The link was being upgraded from a functioning 1gb. Same traffic.
10G will serialise packets 10x faster. Even if the
--- Begin Message ---
On Tue, 28 Jan 2020 at 17:28, Nathan Lannine wrote:
> FWIW we are actually using object ACLs. What's the behavior then? Copy-swap?
> Is there a real name for that which I'm not remembering?
Object should be indeed copy-swap (atomic).
--
++ytti
--- End Message ---
36 matches
Mail list logo
