05-19-2013 07:56 AM - edited 03-07-2019 01:26 PM
I recently migrated from a Cat6k Sup720 running s72033-advipservicesk9_wan-mz.122-33.SXI3.bin to a Sup2T running s2t54-adventerprisek9-mz.SPA.150-1.SY1.bin. The config is basically the same, but on the new Sup2T I'm getting 7 Tunnel interfaces which are being created automatically, so to speak I guess. They aren't in the config. See below snippet from the show ip int brief output.
Tunnel0 10.30.2.98 YES unset up up
Tunnel1 10.30.2.98 YES unset up up
Tunnel2 10.30.2.98 YES unset up up
Tunnel3 10.30.2.98 YES unset up up
Tunnel4 10.30.2.98 YES unset up up
Tunnel5 10.30.2.98 YES unset up up
Tunnel6 10.30.2.98 YES unset up up
The address they all use is the Gig port that is the link to the WAN router (routed OSPF), below.
interface GigabitEthernet2/1
description WAN edge
ip address 10.30.2.98 255.255.255.248
no ip redirects
no ip proxy-arp
ip flow monitor Netflow-Monitor-1 input
ip pim query-interval 1
ip pim sparse-mode
ip ospf network point-to-point
ip ospf hello-interval 1
flowcontrol receive desired
Is anyone aware of what process or feature might be creating these interfaces? They don't appear to affect performance or functionality, but I am curious why they are there and where they came from since this behavior isn't seen on the old Sup720. Thanks.
Michael
Solved! Go to Solution.
05-19-2013 08:53 AM
Hi Michael,
I believe these tunnels are related to the PIM Sparse Mode operation and they probably represent a PIM-Register tunnel used during the multicast source registration process. I have no firm proof of that but I have also seen these tunnels being created on the fly on software ISR router platforms on recent IOSes when PIM-SM was run.
Would it actually be possible to elicit any output from show run int tun0 up to show run int tun6 (yes, I know they are not in the config but sometimes this command works for dynamically configured interfaces, too)? Or at least show interface tun0 and show ip interface tun0?
Best regards,
Peter
05-19-2013 09:28 AM
Hi Michael,
Peter is absolutely correct. These tunnels are created automatically by the Multicast Forwarding Information Base (MFIB) as part of the PIM sparse-mode registration process.
From the IPv4 Multicast Layer 3 Features section of the Catalyst 6500 Software Configuration Guide:
The PIM-SM protocol requires the first-hop router for a multicast source to send a register packet to the Rendezvous Point (RP) when the source starts sending packets. On the Supervisor Engine 2T, the PIM control-plane uses the MFIB infrastructure to represent the PIM register tunnel as an interfaceand adds it to the outgoing interface list when PIM register packets are sent. When a new PIM RP is configured or learned, a PIM register tunnel interface is created and used for PIM register packets. The interface is deleted when a register-stop packet is received. On the RP, an additional interface is created and used to decapsulate the PIM register packet when it is received.
You can see the tunnels created and the groups associated with those tunnels using the show ip pim tunnel command.
Regards
05-19-2013 08:53 AM
Hi Michael,
I believe these tunnels are related to the PIM Sparse Mode operation and they probably represent a PIM-Register tunnel used during the multicast source registration process. I have no firm proof of that but I have also seen these tunnels being created on the fly on software ISR router platforms on recent IOSes when PIM-SM was run.
Would it actually be possible to elicit any output from show run int tun0 up to show run int tun6 (yes, I know they are not in the config but sometimes this command works for dynamically configured interfaces, too)? Or at least show interface tun0 and show ip interface tun0?
Best regards,
Peter
05-19-2013 09:28 AM
Hi Michael,
Peter is absolutely correct. These tunnels are created automatically by the Multicast Forwarding Information Base (MFIB) as part of the PIM sparse-mode registration process.
From the IPv4 Multicast Layer 3 Features section of the Catalyst 6500 Software Configuration Guide:
The PIM-SM protocol requires the first-hop router for a multicast source to send a register packet to the Rendezvous Point (RP) when the source starts sending packets. On the Supervisor Engine 2T, the PIM control-plane uses the MFIB infrastructure to represent the PIM register tunnel as an interfaceand adds it to the outgoing interface list when PIM register packets are sent. When a new PIM RP is configured or learned, a PIM register tunnel interface is created and used for PIM register packets. The interface is deleted when a register-stop packet is received. On the RP, an additional interface is created and used to decapsulate the PIM register packet when it is received.
You can see the tunnels created and the groups associated with those tunnels using the show ip pim tunnel command.
Regards
05-20-2013 08:12 AM
Thanks to both of you.
Yes, the show ip pim tunnel output does show the PIM-related tunnels:
#sh ip pim tunnel
Tunnel0
Type : PIM Encap
RP : 10.28.254.253
Source: 10.30.2.98
Tunnel1
Type : PIM Encap
RP : 10.28.254.254
Source: 10.30.2.98
The show run int tun0 command only produces:
#sh run int tun0
Building configuration...
Current configuration : 5 bytes
end
However, the show int does indeed show some valid output though:
#sh int tun0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Interface is unnumbered. Using address of GigabitEthernet2/1 (10.30.2.98)
MTU 17864 bytes, BW 100 Kbit, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.30.2.98 (GigabitEthernet2/1), destination 10.28.254.253
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with GigabitEthernet2/1
Set of tunnels with source GigabitEthernet2/1, 7 members (includes iterators), on interface
Tunnel protocol/transport PIM/IPv4
Tunnel TOS/Traffic Class 0xC0, Tunnel TTL 255
Tunnel transport MTU 1472 bytes
Tunnel is transmit only
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Good to know!
Michael
07-11-2019 10:58 AM
You can use the "show derived-config interface tunnel #" to get the interface derived configuration:
Router#show derived-config interface tunnel 1
Building configuration...
Derived configuration : 199 bytes
!
interface Tunnel1
description Pim Register Tunnel (Encap) for RP x.x.x.x
ip unnumbered Vlanxxx
tunnel source Vlanxxx
tunnel destination x.x.x.x
tunnel tos 192
no routing dynamic
end
Best regards.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide