Autoroute Announce is dropping traffic
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
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.
Similar Messages
-
MPLS TE tunnel autoroute announce metric in SPF computation
Hi, I have a doubt whether MPLS TE tunnel metric is taking into SPF computation when the tunnel has "autoroute announce" configured.
From the book "MPLS traffice enginnering" written by Osbourn, IGP SPF computation is always performed before tunnel metric is modified, I found this is only true if IGP is ISIS, but if IGP is OSPF, tunnel metric specified by "autoroute metric" will always be taken into SPF computation, a.k.a, if tunnel metric is configured to be less than underlying IGP metric, a suboptimal routing will always happen to destination routers that are in between tunnel head and tunnel tail.
Any idea why there is a inconsistent behavior between OSPF and ISIS SPF computation? or I missed anything?Hi,
You're right. There is a different behavior between OSPF and ISIS on how they handle the autoroute metric feature.
ISIS: TE tunnel metric is not taken into account during SPF computation.
OSPF: TE tunnel metric is taken into account during SPF computation.
So playing with this feature can change the SPT if your IGP is OSPF.
The difference seems coming from the SPF implementation of OSPF and ISIS
HTH
Laurent. -
Wireless Bridge dropping traffic
Hi,
We have 2 x AIR-BR1310 setup with a point to point bridge between 2 offices, see below.
Office2---Bridge2------Bridge1---Office1
At random periods of the day the link drops and office1 is unable to contact office2. Upon further inspection the Bridges report that the wireless association is still active and this is confirmed as Bridge1 can still ping the BVI interface on Bridge2.
I telneted to the console on Bridge2 and attempted to ping hosts in Office2, all ping attempts failed. The BVI and Fastethernet interfaces on Bridge2 are both up and there are no errors on the interfaces.
To resolve the issue we have to perform a hard reboot on Bridge2, as soon as the bridge comes back up traffic passes as normal. We have tried rebooting the switches and Bridge1 but the network still drops traffic, its only when Bridge2 is rebooted that operation returns to normal.
Any ideas?If the bridge link stays up, and you can get to the BVI interface, then this isn't a wireless problem. The problem should be on the other side of the radio interface.
What do you have installed on the other side? Does the bridge connect directly to a switch? Can Bridge 2 ping its default-gateway? -
SFR drops traffic when policy is out-of-date?
Hi,
We are evaluating a 5515X with FireSIGHT.
I am routing a few guest networks through the lab ASA but are experiencing some strangeness :)
Three times it has suddenly started dropping traffic, and I really can't pinpoint the reason..
The things that I have noticed when I get the warning from our support staff, is that there are policies out-of-date on the ASA. (See att. img policy_out-of-date.png). And the when I apply the policies the traffic starts again..
And when I look at the logs from the ASA the thing thats sticks out is the sudden spike of SYN Timeouts (See att. img syn_timouts.png).
I have "Inspect traffic during policy apply = Yes", and I have read that this could stop the traffic "when applying" the policy. But should that really block traffic when the policy is out-of-date?
Do you guys have any idea whats happening here, or noticed anything like this before?
Is there a log that shows why the policy gets out-of-date?
Regards FalkAs far as getting the package in the repo updated as mentioned above it all depends on the maintainer for that particular package. What you can do to help is go to the homepage, search for the package and flag it as out of date. FYI this has already been done for mythtv.
To upgrade on your own the best way to do it is start from the same PKGBUILD that is used to build the official package through abs. You can find all the info you need on the wiki page.
Typically the PKGBUILDs in the AUR have some different functionality from the main version in the repo, and aren't usually what you are looking for if all you want is a version bump.
It is usually best to remove your installed version before using a version from AUR. Most AUR PKGBUILDs will have conflicts (and provides) for other versions of the same package and thus pacman will give an error when trying to install it. If you are just bumping the version of the same package you will not need to remove it first.
EDIT: You can use pacman -Rd to remove (and replace) a package if others depend on it.
Last edited by quigybo (2010-06-18 04:51:24) -
Hello,
I've got a cisco WLC 2504 with the latest firmware. And created an AVC profile to drop Whatsapp and Facebook traffic.
I added this to the WLAN I configurerd, but the traffic doesn't get dropped with cell phones.
If I've a cell phone which has the apps (whatsapp and Facebook) installed, AVC wont drop te traffic.
It does drop the traffic if I use a browser to go to Facebook. Is this some kind of bugg?
Regards,
TomUnfortunately you have to wait for the next release of software code (not sure when 8.0MR1 comes it will have the updated protocol pack),.
Even if it is a bug, without updating these AVC signatures, I do not think you can fix it. Here is the release not confirming this
http://www.cisco.com/c/en/us/td/docs/wireless/controller/nbar2_prot_pack/11-0-0/b-nbar2-prot-pack-1100/b-nbar2-prot-pack-1100_chapter_010101.html#wp2108825774
Network-Based Application Recognition (NBAR2) Protocol Pack 11.0.0 support is provided for Cisco Wireless LAN Controller platforms, starting with the 8.0 release.
NBAR2 Protocol Pack 11.0.0 is supported on the following Cisco Wireless LAN Controller platforms:
Cisco 5508 Wireless Controller
Cisco Flex 7500 Series Wireless Controllers
Cisco 8510 Wireless Controller
Cisco Wireless Services Module 2 (WiSM2)
Note
Cisco Wireless LAN Controller software release 8.0, uses NBAR engine 16, and contains NBAR2 Protocol Pack 9.0.0 built-in. For more information on software releases and compatible protocol packs, see Working with Protocol Packs.
Though the NBAR2 protocol library and the protocol signatures support IPv6 traffic classification, Cisco Wireless LAN Controller platforms currently support only IPv4 traffic classification.
The Cisco 2504 Wireless Controller supports Application Visibility and Control, but supports only built-in protocol packs present in Wireless LAN Controller software releases. It does not support downloading and installing protocol packs.
**** Pls do not forget to rate our responses if it useful ****
HTH
Rasika -
Hi Everyone.
I am working at a site that has a Cisco router that is setup to connect the LAN to the internet. The client runs a VoIP service hosted by the provider. We have noticed packets are dropping. Calls connect but there isn't two-way flow, you can't hear the party at the other end. I wanted to drop this at the feet of the VoIP provider but then I did a sh ip cache flow on the router and this is what I noticed.
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Gi0/1 172.30.0.136 Null xx.xxx.32.89 01 0000 0800 922
All the time traffic to the provider's server, xx.xxx.32.89 is always sent to the Null interface instead of the G0/0.
I don't know if this has a bearing on the problem, but when I connected a Linksys router, we did not have this problem.
Any help would be appreciated.Hello
Are you using quality of service on the cisoc router or on the lan switch?
do you know what your ISP making for voice should be?
Has any changes been made to your network and if so has this problem occurred since that change !
res
Paul -
Randomly Dropping Traffic - Bad Tech Support - Should I Switch ISP?
Summary
I replaced the Verizon router with a Cisco router that support being an IPSec VPN Tunnel end-point. I switched from the coax to the Ethernet port on the ONT as the router doesn't have a coax port. Next I configured the IPSec Tunnel on the router, and I was a happy camper because I now have access to the company LAN.
[Fast forward a week.]
Phone calls started sounding choppy so I investigated. It now seems like there is a ~15% packet loss for VPN traffic. How did that happen? I spent 2 full days triaging the issue ... I'll spare the details ... and I narrowed down the packet drops to somewhere between the local Verizon ONT and the remote site modem.
As a test, I temporarily switch my Internet connection to my handy iPhone 4 hotspot (thanks AT&T )
To my surprise ... no packet loss. So that narrows it down to the ONT and the Verizon network. So I contacted tech support and wasted almost an hour with someone who was absolutely no help. To top it off, he tried to sell me on some Expert Care package -- apparently he himself is neither an expert nor does he care -- for me to get my service issues resolved.
Now the question for me is, should I continue struggling with this subpar support service, or should I switch to another more helpful ISP?
Solved!
Go to Solution.Physical Connections:
PC----[Router A]--(Ethernet Port)[ONT]===={{{{Verizon Cloud}}}}==={{{{Time Warner Cloud}}}}====[Modem]----[Router B]
The central VPN point is Router B.
Router A is a remote VPN client. Alternatively, if VPN is disabled on the router, the PC behind Router A can also connect with a software VPN client.
No.
The configuration is fine.
The IPSec tunnel gets established.
The VPN has worked fine for two weeks.
Starting yesterday, random IPSec encapsulated packets from Router A to Router B are getting dropped.
~30% packet loss.
This happens with either the PC or Router A as VPN client.
(Please note that Router A is not the Verizon supplied Router.)
Also, pings from Router A to Router B outside the VPN tunnel have 100% success rate.
I narrowed down the packet drop to somewhere from the ONT to maybe the Verizon clould (packet filtering or inspection?).
Can you reload the ONT?
Thanks.
Will do.
Done.
There only is a 3rd party router.
There is no Verizon supplied router.
PC----[Cisco UC520 Router]====[ONT] -
Site to site between 892s, video streaming, fragments and dropped traffic
Customer network consists of two LANs, each routed from an 892. The 892s are connected by a Gig fiber path, and there's an IPSec VPN between the 892s. All traffic from one LAN to the other traverses the VPN. Site 1 has a Lenel video server with a bunch of cameras streaming video to it. Site 1 and Site 2 each have a Win7 PC with some Lenel software that receives video streams retransmitted from the video server at Site 1. The video server streams the video as UDP. The client PC at Site1 receives all the video streams from the server just fine. The client PC at Site 2 does not reliably receive the video streams from the server at Site 1. Streams from *some* cameras are received fine, but not others. Looking at Wireshark captures taken at Site 1, it looks like most of the UDP traffic is fragmented.
Anyone else out there have anything remotely like this setup, and any notions of where to go looking for why Site 2's got such issues?
I'm afraid I'm somewhat constrained by all sorts of legal and bureaucratic restrictions on exactly what configuration and sample data I can include in this discussion, which would make me laugh if it wasn't so frustrating (this is a network of security cameras around a sensitive research facility).Hi Julio,
Everything seems to be ok in this access list. I think this is a routing issue. It is just does not know where to send the packet back or where to reply.
Crypto map tag: XXXX_map, seq num: 7, local addr: x.x.x.x
access-list XXXX_7_cryptomap permit ip x.x.x.x x.x.x.x x.x.
x.x x.x.x.x
local ident (addr/mask/prot/port): (local network and subnet)
remote ident (addr/mask/prot/port): (Remote network and subnet)
current_peer: x.x.x.x
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 9122, #pkts decrypt: 9122, #pkts verify: 9122
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: x.x.x.x, remote crypto endpt.: x.x.x.x
path mtu 1500, ipsec overhead 58, media mtu 1500
current outbound spi:
inbound esp sas:
spi:
transform: esp-des esp-md5-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: .., crypto-map: xxxx_map
sa timing: remaining key lifetime (sec): 18731
IV size: 8 bytes
replay detection support: Y
outbound esp sas:
spi:
transform: esp-des esp-md5-hmac none
in use settings ={L2L, Tunnel, }
slot: 0, conn_id: 8849, crypto-map: xxxx_map
sa timing: remaining key lifetime (sec): 18673
IV size: 8 bytes
replay detection support: Y -
How traffic is directed in MPLS network? Via ldp LSPs or via RSVP LSPs
My question is basicly to understand how traffic is treated.
Lets assume our topology is :
A-----------------------------B------------------------------------C--------------------------------------------D
1-) if we just enable MPLS under all interfaces, LDP labels are exchanged with each peer. At that moment RIB, LIB, FIB and LFIB are created on all routers. So LDP LSPs are created dynamicly. but If i ping "loopback D" from router A, there will be IP routing or LABEL switching. will routing make routing by looking IP address at each hop or labels will be swapped at each hop ?
2-) If we enable MPLS traffic engineering capability and create a tunnel interface between router A and router D, vice versa. At that moment, Router A will have :
-simple IGP reachability to Router D,
-Dynamic LDP LSP and
-RSVP tunnel.
what about now, Which one of the paths above my traffic will follow ? do I have to direct my traffic to tunnel interface signaled via RSVP. Is there any precedence for choosing the path that traffic will be addressed ?for second secenario, i have found that I have to write
"tunnel mpls traffic-eng autoroute announce " other wise traffic will always follow LDP signaled paths. In order to get all traffic inside "tunnel" we should execute that command. once you write that command you see that ;
Before executing command;
R1#sh ip route
O 3.3.3.3 [110/129] via 3.3.3.3, 00:07:08, serial0/0
R1#show mpls forwarding-table
18 18 3.3.3.3/32 0 Se0/0 point2point
After executing command;
R1#sh ip route
O 3.3.3.3 [110/129] via 3.3.3.3, 00:07:08, Tunnel0
R1#show mpls forwarding-table
18 Pop tag [T] 3.3.3.3/32 0 Tu0 point2point
Hope you see my point, router doesnt decide to use RSVP signaled LSP itself, we shoud trig router to use RSVP signalled LSP. -
Tunnel mpls traffic-eng dynamic reoptimization issue
we have a dynamic tunnel, when the LSP switches to a suboptimal path due to failure on the optimal path it does not switch back to the optimal path once the path is restored.
How do we enable automatic reoptimization plus a threshold setting re = 5 seconds
interface Tunnel0
description test
ip unnumbered Loopback0
tunnel destination 211.1.219.6
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamicIf you do a "show mpls traffic-eng tunnels brief" you will see that the default periodic optimization is set to 1 hour (3600 seconds).
You can use the following command to change this default timer:
mpls traffic-eng reoptimize timers frequency
For more information on this command, please see this URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/swtch_r/swi_m3.htm#wp1061558
Hope this helps, -
Hi ... we have xconnect problem between our PE-Router when we apply TE on this xconnect. The xconnect is between Cisco 7600 (s72033-advipservicesk9_wan-mz.122-33.SRA3.bin) and Cisco 7206 NPEG2 (c7200p-advipservicesk9-mz.124-11.T3.bin). The problem is xconnect from 7600 to 7206 is up, but xconnect from 7206 to 7600 is down. We have try to test this TE xconnect to different PE, but still got same symptom. There's no problem if we don't apply TE on this xconnect.
The path from TE is:
PE(7606) - P(7606) - PE(7206). The TE path between 7606 to 7206 and 7206 to 7606 is via same physical path.
Cisco-7606:
#sh mpls l2transport vc 896 detail
Local interface: Po1.896 up, line protocol up, Eth VLAN 896 up
Destination address: 116.199.192.146, VC ID: 896, VC status: up
Output interface: Tu5, imposed label stack {57 41}
Preferred path: Tunnel5, active
Default path: disabled
Next hop: point2point
Create time: 00:00:23, last status change time: 00:00:23
Signaling protocol: LDP, peer 116.199.192.146:0 up
MPLS VC labels: local 19, remote 41
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 0, send 0
byte totals: receive 0, send 0
packet drops: receive 0, send 0
Cisco 7206:
#sh mpls l2transport vc 896 detail
Local interface: Gi0/2.896 up, line protocol up, Eth VLAN 896 up
Destination address: 116.199.192.130, VC ID: 896, VC status: down
Preferred path: Tunnel1, active
Default path: disabled
Output interface: unknown, imposed label stack {}
Create time: 3d23h, last status change time: 00:00:12
Signaling protocol: LDP, peer 116.199.192.130:0 up
MPLS VC labels: local 41, remote 19
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 0, send 0
byte totals: receive 0, send 0
packet drops: receive 0, seq error 0, send 171145
Appreciate if someone can help.
thks,rezahi shivlu,
there's no problem with TE path, and already test some TE between my 7606-PE to several 7206-PE, and got some result.
the TE config is like this:
7606-PE:
ip explicit-path name METRO_BDG_MORA-GIG-1/5 enable
next-address xxx.xxx.xxx.xxx
next-address xxx.xxx.xxx.xxx
next-address xxx.xxx.xxx.xxx --> 7206-PE Loopback 0 IP address
interface Tunnel5
ip unnumbered Loopback0
tunnel destination xxx.xxx.xxx.xxx --> 7206-PE Loopback 0 IP address
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 1 explicit name METRO_BDG_MORA-GIG-1/5
tunnel mpls traffic-eng path-option 2 dynamic
tunnel mpls traffic-eng record-route
tunnel mpls traffic-eng load-share 10
pseudowire-class TE_METRO_BDG_MORA_GIG-1/5
encapsulation mpls
preferred-path interface Tunnel5 disable-fallback
7206-PE:
ip explicit-path name BDG_METRO_MORA-GIG-0/1 enable
next-address xxx.xxx.xxx.xxx
next-address xxx.xxx.xxx.xxx
next-address xxx.xxx.xxx.xxx --> 7606-PE Loopback 0 IP address
interface Tunnel1
ip unnumbered Loopback0
tunnel destination xxx.xxx.xxx.xxx --> 7606-PE Loopback 0 IP address
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 1 explicit name BDG_METRO_MORA-GIG-0/1
tunnel mpls traffic-eng path-option 2 explicit name BDG_METRO_XL-SE-6/0
tunnel mpls traffic-eng record-route
tunnel mpls traffic-eng load-share 10
pseudowire-class TE_BDG_METRO_MORA_GIG-0/1
encapsulation mpls
preferred-path interface Tunnel1 disable-fallback -
Hi
Need some discussion on MPLS - TE tunnel issue.
One of Tunnel with FRR configured, creates problem after a while affects the traffic running on the link until I shut the tunnel manually.
Configs are ok because same configurations made for different cities to authenticate to a AAA server located in one of city.
following is the generic diagram and complete config for respective links in all 3 cities but the tunnel on link highlighted with RED arrow creates problem after a while not at once until I shut the tunnel,
The Platform is Cisco CISCO7609-S and all links are on 7600-SIP-400 module
interface GigabitEthernet2/2/0
description *** Physical Interface ***
dampening
mtu 9216
ip address x.x.x.x x.x.x.x
no ip redirects
no ip proxy-arp
ip ospf message-digest-key 1 md5 7 xxx
ip ospf network point-to-point
load-interval 30
carrier-delay msec 0
negotiation auto
mpls traffic-eng tunnels
mpls traffic-eng backup-path Tunnel2300
mpls ip
service-policy output egress_policy
hold-queue 4096 in
hold-queue 4096 out
ip rsvp bandwidth percent 95
ip rsvp signalling dscp 48
end
x.x.x.x#sh running-config int tun 1300
Building configuration...
Current configuration : 377 bytes
interface Tunnel1300
description *** Primary Tunnel ***
ip unnumbered Loopback0
shutdown
mpls ip
tunnel destination x.x.x.x
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 explicit name path-1300
tunnel mpls traffic-eng fast-reroute
end
x.x.x.x#sh running-config int tun 2300
Building configuration...
Current configuration : 332 bytes
interface Tunnel2300
description *** Backup Tunnel ***
ip unnumbered Loopback0
shutdown
mpls ip
tunnel destination x.x.x.x
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 10 explicit name path-2300
tunnel mpls traffic-eng record-route
endHi,
Issue was figured out, the traffic was dropping dut to EF tagged traffic in the service policy applied under the physical interface.
The limit of EF tagged traffic was defined less as per actual traffic which was causing drop in peak hours -
MPLS TE load-balancing --- CEF Problem
Dears
Would like your assistance please regarding below issue
We are having 5 TE tunnels going to same destination and we are doing load-balancing between these 5 LSPs TE tunnels.
Command "mls ip cef load-sharing full simple" is configured so that CEF will use L4 ports in its algorithm
Problem that due to CEF behavior, 2 link are v.highly utilized and the other 3 utilization are below average
What I am thinking of but not sure If this will help or not is to have 2 TE tunnels instead of 5
1 TE tunnel load balancing on 3 links ( This can be done by using static route to tail loopback poiting to the 3 links) and another TE tunnel load balancing on the other 2 links
By doing this, I think CEF would be used 2 times; first to determine which TE tunnel to use then to determine which link within the tunnel
Will this help ?
For example
interface Tunnel1
ip unnumbered Loopback0
mpls ip
tunnel destination 10.0.0.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng fast-reroute
ip route 10.0.0.1 255.255.255.255 link-1
ip route 10.0.0.1 255.255.255.255 link-2
ip route 10.0.0.1 255.255.255.255 link-3Hello Sherif,
traffic of a single TE tunnel will not be load balanced over multiple physical links as the TE tunnel is setup using a reservation and the path will use only one link for each router hop.
So moving to two TE tunnels is not an option for you.
Hope to help
Giuseppe -
Fast-Reroute on a ring with Gig Interface
Hi,
I'm trying to setup a fast-reroute option on a 4 routers ring connected through gige with OSPF.
The main idea is to be able to use xconnect between A & B for normal route with a backup through C & D in case of Gig failure AB.
I created two tunnel as follow on A
interface Tunnel50
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination b.b.b.b
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 2 2
tunnel mpls traffic-eng path-option 1 explicit name b-fast
tunnel mpls traffic-eng fast-reroute node-protect
interface Tunnel51
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination b.b.b.
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 5 5
tunnel mpls traffic-eng path-option 10 explicit name b-low
and configure A to B interfaces with
mpls traffic-eng backup-path Tunnel51
ip rsvp bandwidth
router ospf
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
Same kind of conf on B side...
Well, if I shutdown A to B interface, the fast-reroute doesn't seems to operate and the xconnect resume on a ospf convergence base latency.
Should I also create tunnel A-C, A-D, B-C, B-D, ... like a full mesh ? or point to point on a ring AB, BC, CD, DA ?
Thanks for your help.
LaurentI tried a xconnect between br01 and br04.
Routers are on a ring : br01(ge3/2)--(ge3/1)br03--br02--br04(ge3/2)--(ge3/1)br01
tunnel50 is the straight route and tunnel 51 is the low route
*Here the output from br04
br04-7600-mtp02#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 2803 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 103 seconds
P2P TUNNELS/LSPs:
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
br04-7600-mtp02_t50 94.103.128.56 - Gi3/2 up/up
br04-7600-mtp02_t51 94.103.128.56 - Gi3/1 up/up
br01-7600-par01_t50 94.103.128.59 Gi3/2 - up/up
br01-7600-par01_t51 94.103.128.59 Gi3/1 - up/up
Displayed 2 (of 2) heads, 0 (of 0) midpoints, 2 (of 2) tails
P2MP TUNNELS:
Displayed 0 (of 0) P2MP heads
P2MP SUB-LSPS:
Displayed 0 P2MP sub-LSPs:
0 (of 0) heads, 0 (of 0) midpoints, 0 (of 0) tails
br04-7600-mtp02#show mpls traffic-eng fast-reroute database
P2P Headend FRR information:
Protected tunnel In-label Out intf/label FRR intf/label Status
Tunnel50 Tun hd Gi3/2:implicit-n Tu51:implicit-nu Ready
P2P LSP midpoint frr information:
LSP identifier In-label Out intf/label FRR intf/label Status
P2MP Sub-LSP FRR information:
*Sub-LSP identifier
src_lspid[subid]->dst_tunid In-label Out intf/label FRR intf/label Status
* Sub-LSP identifier format: _[SubgroupID]->_
Note: Sub-LSP identifier may be truncated.
Use 'detail' display for the complete key.
br04-7600-mtp02#show mpls traffic-eng tunnels backup
br04-7600-mtp02_t51
LSP Head, Admin: up, Oper: up
Tun ID: 51, LSP ID: 35, Source: 94.103.128.59
Destination: 94.103.128.56
Fast Reroute Backup Provided:
Protected i/fs: Gi3/2
Protected LSPs/Sub-LSPs: 1, Active: 0
Backup BW: any pool unlimited; inuse: 0 kbps
Backup flags: 0x0
*Here the output from br01
br01-7600-par01#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 2489 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 89 seconds
P2P TUNNELS/LSPs:
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
br01-7600-par01_t50 94.103.128.59 - Gi3/1 up/up
br01-7600-par01_t51 94.103.128.59 - Gi3/2 up/up
br04-7600-mtp02_t50 94.103.128.56 Gi3/1 - up/up
br04-7600-mtp02_t51 94.103.128.56 Gi3/2 - up/up
Displayed 2 (of 2) heads, 0 (of 0) midpoints, 2 (of 2) tails
P2MP TUNNELS:
Displayed 0 (of 0) P2MP heads
P2MP SUB-LSPS:
Displayed 0 P2MP sub-LSPs:
0 (of 0) heads, 0 (of 0) midpoints, 0 (of 0) tails
br01-7600-par01#show mpls traffic-eng fast-reroute database
P2P Headend FRR information:
Protected tunnel In-label Out intf/label FRR intf/label Status
Tunnel50 Tun hd Gi3/1:implicit-n Tu51:implicit-nu Ready
P2P LSP midpoint frr information:
LSP identifier In-label Out intf/label FRR intf/label Status
P2MP Sub-LSP FRR information:
*Sub-LSP identifier
src_lspid[subid]->dst_tunid In-label Out intf/label FRR intf/label Status
* Sub-LSP identifier format: _[SubgroupID]->_
Note: Sub-LSP identifier may be truncated.
Use 'detail' display for the complete key.
br01-7600-par01#show mpls traffic-eng tunnels backup
br01-7600-par01_t51
LSP Head, Admin: up, Oper: up
Tun ID: 51, LSP ID: 30, Source: 94.103.128.56
Destination: 94.103.128.59
Fast Reroute Backup Provided:
Protected i/fs: Gi3/1
Protected LSPs/Sub-LSPs: 1, Active: 0
Backup BW: any pool unlimited; inuse: 0 kbps
Backup flags: 0x0
Thx,
Laurent -
TE over ospf virtual-link does not work
Hi Expert,
I want to practise the TE over ospf virtual-link. The topo is like this one:
R1 R2
| |
R3---R4
| |
R5 R6
all links are in area 0 except link between R3 and R4.
rt5_1#ro
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
interface Tunnel16
ip unnumbered Loopback0
tunnel destination 6.6.6.6
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 5 5
tunnel mpls traffic-eng bandwidth 5
tunnel mpls traffic-eng path-option 10 dynamic
rt5_2#ro
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
rt5_3#ro
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
area 1 virtual-link 4.4.4.4
network 3.3.3.3 0.0.0.0 area 0
network 10.10.13.0 0.0.0.255 area 0
network 10.10.34.0 0.0.0.255 area 1
network 10.10.35.0 0.0.0.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
mpls traffic-eng interface
Ethernet1/0/1 area 0
rt5_4#ro
router ospf 1
router-id 4.4.4.4
log-adjacency-changes
area 1 virtual-link 3.3.3.3
network 4.4.4.4 0.0.0.0 area 0
network 10.10.24.0 0.0.0.255 area 0
network 10.10.34.0 0.0.0.255 area 1
network 10.10.46.0 0.0.0.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
mpls traffic-eng interface Ethernet1/1 area 0
rt5_5#ro
router ospf 1
router-id 5.5.5.5
log-adjacency-changes
network 5.5.5.5 0.0.0.0 area 0
network 10.10.35.0 0.0.0.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
rt5_7#ro
router ospf 1
router-id 6.6.6.6
log-adjacency-changes
network 6.6.6.6 0.0.0.0 area 0
network 10.10.46.0 0.0.0.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
The tunnel 16 on R1 from R6 does not come up .
rt5_1#sh mpls traffic-eng tunnels t16
Name: rt5_1_t16 (Tunnel16) Destination: 6.6.6.6
Status:
Admin: up Oper: down Path: not valid Signalling: Down
path option 10, type dynamic
Config Parameters:
Bandwidth: 5 kbps (Global) Priority: 5 5 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 5 bw-based
auto-bw: disabled
Shortest Unconstrained Path Info:
Path Weight: UNKNOWN
Explicit Route: UNKNOWN
History:
Tunnel:
Time since created: 1 hours, 7 minutes
Path Option 10:
Last Error: PCALC:: No path to destination, 6.6.6.6
Does anyone the cause of the problem?
thanks,Hi,
There is one virutal link between R3 and R4.
rt5_1#sh mpls traffic-eng topology
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node (ospf 1 area 0)
link[0]: Broadcast, DR: 10.10.35.5, nbr_node_id:24, gen:224
frag_id 1, Intf Address:10.10.35.3
TE metric:10, IGP metric:10, attribute flags:0x0
link[1]: Broadcast, DR: 10.10.13.1, nbr_node_id:25, gen:224
frag_id 0, Intf Address:10.10.13.3
TE metric:10, IGP metric:10, attribute flags:0x0
link[2]: Broadcast, DR: 10.10.34.3, nbr_node_id:-1, gen:224
frag_id 3, Intf Address:10.10.34.3
TE metric:10, IGP metric:invalid, attribute flags:0x0
sh mpls traffic-eng topology brief
IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3 Router Node (ospf 1 area 0)
link[0]: Broadcast, DR: 10.10.35.5, nbr_node_id:31, gen:106
frag_id 1, Intf Address:10.10.35.3
TE metric:10, IGP metric:10, attribute flags:0x0
link[1]: Broadcast, DR: 10.10.13.1, nbr_node_id:32, gen:106
frag_id 0, Intf Address:10.10.13.3
TE metric:10, IGP metric:10, attribute flags:0x0
link[2]: Broadcast, DR: 10.10.34.3, nbr_node_id:-1, gen:106
frag_id 3, Intf Address:10.10.34.3
TE metric:10, IGP metric:invalid, attribute flags:0x0
IGP Id: 4.4.4.4, MPLS TE Id:4.4.4.4 Router Node (ospf 1 area 0)
link[0]: Broadcast, DR: 10.10.46.6, nbr_node_id:34, gen:104
frag_id 0, Intf Address:10.10.46.4
TE metric:10, IGP metric:invalid, attribute flags:0x0
link[1]: Broadcast, DR: 10.10.24.2, nbr_node_id:19, gen:104
frag_id 1, Intf Address:10.10.24.4
TE metric:10, IGP metric:10, attribute flags:0x0
link[2]: Broadcast, DR: 10.10.34.3, nbr_node_id:-1, gen:104
frag_id 2, Intf Address:10.10.34.4
TE metric:10, IGP metric:invalid, attribute flags:0x0
IGP Id: 5.5.5.5, MPLS TE Id:5.5.5.5 Router Node (ospf 1 area 0)
link[0]: Broadcast, DR: 10.10.35.5, nbr_node_id:31, gen:94
thanks,
guoming
Maybe you are looking for
-
Timeline behavior when inserting a clip
I've got a timeline built, but it's sort of a draft. I'll replace some clips with others, delete some, insert some. Problem is, when I'm inserting a new clip, it would make my life so much easier if the rest of the clips in the timeline would move ou
-
Will Air-print be available for other types of wireless printers soon? Why Is Air-Print only for HP Printers? Is It a deal Apple have with HP or Is the software used just not able to work with other printers?
-
Same artist is shown multiple times
In iTunes, I downloaded a song not through the iTunes store, then added the .mp3 file to iTunes. When I enter in the artist information for sorting, it lists that artist separate from the same artist I've added in the past. I am 100% positive that th
-
I cannot download updates re photoshop and illustrator error message unable to extract files
I am still new to all of this I cannot download updates re photoshop and illustrator an error message comes up saying that I am unable to extract files I do have an open case number re this query but am rarely free during office hours to sort thank
-
Is there a straightforward way to install a 10.8.5 recovery partition on an external firewire drive?
Ideally one that is not hardware specific?