Re: Catalyst 4500 listening on TCP 6154 on all interfaces
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.jut...@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 StartsWakeupsNext > Retrans 0 0 0x0 > TimeWait0 0 0x0 > AckHold 0 0 0x0 > SendWnd 0 0 0x0 > KeepAlive 0 0 0x0 > GiveUp 0 0 0x0 > PmtuAger0 0 0x0 > DeadWait0 0 0x0 > Linger 0 0 0x0 > ProcessQ0 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: 6 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 >
Re: How are you configuring BFD timers?
On 21/Mar/18 19:10, Jason Lixfeld wrote: > A few years ago I did some testing and found that the time between the > transceiver detecting LOS and the routing protocol (ISIS in this case) being > informed that the link was down (triggering the recalculation) took longer > than it took BFD to signal ISIS to recalculate. You also have the issues of: * Deciding whether you want to have a uniform standard when deploying BFD. If your standard is not to on dark links and should do lit links, you can quickly run into an administrative scenario as your network grows, and keeping track of which link is what re: BFD or not can be someone's untangling project 10 years later. * Circuit providers delivering hybrid links and not telling you because they are either afraid to or don't fully understand the scope of their (very large) network. In this case, you're told the link is dark, but somewhere along the path is their active gear. (not so) Strange, but true. Mark.
Re: How are you configuring BFD timers?
On 22/Mar/18 10:47, James Bensley wrote: > Have you looked at testing and adding this command to your IOS devices: > > ip routing protocol purge interface In all recent versions of IOS, this command is now standard and is elided from the running configuration. Mark.
Re: NSR / NSF
On 17/Mar/18 12:29, Hari . wrote: > Checking on best practice being followed with regards to enabling NSF or NSR > or both on ASR 9k. Which option can be beneficial and considered to be a > standard approach. See https://mailman.nanog.org/pipermail/nanog/2014-November/071600.html from 2014. In 2018, the only routers we have that don't support NSR are not carrying essential production traffic, e.g., looking glass routers based on the Cisco 7201. GR would be useful here, but no mileage for us since all other devices have the hardware to do NSR. We do run our RR's on CSR1000v, which would put them into the GR category, but redundancy here is caused by discrete hardware duplication. Mark.
Re: Route Reflector Client Design Question
On 4/May/18 08:01, Erik Sundberg wrote: > My questions is how do I get traffic to go directly between the PE's without > going to the Core Routers? > > 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between > the PE's without going to the core's. Or does this break the Route Reflector > model? You could do, but then you lose the point of the RR in the first place, as it's likely your Metro-E nodes will continue to grow, making this iBGP mesh thing, well, messy. > 2. Create a route policy on the Core's advertising routes learned from the > PE's back to all the PE's on the ring. You could do, but adds unnecessary routing complexity since the role of an RR is to, well, reflect. > 3. Is this one of the down sides to U Rings? Not really a downside, just the perks of extending IP/MPLS all the way into the Access (I drink to the death of Layer 2 Metro-E networks - my liver will probably give out before I do, though...). > 4. Leave it alone and move on to bigger and better things Now where's the fun in that :-)? So we've solved this problem by using BGP-SD (Selective Download): * For every prefix each Metro-E node handles, originate that toward both RR's with NEXT_HOP=self. * Attach a BGP community along with the routes originated toward the RR's. For maximum saving of your precious FIB in your Metro-E nodes, use a BGP community that is unique to the ring. This way, you don't need to accept routes into each Metro-E's FIB that don't require the "local" forwarding. * Ensure the RR's reflect the routes they learn from each Metro-E node to the other Metro-E nodes. * Setup BGP-SD on each Metro-E node. Match the ring-specific BGP community you added to each Metro-E node's prefix origination. Accept those routes into FIB + default. Reject everything else (from populating the FIB). That should give you local forwarding within the ring, while maintaining very sparse population of your Metro-E nodes' FIB's. Mark.
RE: Route Reflector Client Design Question
Mark, Your solutions sounds like the best one. We have just started to mess with Selective download and we have only turned it on for one of the PE’s in our network. I am in the process of upgrading our Core routers from Cisco12410 to ASR9906’s, before I turn this one. Having the PE decide what to import is a better solution than trying to do router filtering on the core routers. Thanks for the info Erik From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Saturday, May 5, 2018 6:38 PM To: Erik Sundberg ; NANOG Subject: Re: Route Reflector Client Design Question On 4/May/18 08:01, Erik Sundberg wrote: My questions is how do I get traffic to go directly between the PE's without going to the Core Routers? 1. Can I enable iBGP between the PE's in a full mesh to allow traffic between the PE's without going to the core's. Or does this break the Route Reflector model? You could do, but then you lose the point of the RR in the first place, as it's likely your Metro-E nodes will continue to grow, making this iBGP mesh thing, well, messy. 2. Create a route policy on the Core's advertising routes learned from the PE's back to all the PE's on the ring. You could do, but adds unnecessary routing complexity since the role of an RR is to, well, reflect. 3. Is this one of the down sides to U Rings? Not really a downside, just the perks of extending IP/MPLS all the way into the Access (I drink to the death of Layer 2 Metro-E networks - my liver will probably give out before I do, though...). 4. Leave it alone and move on to bigger and better things Now where's the fun in that :-)? So we've solved this problem by using BGP-SD (Selective Download): * For every prefix each Metro-E node handles, originate that toward both RR's with NEXT_HOP=self. * Attach a BGP community along with the routes originated toward the RR's. For maximum saving of your precious FIB in your Metro-E nodes, use a BGP community that is unique to the ring. This way, you don't need to accept routes into each Metro-E's FIB that don't require the "local" forwarding. * Ensure the RR's reflect the routes they learn from each Metro-E node to the other Metro-E nodes. * Setup BGP-SD on each Metro-E node. Match the ring-specific BGP community you added to each Metro-E node's prefix origination. Accept those routes into FIB + default. Reject everything else (from populating the FIB). That should give you local forwarding within the ring, while maintaining very sparse population of your Metro-E nodes' FIB's. Mark. CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
RE: How are you configuring BFD timers?
Here is what we do... router isis interface TenGigabitEthernet0/0/0/0 circuit-type level-2-only bfd minimum-interval 50 bfd multiplier 5 bfd fast-detect ipv4 We keep the same config for local and long haul core links. Works like a champ every time. Also as a FYI if you are running ASR9K, you are able to offload the BFD process from the Linecard CPU to the NPU. This allows BFD timers down to 3.3 milliseconds. https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-1/routing/configuration/guide/b_routing_cg51xasr9k/b_routing_cg51xasr9k_chapter_011.html -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Tinka Sent: Saturday, May 5, 2018 6:38 PM To: James Bensley ; NANOG Subject: Re: How are you configuring BFD timers? On 22/Mar/18 10:47, James Bensley wrote: > Have you looked at testing and adding this command to your IOS devices: > > ip routing protocol purge interface In all recent versions of IOS, this command is now standard and is elided from the running configuration. Mark. CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
