Solved: Autoroute Announce is dropping traffic

evantol · ‎01-10-2014

I'm running 15.3(3)S on a group of three ME3600X switches and I'm having some issues testing autoroute announce. I've built a tunnel from one of my ME3600X switches to a remote router and the tunnel is up and accepts traffic from the local switch:

P2P TUNNELS/LSPs:

TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT

me3600-4.lab_to_cr3_lab 10.10.8.3 - Vl100 up/up

ME3600X-4.lab#ping 10.10.8.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.8.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

ME3600X-4.lab#sh int tun1 | inc pack

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

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

0 packets input, 0 bytes, 0 no buffer

5 packets output, 520 bytes, 0 underruns

However, as soon as I add 'tunnel mpls traffic-eng autoroute announce' to the tunnel configuration, IP traffic to destinations that are preferred through the tunnel drop from anywhere behind this ME3600:

ME3600X-4.lab#sh ip route 10.10.8.11

Routing entry for 10.10.8.11/32

Known via "isis", distance 115, metric 600, type level-2

Redistributing via isis lab-test

Last update from 10.10.8.3 on Tunnel1, 00:10:06 ago

Routing Descriptor Blocks:

* 172.16.24.149, from 10.10.8.11, 00:10:06 ago, via Vlan100

Route metric is 600, traffic share count is 1

10.10.8.3, from 10.10.8.11, 00:10:06 ago, via Tunnel1

Route metric is 600, traffic share count is 1

Here's a ping from a switch behind the ingress ME3600:

ME3600X-1.lab#ping 10.10.8.11

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.8.11, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Traffic is not making it into the tunnel at all, according to the tunnel stats, unless I ping from the ingress ME3600 switch:

ME3600X-4.lab#sh int tun1 | inc pack

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

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

0 packets input, 0 bytes, 0 no buffer

0 packets output, 0 bytes, 0 underruns

Traceroutes show the traffic dying at the ingress switch and packet captures on the upstream link from the ingress switch show no packets, plain IP or otherwise, exiting its upstream interface:

ME3600X-1.lab#traceroute 10.10.8.11

Type escape sequence to abort.

Tracing the route to 10.10.8.11

VRF info: (vrf in name/id, vrf out name/id)

1 172.16.32.1 [MPLS: Label 27 Exp 0] 0 msec 0 msec 0 msec

2 * * *

3

I'm just wondering what it is I'm doing wrong, it has to be something simple. A cluebat upside the head would be much appreciated. Here's the relevant config of the ingress switch:

ME3600X-4.lab#sh run int vl100

Building configuration...

Current configuration : 223 bytes

!

interface Vlan100

mtu 9000

ip address 172.16.24.150 255.255.255.252

ip mtu 1500

ip router isis lab-test

mpls ip

mpls traffic-eng tunnels

isis circuit-type level-2-only

isis metric 100

isis hello-interval 3

end

ME3600X-4.lab#sh run int vl4000

Building configuration...

Current configuration : 279 bytes

!

interface Vlan4000

mtu 9000

ip address 172.16.32.1 255.255.255.0

ip mtu 1500

ip router isis lab-test

mpls ip

mpls mtu 1546

mpls traffic-eng tunnels

isis metric 200

isis hello-interval 3

end

ME3600X-4.lab#sh run int tun1

Building configuration...

Current configuration : 242 bytes

!

interface Tunnel1

description me3600-4.lab_to_cr3_lab

ip unnumbered Loopback1

tunnel mode mpls traffic-eng

tunnel destination 10.10.8.3

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng path-option 1 dynamic

end

ME3600X-4.lab#sh run partition router isis lab-test

Building configuration...

Current configuration : 343 bytes

!

Configuration of Partition - router isis lab-test

!

router isis lab-test

net 47.0000.0101.8820.8024.00

is-type level-2-only

metric-style wide

passive-interface Loopback1

!

mpls traffic-eng router-id Loopback1

mpls traffic-eng level-1

mpls traffic-eng level-2

!

end

mtsb · ‎01-13-2014

Hi evantol,

The only thing that I can think of is that you are using vlan 100 interface as core facing MPLS interface for tunnel 1.

Can you try to change it to any physical interface than a virtual interface to see if the problem goes away?

If that doesn't solve the issue we need to check the hardware programming on ME3600 that will involve checking the NILE programming and its corresponding layer2 rewrites.

Thanks,

Madhu

View solution in original post

mtsb · ‎01-12-2014

Hi Evantol,

Can you draw a simple topology and mentioned from where to where you are doing a ping test?

You have mentioned that initially you had a tunnel setup and it accepts the traffic fine. Can you clarify how this tunnel accepts a traffic as you have not yet added the autoroute state? Creating a tunnel is just creating an ACL and without applying it, it is not going to be used. Autoroute announce is one way of preferring the tunnel in spite of other IGP paths. Not sure why it will drop the traffic. Please draw a simple topology, with the config before and after the ping failures.

Thanks,

Madhu

evantol · ‎01-13-2014

Here is the physical topology. Without "autoroute announce", the TE tunnel works as expected. I mis-spoke in my original post - no traffic is forwarded through the tunnel without autoroute announce, and this is expected.

Please note that there are no ACLs on any router interface, so the issue is not one of filtering. The configuration of the tunnel on the "24" switch is as such before the config change to add "autoroute announce":

interface Tunnel1

description me3600-4.lab_to_cr3_lab

ip unnumbered Loopback1

tunnel mode mpls traffic-eng

tunnel destination 10.10.8.3

tunnel mpls traffic-eng path-option 1 dynamic

end

Here is a ping and traceroute from the "21" switch to the "3" router before the configuration change:

ME3600X-1.lab#ping 10.10.8.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.8.3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

ME3600X-1.lab#traceroute 10.10.8.3

Type escape sequence to abort.

Tracing the route to 10.10.8.3

VRF info: (vrf in name/id, vrf out name/id)

1 172.16.32.1 [MPLS: Label 24 Exp 0] 0 msec 0 msec 0 msec

2 172.16.24.149 [MPLS: Label 302032 Exp 0] 0 msec 4 msec 0 msec

3 172.16.25.129 [MPLS: Label 301264 Exp 0] 0 msec 0 msec 0 msec

4 172.16.25.9 [MPLS: Label 301376 Exp 0] 4 msec 0 msec 0 msec

5 10.10.8.3 0 msec 0 msec 4 msec

ME3600X-1.lab#

Here is the configuration of the tunnel on the "24" switch after adding "autoroute announce":

interface Tunnel1

description me3600-4.lab_to_cr3_lab

ip unnumbered Loopback1

tunnel mode mpls traffic-eng

tunnel destination 10.10.8.3

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng path-option 1 dynamic

end

And here is a ping and traceroute from the "21" switch to the "3" router after the configuration change:

ME3600X-1.lab#ping 10.10.8.3 timeout 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.8.3, timeout is 0 seconds:

.....

Success rate is 0 percent (0/5)

ME3600X-1.lab#traceroute 10.10.8.3

Type escape sequence to abort.

Tracing the route to 10.10.8.3

VRF info: (vrf in name/id, vrf out name/id)

1 172.16.32.1 [MPLS: Label 24 Exp 0] 4 msec 0 msec 0 msec

2 * * *

3 *

ME3600X-1.lab#

Note that 172.16.32.1 is a VLAN interface on the "24" switch and is the VLAN/subnet that interconnects the 21, 22, and 24 switches. Pings from switch "24" to any destination that is preferred through the tunnel are successful, but no pings work from switches "21" and "22" - the traffic gets sent to switch "24" and is immediately dropped.

mtsb · ‎01-13-2014

Hi Evantol,

If I understand correctly your TE tunnel is from ME switch 24 to the router 3 and you are trying to ping from a switch say 21 or 22 behind ME switch 24 and it is not working.

1. Can you try to add "mpls ip" under the tunnel interface and try a ping?

2. What does the path TE tunnel takes before and after adding the autoroute statement?

3. Try a "traceroute mpls traffic-eng tunnel " and check if the path is same?

Thanks,

Madhu

evantol · ‎01-13-2014

Hi Madhu,

Unfortunately, adding 'mpls ip' to the tunnel interface doesn't help - pings still drop from behind the "24" switch. The path is the exact same whether 'autoroute announce' is configured or not:

ME3600X-4.lab#traceroute mpls traffic-eng tunnel 1

Tracing MPLS TE Label Switched Path on Tunnel1, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'l' - Label switched with FEC change, 'd' - see DDMAP for return code,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 172.16.24.150 MRU 9000 [Labels: 302096 Exp: 0]

L 1 10.10.8.12 MRU 9192 [Labels: 301408 Exp: 7] 32 ms

L 2 10.10.8.7 MRU 9192 [Labels: 301552 Exp: 7] 32 ms

L 3 10.10.8.5 MRU 9192 [Labels: implicit-null Exp: 0] 24 ms

! 4 10.10.8.3 1 ms

ME3600X-4.lab#conf t

Enter configuration commands, one per line. End with CNTL/Z.

ME3600X-4.lab(config)#int tun1

ME3600X-4.lab(config-if)#no tunnel mpls traffic-eng autoroute announce

ME3600X-4.lab(config-if)#end

ME3600X-4.lab#conf t

*Jan 14 01:33:20.750: %SYS-5-CONFIG_I: Configured from console by console

ME3600X-4.lab#traceroute mpls traffic-eng tunnel 1

Tracing MPLS TE Label Switched Path on Tunnel1, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,

'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,

'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,

'P' - no rx intf label prot, 'p' - premature termination of LSP,

'R' - transit router, 'I' - unknown upstream index,

'l' - Label switched with FEC change, 'd' - see DDMAP for return code,

'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 172.16.24.150 MRU 9000 [Labels: 302096 Exp: 0]

L 1 10.10.8.12 MRU 9192 [Labels: 301408 Exp: 7] 24 ms

L 2 10.10.8.7 MRU 9192 [Labels: 301552 Exp: 7] 28 ms

L 3 10.10.8.5 MRU 9192 [Labels: implicit-null Exp: 0] 24 ms

! 4 10.10.8.3 4 ms

mtsb · ‎01-13-2014

Hi Evantol,

Okay.

Can you provide me the following?

1. "show ip route 10.10.8.3" from switch 21 and 24 before and after the command addition.

2. "show ip cef 10.10.8.3 detail/internal " from switch 21 and 24 before and after the command addition.

3. Are the interfaces from 21 switch is MPLS enabled until 24 or it is like plain IP and then converted to MPLS on 24 switch?

4. What does the "show ip cef exact-route 10.10.8.3 shows before and after that command from 24 switch?

5. sho mpls forwarding-table 10.10.8.3 from switch 24

Looks like the switch 24 is not able to either impose a tag or swap the tag and send out to next hop.

Thanks,

Madhu

mtsb · ‎01-13-2014

and send me "show mpls traffic-eng tunnel tunnel 1" from the 24 switch.

evantol · ‎01-13-2014

Looks like the switch 24 is not able to either impose a tag or swap the tag and send out to next hop.

That's what I thought, too, as the traffic is not even leaving the 24 switch, according to packet captures taken between the 24 switch and the 12 router.

1. "show ip route 10.10.8.3" from switch 21 and 24 before and after the command addition.

Switch 21 before the command addition:

ME3600X-1.lab#sh ip route 10.10.8.3

Routing entry for 10.10.8.3/32

Known via "isis", distance 115, metric 700, type level-2

Redistributing via isis

Last update from 172.16.32.1 on Vlan4000, 3d09h ago

Routing Descriptor Blocks:

* 172.16.32.1, from 10.10.8.3, 3d09h ago, via Vlan4000

Route metric is 700, traffic share count is 1

ME3600X-1.lab#sh ip cef 10.10.8.3 detail

10.10.8.3/32, epoch 0

local label info: global/23

nexthop 172.16.32.1 Vlan4000 label 39

ME3600X-1.lab#sh ip cef 10.10.8.3 internal

10.10.8.3/32, epoch 0, RIB[I], refcount 5, per-destination sharing

sources: RIB, LTE

feature space:

IPRM: 0x00028000

LFD: 10.10.8.3/32 1 local label

local label info: global/23

contains path extension list

disposition chain 0x12BB5E40

label switch chain 0x12BB5E40

ifnums:

Vlan4000(4144): 172.16.32.1

path 1291D528, path list 12A78CDC, share 1/1, type attached nexthop, for IPv4

MPLS short path extensions: MOI flags = 0x0 label 39

nexthop 172.16.32.1 Vlan4000 label 39, adjacency IP adj out of Vlan4000, addr 172.16.32.1 12841840

output chain: label 39 TAG adj out of Vlan4000, addr 172.16.32.1 128413E0

ME3600X-1.lab#sh ip cef exact-route 10.10.8.21 10.10.8.3

10.10.8.21 -> 10.10.8.3 => label 39 TAG adj out of Vlan4000, addr 172.16.32.1

Switch 24 before the command addition:

ME3600X-4.lab#sh ip route 10.10.8.3

Routing entry for 10.10.8.3/32

Known via "isis", distance 115, metric 500, type level-2

Redistributing via isis

Last update from 172.16.24.149 on Vlan100, 00:03:44 ago

Routing Descriptor Blocks:

* 172.16.24.149, from 10.10.8.3, 00:03:44 ago, via Vlan100

Route metric is 500, traffic share count is 1

ME3600X-4.lab#sh ip cef 10.10.8.3 detail

10.10.8.3/32, epoch 0

local label info: global/39

nexthop 172.16.24.149 Vlan100 label 302032

ME3600X-4.lab#sh ip cef 10.10.8.3 internal

10.10.8.3/32, epoch 0, RIB[I], refcount 5, per-destination sharing

sources: RIB, LTE

feature space:

IPRM: 0x00028000

LFD: 10.10.8.3/32 1 local label

local label info: global/39

contains path extension list

disposition chain 0x12B16A58

label switch chain 0x12B16A58

ifnums:

Vlan100(244): 172.16.24.149

path 124EF1A0, path list 12504414, share 1/1, type attached nexthop, for IPv4

MPLS short path extensions: MOI flags = 0x0 label 302032

nexthop 172.16.24.149 Vlan100 label 302032, adjacency IP adj out of Vlan100, addr 172.16.24.149 128322A0

output chain: label 302032 TAG adj out of Vlan100, addr 172.16.24.149 12831E40

ME3600X-4.lab#sh ip cef exact-route 10.10.8.21 10.10.8.3

10.10.8.21 -> 10.10.8.3 => label 302032 TAG adj out of Vlan100, addr 172.16.24.149

Switch 21 after the command addition:

ME3600X-1.lab#sh ip route 10.10.8.3

Routing entry for 10.10.8.3/32

Known via "isis", distance 115, metric 700, type level-2

Redistributing via isis atlantech

Last update from 172.16.32.1 on Vlan4000, 3d09h ago

Routing Descriptor Blocks:

* 172.16.32.1, from 10.10.8.3, 3d09h ago, via Vlan4000

Route metric is 700, traffic share count is 1

ME3600X-1.lab#sh ip cef 10.10.8.3 detail

10.10.8.3/32, epoch 0

local label info: global/23

nexthop 172.16.32.1 Vlan4000 label 39

ME3600X-1.lab#sh ip cef 10.10.8.3 internal

10.10.8.3/32, epoch 0, RIB[I], refcount 5, per-destination sharing

sources: RIB, LTE

feature space:

IPRM: 0x00028000

LFD: 10.10.8.3/32 1 local label

local label info: global/23

contains path extension list

disposition chain 0x12BB5E40

label switch chain 0x12BB5E40

ifnums:

Vlan4000(4144): 172.16.32.1

path 1291D528, path list 12A78CDC, share 1/1, type attached nexthop, for IPv4

MPLS short path extensions: MOI flags = 0x0 label 39

nexthop 172.16.32.1 Vlan4000 label 39, adjacency IP adj out of Vlan4000, addr 172.16.32.1 12841840

output chain: label 39 TAG adj out of Vlan4000, addr 172.16.32.1 128413E0

ME3600X-1.lab#sh ip cef exact-route 10.10.8.21 10.10.8.3

10.10.8.21 -> 10.10.8.3 => label 39 TAG adj out of Vlan4000, addr 172.16.32.1

Switch 24 after the command addition:

ME3600X-4.lab#sh ip route 10.10.8.3

Routing entry for 10.10.8.3/32

Known via "isis", distance 115, metric 500, type level-2

Redistributing via isis

Last update from 10.10.8.3 on Tunnel1, 00:02:01 ago

Routing Descriptor Blocks:

* 10.10.8.3, from 10.10.8.3, 00:02:01 ago, via Tunnel1

Route metric is 500, traffic share count is 1

ME3600X-4.lab#sh ip cef 10.10.8.3 detail

10.10.8.3/32, epoch 0

local label info: global/39

nexthop 10.10.8.3 Tunnel1

ME3600X-4.lab#sh ip cef 10.10.8.3 internal

10.10.8.3/32, epoch 0, RIB[I], refcount 5, per-destination sharing

sources: RIB, LTE

feature space:

IPRM: 0x00028000

LFD: 10.10.8.3/32 1 local label

local label info: global/39

contains path extension list

disposition chain 0x12B18078

label switch chain 0x12B16A58

ifnums:

Tunnel1(4303)

path 124EEB80, path list 125042D4, share 1/1, type attached nexthop, for IPv4

MPLS short path extensions: MOI flags = 0x1 label implicit-null

nexthop 10.10.8.3 Tunnel1, adjacency IP midchain out of Tunnel1 12832FC0

output chain: IP midchain out of Tunnel1 12832FC0 label 302096 TAG adj out of Vlan100, addr 172.16.24.149 12831E40

ME3600X-4.lab#sh ip cef exact-route 10.10.8.21 10.10.8.3

10.10.8.21 -> 10.10.8.3 => label 302096 TAG adj out of Vlan100, addr 172.16.24.149

5. sho mpls forwarding-table 10.10.8.3 from switch 24

ME3600X-4.lab#show mpls forwarding-table 10.10.8.3 detail

Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface

39 Pop Label 10.10.8.3/32 126 Tu1 point2point

MAC/Encaps=14/18, MRU=9000, Label Stack{302096}, via Vl100

009069C7FC3E5017FF5A18408847 49C10000

No output feature configured

3. Are the interfaces from 21 switch is MPLS enabled until 24 or it is like plain IP and then converted to MPLS on 24 switch?

The interface connecting the 21, 22, and 24 switches is an SVI, VLAN4000, and has 'mpls ip' configured on it. I've tried disabling MPLS on the SVI on each switch with no change.

Thanks for these commands, as some of them are new ones to me that can help me in the future.

mtsb · ‎01-13-2014

Hi evantol,

The only thing that I can think of is that you are using vlan 100 interface as core facing MPLS interface for tunnel 1.

Can you try to change it to any physical interface than a virtual interface to see if the problem goes away?

If that doesn't solve the issue we need to check the hardware programming on ME3600 that will involve checking the NILE programming and its corresponding layer2 rewrites.

Thanks,

Madhu

evantol · ‎01-14-2014

Madhu,

That seemed to do it!

ME3600X-1.lab#tr 10.10.8.3

Type escape sequence to abort.

Tracing the route to 10.10.8.3

VRF info: (vrf in name/id, vrf out name/id)

1 172.16.32.1 [MPLS: Label 39 Exp 0] 0 msec 0 msec 0 msec

2 172.16.24.149 [MPLS: Label 302288 Exp 0] 4 msec 0 msec 0 msec

3 172.16.25.129 [MPLS: Label 301584 Exp 0] 0 msec 4 msec 0 msec

4 172.16.25.9 [MPLS: Label 301728 Exp 0] 0 msec 0 msec 0 msec

5 10.10.8.3 4 msec 0 msec 0 msec

I would like to mention that changing that same interface to a normal switchport instead of a switchport that supports EVC-style configuration resolves the problem, too. I am having a similar problem with dropped packets inside the switch in a case I've had open with TAC for a couple of months and they've been unable to reproduce it. I am hopeful that this issue I've run into with autoroute announce can allow them to at least reproduce the behavior and resolve my case.

mtsb · ‎01-14-2014

Hi Eric,

Great that it fixed your issue. In fact I came across the case you mentioned with TAC as I do work for TAC here:-)

I believe the SVI interface as core facing MPLS was introduced in 15.3(01)S version and I have come across some issues with this feature with various combinations. If this is not your production may be you can help us to share your setup where someone from engineering can take a look at. There are a lot of issues that can't be reproduced inhouse in our lab for various unknown reasons and this could be one of them. TAC is always at customer's service to fix their issues so feel free to talk to them on other options we have.

Thanks,

Madhu

evantol · ‎01-14-2014

Thanks, Madhu. What do you feel the best course of action is? Should I open a new case on this or continue logging it to my currently open case.

The odd part about my open case is that it seems to be based solely upon destination prefix *length*, whereas this one is quite different, but the same exact symptoms.

mtsb · ‎01-14-2014

Hi Eric,

I am giving a bit mroe thinking on this one. I need to check if we really support SVI core facing MPLS interface as TE tunnel egress interface. Because normally we configure a TE tunnel to protect a physical link failure but if we use a virtual interface like SVI then how are we going to protect it! I will check on this and get back to you.

The best way to move forward is to capture all the information clearly and open up a new case and make sure you point the other case that is ongoing as well. If TAC finds these 2 related probably one can be duplicated to other else we can deal with these 2 issues separately.

Thanks,

Madhu

evantol · ‎01-14-2014

I suppose that depends on what you mean by "protect" . For one, if the SVI is in a bridge domain and the SVIs physical interfaces go down, that would cause an event which would force a recalculation of the tunnel, no? Additionally, I would say that protection is only one reason a TE tunnel would be configured. Regardless of the reason for the tunnel, it would be good to know if this is officially supported, since I could not find anything saying it wasn't in the documentation.

The issue seems to be tied more to the fact that the SVI is in a bridge domain that's called by an EFP service instance. It seems to work fine when the physical port is configured as a 'switchport trunk allowed vlan 100', which is the same thing as the open case. However, in that case, the issue only appears on 10G ports configured with the EFP - 1G ports with the EFP work fine. This issue has a 1G core-facing port and it doesn't work, but the interconnecting ports between the ME3600s are all 10G. The only reason I bring this up is because it's my understanding that the 10G ports are on a different ASIC than the 1G ports, which was pointed to as a possible source of the problem (switching/routing from one ASIC to another).

mtsb · ‎01-14-2014

Hi Eric,

Yes you are right about the physical interface tied to a SVI going down will trigger TE recalc but if a FRR protection is configured for such interface then the internal chain that needs to be formed beforehand which gives the 50 ms swithcover time has to be different when a FRR protection is configured for a physical interface. Keeping the purpose apart as you said we need to find out if a TE tunnel with SVI MPLS core as egress is supported or not or it is something that is missed while the feature is developed or is it something that they are aware of and planned to bring in as phase2 of this feature.

So, in a nutshell the issue is as below (correct or add to this list)

TE tunnel with SVI core with EVC BD on a 1 Gig interface - Working

TE tunnel with SVI core with EVC BD on a 10 Gig interface - Not working

TE tunnel with SVI core with switchport on a 1 Gig interface - Working

TE tunnel with SVI core with switchport on a 10 Gig interface - Working

The 1Gig ports are managed by NILE0 and 10G ports are managed by NILE1 forwarding asic.

Thanks,

Madhu