[c-nsp] Strange new PIM Tunnel interfaces after upgrade to 12.2(33)SRC
Jared Mauch
jared at puck.nether.net
Wed Jan 5 16:50:18 EST 2011
IIRC, these are used for pim registers and other messages.
You see the same thing in IOS-XE on the ASR1000
Router(config)#int t0
%Tunnel0 used by PIM for Registering, configuration not allowed
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Interface is unnumbered. Using address of GigabitEthernet0/0/1 (x.y.4.130)
MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source x.y.4.130 (GigabitEthernet0/0/1), destination 129.250.0.241
129.250.0.241 is our configured RP/auto-rp for customers doing pim/mcast that do not speak MSDP.
- Jared
On Jan 5, 2011, at 4:35 PM, John Neiberger wrote:
> We recently upgraded several 7600s from 12.2(18) to 12.2(33)SRC. After
> the upgrade, we noticed several new tunnel interfaces. According to
> the output of "show int tunnel1", as an example, this is a
> transmit-only PIM tunnel between that router and a 4948 in another
> data center. We have absolutely no idea what these tunnel interfaces
> are being used for or how (or why!) they're dynamically created.
>
> Do any of you have any idea what these are?
>
> Tunnel1 is up, line protocol is up
> Hardware is Tunnel
> Interface is unnumbered. Using address of TenGigabitEthernet4/4 (10.1.1.2)
> MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,
> reliability 255/255, txload 1/255, rxload 1/255
> Encapsulation TUNNEL, loopback not set
> Keepalive not set
> Tunnel source 10.1.1.2 (TenGigabitEthernet4/4), destination 10.3.4.1
> Tunnel Subblocks:
> src-track:
> Tunnel1 source tracking subblock associated with TenGigabitEthernet4/4
> Set of tunnels with source TenGigabitEthernet4/4, 4 members
> (includes iterators), on interface <OK>
> 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 3w0d
> Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
> Queueing strategy: fifo
> Output queue: 0/0 (size/max)
> 5 minute input rate 0 bits/sec, 0 packets/sec
> 5 minute output rate 0 bits/sec, 0 packets/sec
> L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
> L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
> L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
> 0 packets input, 0 bytes, 0 no buffer
> Received 0 broadcasts (0 IP multicasts)
> 0 runts, 0 giants, 0 throttles
> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
> 0 packets output, 0 bytes, 0 underruns
> 0 output errors, 0 collisions, 0 interface resets
> 0 unknown protocol drops
> 0 output buffer failures, 0 output buffers swapped out
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list