Catalyst 4500 listening on TCP 6154 on all interfaces

frederic.jutzet at sig-telecom.net frederic.jutzet at sig-telecom.net
Mon May 7 15:45:14 UTC 2018


I've been told that the TAC center will not take the time to answer as
it's not a 'real' problem, service affecting issue.
And the Cisco community forum on that topic was useless (nobody answer
to a person which already open a topic about this issue 10 months ago).
But you are the 4rd person to tell me to open a TAC, I could have tried
first.
In the meantime Cisco contact me off-list, so I will try with them.




On 07.05.2018 16:59, Jay Farrell via NANOG wrote:
> Just a wild thought – why not open a TAC case with Cisco and ask them?
>
> On Mon, May 7, 2018 at 3:06 AM, frederic.jutzet at sig-telecom.net <
> frederic.jutzet at sig-telecom.net> wrote:
>
>>> - a nsa backdoor :-)
>> it would be a very bad backdoor as it's really easy to see the port
>> listening...
>>
>>
>>> - a default active service
>> Maybe, but a service which is not officially registered:
>> https://www.iana.org/assignments/service-names-port-numbers/service-names-
>> port-numbers.xhtml?search=6154
>>
>> in contrary to the SMI (zero touch feature on tcp 4786) which is
>> registered since almost 10y:
>> https://www.iana.org/assignments/service-names-port-numbers/service-names-
>> port-numbers.xhtml?search=4786
>>
>>
>>
>> Could it be possible that this kind of tcp port is not registered by
>> Iana because it meant to be used for internal communication only
>> (internal to the device), or should you register any port usage (even
>> 'private') ?
>>
>>
>> And yes I've tried to reset to default the config, shutdown all
>> interface, remove all L3 ip/feature (no ip blabla), and I still see by
>> default 2 TCP ports on listening state:
>>
>> Cat4500-SUP7L-E#sh ip prot
>> *** IP Routing is NSF aware ***
>>
>> Cat4500-SUP7L-E#
>> Cat4500-SUP7L-E#sh run | in ip
>>  address-family ipv4
>>  address-family ipv6
>> no ip routing
>> ip vrf Liin-vrf
>> no ip mfib
>> no ip bootp server
>> no ip dhcp-client broadcast-flag
>> no ip igmp snooping
>> no ipv6 traffic interface-statistics
>>  no ip address
>>  no ip route-cache
>>  no ip address
>>  no ip route-cache
>> no ip forward-protocol nd
>> no ip http server
>> no ip http secure-server
>> Cat4500-SUP7L-E#
>> Cat4500-SUP7L-E#
>> Cat4500-SUP7L-E#show tcp br all
>> TCB       Local Address               Foreign Address             (state)
>> 5B40BB30  0.0.0.0.4786               *.*                         LISTEN
>> 5CD5D2D8  0.0.0.0.6154               *.*                         LISTEN
>> Cat4500-SUP7L-E#
>>
>>
>>
>> I will now try to negate all potential active service from the 'show run
>> all' config but it's not optimal as for example 'vstack' (port 4786)
>> does not appear in the default config so it would not be disable by this
>> trivial method.
>>
>>
>> Fred
>>
>>
>> On 05.05.2018 13:22, marcel.duregards at yahoo.fr wrote:
>>> As the zero touch feature is on TCP 4786 (SMI), I vote for either:
>>>
>>> - a nsa backdoor :-)
>>> - a default active service
>>>
>>> Have you tried to zeroize the config and restart then check if TCP 6154
>>> is still on LISTEN state ?
>>>
>>>
>>> -
>>> Marcel
>>>
>>>
>>>
>>> On 03.05.2018 06:51, frederic.jutzet at sig-telecom.net wrote:
>>>> Hi,
>>>>
>>>> We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2
>>>> which have TCP port 6154 listening on all interfaces.
>>>>
>>>> Any idea what it could be ?
>>>>
>>>> #show tcp brief all
>>>> TCB       Local Address               Foreign Address
>>  (state)
>>>> ...
>>>> 5A529430  0.0.0.0.6154        <<<<<<<<<<<<<<<<
>>>>
>>>>
>>>> #show tcp tcb 5A529430
>>>> Connection state is LISTEN, I/O status: 1, unread input bytes: 0
>>>> Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
>>>> Local host: 0.0.0.0, Local port: 6154
>>>> Foreign host: UNKNOWN, Foreign port: 0
>>>> Connection tableid (VRF): 1
>>>> Maximum output segment queue size: 50
>>>>
>>>> Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)
>>>>
>>>> Event Timers (current time is 0xF58354):
>>>> Timer          Starts    Wakeups            Next
>>>> Retrans             0          0             0x0
>>>> TimeWait            0          0             0x0
>>>> AckHold             0          0             0x0
>>>> SendWnd             0          0             0x0
>>>> KeepAlive           0          0             0x0
>>>> GiveUp              0          0             0x0
>>>> PmtuAger            0          0             0x0
>>>> DeadWait            0          0             0x0
>>>> Linger              0          0             0x0
>>>> ProcessQ            0          0             0x0
>>>>
>>>> iss:          0  snduna:          0  sndnxt:          0
>>>> irs:          0  rcvnxt:          0
>>>>
>>>> sndwnd:      0  scale:      0  maxrcvwnd:   4128
>>>> rcvwnd:   4128  scale:      0  delrcvwnd:      0
>>>>
>>>> SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms
>>>> minRTT: 60000 ms, maxRTT: 0 ms, ACK hold: 200 ms
>>>> uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms
>>>> Status Flags: gen tcbs
>>>> Option Flags: VRF id set, keepalive running, nagle, Reuse local address
>>>>   Retrans timeout
>>>> IP Precedence value : 0
>>>>
>>>> Datagrams (max data segment is 516 bytes):
>>>> Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0
>>>> Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second
>>>> Congestion: 0), with data: 0, total data bytes: 0
>>>>
>>>>  Packets received in fast path: 0, fast processed: 0, slow path: 0
>>>>  fast lock acquisition failures: 0, slow path: 0
>>>> TCP Semaphore      0x5BEB9B10  FREE
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> (The command "show control-plane host open-ports" is not available on
>>>> this platform/code)
>>>>
>>>>
>>>>
>>>> I also think that if it would be a local socket for internal process
>>>> communication, it would be 127.0.0.1:6154 instead of 0.0.0.0:6154.
>>>> So this is listening on all interfaces, virtuals and physicals and seam
>>>> not to be for internal internal process communication.
>>>>
>>>>
>>>> Fred
>>>>





More information about the NANOG mailing list