> On Tue, 2010-06-22 at 07:37 -0500, Jeff Bacon wrote: > > It's packets that are being NATted by dev B. Anything else is fine, > > labeled or unlabeled. (The NAT is in the global domain, edge handoff > > to a vendor, so they are all egress points from the mpls mesh.) > > Another shot in that dark: Could it be something about flow masks and > some combination of NAT and MPLS making the NAT translations not work?
Yeah, that's come up - show fm fie shows no conflicts, but I've had some issues with NAT sessions before dropping due to having reflexive ACLs, mcast boundaries, and NAT all configured on the same switch (according to cisco L3, "pick any two" - supposedly it should be per-interface but it's really per PFC), though I could never pin it down. > Or do all TCP sessions actually come up, and are the drops only > intermittent? I lose about 1 in 8-10 packets. The connection comes up and stays up, but it's just incredibly slow. > You can see that in the LFIB, i.e. "show mpls forwarding-table". If this > link is the only MPLS link in the network the traffic should be > untagged because of PHP. It's the only link between dev A and dev B. dev B (which has the vendor connections w/NAT) has another inbound MPLS link, and dev A has a lot of other routes, so dev A has to publish labels for those. I need to look more closely at it later. (Basically I can only work on it after 5PM; I take down mpls during the prod day, and setting up a test environment that simulates what's going on is more work than just working on it after hours and then resetting the configs from RANCID.) > > I think I understand _why_ it's doing it - the summary route isn't a > > true summary, it's a static /16 on dev A, so it's redisted into EIGRP, > > so it gets a label. With a bit of work I can change this structure and > > advertise a /16 via EIGRP into dev A. > > The only problems I could think of regarding label allocation would > affect all traffic, not just drop things randomly. I know. It's just ... weird. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
