> Just curious; why are you running MPLS and your core-facing
> features on an SVI?
The primary reason for this is because these switches are in a ring. The core
facing interface on this switch needs to support VLAN trunking so the ring APS
control channel and ring data VLAN can be transported in the core from one
router to another. In other words, the two head-end switches of the ring are
not physically connected and are stitched together via MPLS in the core:
R - R - R
/ \
S - S - S - S
> Also, you're lowering your protocol MTU's quite a fair bit,
> even though the physical interface can handle them. Any
> reason why?
Just the way it's always been and I really haven't found a compelling reason to
increase them.
> Have you tried running all this on the 10Gbps uplink ports
> natively, and checked again to see whether you see these
> issues?
Yes - changing the port to either a normal switchport with an allowed VLAN list
or a routed port works fine.
> I can't recall for which platform, but I think there are
> some restrictions with running MPLS and/or MPLS-TE on an
> SVI.
I was told by the TAC engineer that assisted me with my latest problem that
this was a possibility, as MPLS on SVI was only "recently" introduced in
15.3(1). Frustrating, since not a single TAC engineer I worked with on my case
mentioned anything at all about any restrictions. That said, I now see this:
http://www.cisco.com/en/US/partner/docs/switches/metro/me3600x_3800x/software/release/15.3_3_S/configuration/guide/swmpls.html#wp1289925
"4. MPLS-TE is not supported on SVI."
I guess it's time to look at how the ring is configured and re-evaluate whether
a layer 2 ring architecture is worth the weird troubles and randomly
supported/unsupported features.
-evt
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
