A method to monitoractive MPLS label Mapping

draft-cauchie-opsawg-monitoring-mpls-label-mapping-00Gregory Cauchie (gregory.cauchie@orange-ftgroup.com)

IETF #79

Once upon a time…

• Received a call from operations“Can you help us? a PW got UP 15 minutes after the

IS-IS adjacency went back Up”

• Issues with the investigation– by that time, PW was UP and everything was OK.– adjacency is between 2 routers from different

vendors with two different behaviours• implementation issue?• protocol issue?• configuration issue?

The quest

• Check event timing from the IGP information– alternate path was available and timing OK

• Explore syslogs and SNMP servers– all label withdrawn/mapping were as expected

• Explore configuration/behaviour from different vendors – independent vs. ordered label distribution– Revisit the LDP RFC

• Try to reproduce the situation on the lab

Our conclusion

• sadly, no conclusions • we never found where the tunnel was broken• So we stayed with:

• we love LDP « plug-and-play »• but following the LDP events is too hard• vendors will not help without clues

• Problem statement is:- we need a solution to monitor tunnel establishment

over time and in details

Requirements

• get the relevant information about tunnel establishment, i.e. label mappings ‘in use’ or ‘active’, over time

• every routers send their information (because of label mappings local significance)

• don’t impact the network convergence• independence from the label distribution

protocol

Proposed approach

• use information from FTN and ILM tables• add timestamp• encode the whole set in XML• compress the XML information• send message over TCP session towards a

configured server– sending is delayed until convergence is done– new sending is scheduled after any MPLS forwarding

decision change (config, reroute, etc)

Why not using/upgrading existing stuff??

• OAM tools are good for online debugging, not offline troubleshooting

• SNMP gets comes with a polling issue• SNMP traps and Syslog suffer from

– no information ACK– no ‘interoperable’ information set– no ‘delay’ feature

• L3VPN context with PHP

Example of information set

VRF_1

Push label 11

Push label 22

Swap label 22 3

Pop label 11

R1 R2 R3

VRF_2

Minimal information set

Router ID = @R1FEC = [ type = VRF_ID ; Loopback IP address = @R3 ; RD = RD2 ]Ingress label value = [ (value = -1 ; origin = 'untagged')]Forwarding operation = [ operation = push ; label = 11 ; next-hop = recursive]Timestamp = 2010/10/10 15:30:01.674842

Message #1Router ID = @R1FEC = [ type = IP ; IP prefix = @R3/32 ]Ingress label value = [ (value = 11 ; origin = 'service')]Forwarding operation = [ operation = push ; label = 22 ; next-hop = @R2]Timestamp = 2010/10/10 15:30:01.674842

Message #2Router ID = @R2FEC = [ type = IP ; IP prefix = @R3/32 ]Ingress label value = [ (value = 22 ; origin = 'platform')]Forwarding operation = [ operation = swap ; label = 3 ; next-hop = @R3]Timestamp = 2010/10/10 15:30:01.674842

Router ID = @R3FEC = [ type = VRF_ID ; Loopback IP address = @R3 ; RD = RD2 ]Ingress label value = [ (value = 11 ; origin = 'platform')]Forwarding operation = [ operation = pop ; label = -1 ; next-hop = 'FEC'] Timestamp = 2010/10/10 15:30:01.674842

Next steps• Next actions on the document

– suggestion of using binary rather than XML• any preference?

– Improve mechanism for service announcements– text for message compression section– text for information sending section– example of Tunnels with ECMP– improve the connection establishment section

• Get more feedback. Opinions/comments?