MPLS-TE for VPN isn't working

[John Blakley]

Ok, here goes:

I have a vrf that I've configured to use a certain tunnel. I've verified that traffic is moving over the tunnel. When I put my bgp next-hop under the vrf, I lose all traffic across the tunnel. I'm running eigrp between the ce-pe, so I'm not sure if that's the problem. Does it only work with bgp peers? Here's the config on the routers, and this is in gns3:

PE-A

ip vrf Dragon

rd 100:100

route-target export 100:100

route-target import 100:100

bgp next-hop Loopback30

interface Tunnel2

ip unnumbered Loopback3

tunnel destination 9.9.9.9

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 7 7

tunnel mpls traffic-eng bandwidth  512

tunnel mpls traffic-eng path-option 1 explicit name Dragon

tunnel mpls traffic-eng path-option 2 dynamic

no routing dynamic

interface Loopback30

ip address 30.30.30.30 255.255.255.255

end

ip route 19.19.19.19 255.255.255.255 Tunnel2

PE-B

ip vrf Dragon

rd 100:101

route-target export 100:100

route-target import 100:100

bgp next-hop Loopback19

!

interface Tunnel2

ip unnumbered Loopback1

tunnel destination 3.3.3.3

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng path-option 1 dynamic

no routing dynamic

end

interface Loopback19

ip address 19.19.19.19 255.255.255.255

end

ip route 30.30.30.30 255.255.255.255 Tunnel2

I can ping 19.19.19.19 sourc from 30.30.30.30 and vice versa, so I believe the tunnels are passing traffic fine. Any help would be appreciated; this is irritating

[Edison Ortiz · Accepted solution]

I haven't done this in a while and I can't test at the moment but from what I recall, you need to enable MPLS on the TE so there is a label formed for the next hop (your new loopbacks).

[John Blakley]

I definitely see traffic going over the tunnel now. I enabled mpls on the tunnel interfaces, but none of the documentation that I've found mentioned doing that. The weird thing that I see now is this. From doing a ping on the CE side to another router through the mpls network, I can see the traffic going from PE-A to PE-B on the tunnel interface:

PE-A

R3#sh int tu2 | inc txload

     reliability 255/255, txload 32/255, rxload 1/255

PE-B

R9(config-if)#do sh int tu2 | inc txload

     reliability 255/255, txload 25/255, rxload 1/255

Why is PE-B showing txload also since it's the receiving side? Is this because the tunnels are one way?

Thanks Edison!

[Edison Ortiz]

Are you pinging? It has to reply hence transmit

BTW, I'm surprised the documentation didn't include that as a requirement. You created the loopbacks in the global routing table and now they are being used as next-hop for VPNs. Usually, the next-hop is your BGP VPNv4 peer between PEs and that exchange is labeled. You need to duplicate this design with your new loopbacks.

Before applying MPLS on the TE, any traffic entering the tunnel wasn't labeled so when you created the static route and pointed to the tunnel, a label was not formed.

You can verify with the show mpls forwarding command and you will see labels for the bgp next-hop on each router.

[John Blakley]

Um, yeah Wouldn't I be seeing receive on the other side also?

[Edison Ortiz · Accepted solution]

Yeah, I never trust those txload, rxload counters - I usually go with the packet input/output counters.

[John Blakley]

Are you talking about the 5 minute counters? My output is the only thing increasing for both sides. Oh well, it's working...

PE-A:

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 248000 bits/sec, 32 packets/sec

PE-B:

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 241000 bits/sec, 29 packets/sec

My counter is increasing to the customer side that I'm pinging that belongs to the same vrf:

CE-B

  reliability 255/255, txload 53/255, rxload 53/255

[Edison Ortiz]

As expected due to the unidirectional behavior with MPLS TE