> ECMP appears to be your main pain point, the rich features are not
> relevant, and you mentioned commodity hardware being able to hash on
> IPIP. I feel this may be a very special case where HW can do IPIP hash
> but not MPLSIP hash. Out of curiosity, what is this hardware? Jericho
> can do
> What I'm getting at is that IP allows re-write sharing in that what needs to
> change on two IP frames taking the same paths but ultimately reaching
> different destinations are re-written (e.g. DMAC, egress-port) identically.
> And, at least with IPIP, you are able to look at the
> On Jun 12, 2020, at 11:41 AM, Robert Raszuk wrote:
>
> I'm not sure why this deep label stack keeps popping, if we need
> multiple levels of tunneling, we need it in IP too, and it's almost
> more expensive in IP.
>
> Well imagine you need only one level of tunneling but rich ECMP.
>
>
>
>> Unless you want ECMP then it VERY much matters. But I guess since we are
>> only talking about theoretical instead of building an actual practical
>> network, it doesn't matter.
>
> Well blatantly we are, because in the real world most of the value of
> MPLS tunnels is not available as IP
> Rewrites on MPLS is horrible from a memory perspective as maintaining the
> state and label transition to explore all possible discrete paths across the
> overall end-to-end path you are trying to take is hugely in-efficient.
> Applying circuit switching to a packet network was bad from the
>> The label stack question is about the comparisons between the two extremes
>> of SR that you can be in. You either label your packet just for it's
>> ultimate destination or you apply the stack of the points you want to pass
>> through.
>
> Quite, but transit won't inspect the stack, it
> On Jun 12, 2020, at 8:26 AM, Saku Ytti wrote:
>
> On Fri, 12 Jun 2020 at 18:16, David Sinn wrote:
>
>> I'm not sure what implementation you are saying doesn't exist. The Broadcom
>> XGS line is all on-die. The two largest cloud providers are using them in
&g
> On Jun 11, 2020, at 2:02 PM, Mark Tinka wrote:
>
>
>
> On 11/Jun/20 17:32, David Sinn wrote:
>
>> Respectfully, that is deployment dependent. In a traditional SP topology
>> that focuses on large do everything boxes, where the topology is fairly
>&
> On Jun 11, 2020, at 12:39 PM, Saku Ytti wrote:
>
> On Thu, 11 Jun 2020 at 21:04, David Sinn wrote:
>
>> You've made my point for me. If you are building the core of your network
>> out of MX's, to turn a phrase, in a past life "I fully support my
>> c
> On Jun 11, 2020, at 8:41 AM, Saku Ytti wrote:
>
> On Thu, 11 Jun 2020 at 18:32, David Sinn wrote:
>
>> However if you move away from large multi-chip systems, which hide internal
>> links which can only be debugged and monitored if you know the the obscure,
Respectfully, that is deployment dependent. In a traditional SP topology that
focuses on large do everything boxes, where the topology is fairly
point-to-point and you only have a small handful of nodes at a PoP, labels can
be fast, cheap and easy. Given the lack of ECMP/WECMP, they remain
I think the issue is more complicated then just does it work or not. It is
dependent on how you have your 6500/7600 deployed.
Some form of bus-stalls will occur with any OIR. They may be minor, they may
not and that comes down to how long it takes for the shared bus to re-stabilize
because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Have you tried enabling per-VRF labels instead of pre-prefix labels:
http://ciscosystems.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_per_vrf_lbl_ps6922_TSD_Products_Configuration_Guide_Chapter.html
'mpls label mode all-vrfs protocol bgp-vpnv4
I've not done VRF Select PBR myself, but it would appear that it was first
integrated in 12.2(33)SXH1, so you could be running into a bug, or not totally
following the implementation guide as it would appear that you need to give a
next hop when using the set vrf [instance] term in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sup720's support a Max of 1024 VRF's. See the datasheet:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856.html
David
On Apr 23, 2009, at 10:20 AM, Adam Armstrong wrote:
Marlon Duksa wrote:
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The router will not internally bridge between the two modules. By
having them both on VLAN-1 the router doesn't know which one is the
real VLAN-1.
If you want them both on the same subnet you need to run a
interconnect external between each
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey,
On Dec 10, 2008, at 1:46 AM, Gert Doering wrote:
Hi,
On Wed, Dec 10, 2008 at 10:36:44AM +0100, David Granzer wrote:
did anybody see output below with SXH4 ? Why applying vlan can take a
few minutes ?
6503-lab-1#conf t
Enter configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ignoring ARP responses that return multicast (or broadcast) MAC
addresses is required by the RFC1812 Section 3.3.2. Static ARP's are
the only options (or working on getting the RFC changed).
David
On Oct 17, 2008, at 3:00 PM, Crist Clark
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 15, 2008, at 2:31 PM, Justin Shore wrote:
I can't think of any reason why this prefix wouldn't be advertised.
Any
ideas? I noticed it today because I have customers trying to hit 0/8
IPs (0.4.24.200 for example) that my egress ACLs are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2008, at 11:51 AM, Peter Lothberg wrote:
Tim Stevenson wrote:
At 10:18 PM 1/28/2008 -0600, mack observed:
No mention of MPLS though which gives the CRS-1 a leg up on the
backbone routing market.
NO MPLS (though the h/w is capable).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Have you looked at the mac-address table on the switch and confirmed
that it is learning the right port the machine should be out? Unicast
traffic will flood to all ports on a VLAN when the switch does not
know which specific port the traffic
21 matches
Mail list logo
