[c-nsp] mpls ip -> lost packets

[Peter Rathlev]

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?

Or do all TCP sessions actually come up, and are the drops only
intermittent?

> One can argue, based on my imperfect reading of Luc De Ghein's book,
> that the above-mentioned traffic in tag 275 really shouldn't be
> encapsulated at all - since dev A is the egress LSR, dev B would be
> the penultimate and should be popping the label (indeed it shouldn't
> be labeled at all, I suppose). 

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.

> 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.

-- 
Peter