Re: [c-nsp] Loopback IP set to .255 - 6500 responds to ICMP echo-request from wrong interface

[Eric Rosenberry]

inline...

On Sat, Dec 31, 2011 at 9:57 PM, Jay Hennigan  wrote:
>
>
> If the mask of 216.x.x is /24 or longer, then .255 will be a broadcast
> address and the ping response will be from one or more host addresses on
> the subnet.
>
> If the second x of 216.x.x is odd, then the same issue will pertain to
> shorter masks, binary math will tell you which.
>

But in this case these single IP's are bound to the loopback interface on
the router with a /32 (255.255.255.255) subnet mask...  The router should
know that it's the only IP on the netblock and not treat it is a normal
subnet with a broadcast address...

Under that logic, the .254 IP on the other router is also the broadcast
address since it is in a /32 subnet as well...


-- 
*Eric Rosenberry*
Sr. Infrastructure Architect // Chief Bit Plumber

Direct: 503.943.6763
Mobile: 503.348.3625 // XMPP: eric.rosenbe...@iovation.com
*www.iovation.com* 
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Loopback IP set to .255 - 6500 responds to ICMP echo-request from wrong interface

[Jay Hennigan]

On 12/31/11 9:33 PM, Eric Rosenberry wrote:
> I am scratching my head here wondering if I have run into a Cisco bug, or
> somehow intended weird behavior...
> 
> I set the loopback IP's for a pair of 6500's (Sup720-3CXL's) to adjacent
> IP's and have *identical* config's on them (sans their interface and
> loopback IP's).
> 
> One of them is 216.x.x.254 and the other is 216.x.x.255.

If the mask of 216.x.x is /24 or longer, then .255 will be a broadcast
address and the ping response will be from one or more host addresses on
the subnet.

If the second x of 216.x.x is odd, then the same issue will pertain to
shorter masks, binary math will tell you which.

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Loopback IP set to .255 - 6500 responds to ICMP echo-request from wrong interface

[Eric Rosenberry]

I am scratching my head here wondering if I have run into a Cisco bug, or
somehow intended weird behavior...

I set the loopback IP's for a pair of 6500's (Sup720-3CXL's) to adjacent
IP's and have *identical* config's on them (sans their interface and
loopback IP's).

One of them is 216.x.x.254 and the other is 216.x.x.255.

When pinging the loopback IP's of these devices from the Internet, one
responds as expected (from the IP of the loopback), and the other (.255)
responds from a *different* IP address (one of it's interface IP's rather
than the loopback IP).

I am guessing there is some different code path being exercised here
because .255 is normally the broadcast address in classful networking?
 Somehow the router trying to avoid "directed broadcast" or something?

I am running code rev: 12.2(33)SXI3

ip classless is enabled.

Any thoughts?

P.S.  Changing the router that is .255 to .253 makes it work as expected.
 I am probably just going to make 216.x.x.252/30 into a routing subnet and
move the routers back to .250 and .251...

-Eric

-- 
*Eric Rosenberry*
Sr. Infrastructure Architect // Chief Bit Plumber

Direct: 503.943.6763
Mobile: 503.348.3625 // XMPP: eric.rosenbe...@iovation.com
*www.iovation.com* 
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Cisco 7609-S - RSP SUP 720 3CXL - show ibc - high packets

[Josh Coleman]

Hi, I have two identical Cisco 7609-S / RSP 720 3CXL with the same code
version. The network configs are pretty much identical with one having a
few more interfaces. But when viewing the show ibc and reviewing the
counters the both of them have different results.

The cpu on core01 was way higher before typing the command clear cef
linecard. But the packet rate overtime keeps coming back up per sec as you
can see it shows rx rate 4757 and 9479 tx rate. Both of these routers have
BGP /OSPF / HSRP. The Core02 is the root bridge for all vlans. The code
version on both of the routers is
c7600rsp72043-advipservicesk9-mz.151-3.S1.bin.

I already used the debug NETDR and the packets are hitting the cpu but its
a variety from all the customers with different source / destinations.
There is already the mls rate limits and I have done the show
spanning-tree for unstable incase of layer2 loops.

mls rate-limit unicast cef receive 1 60
mls rate-limit unicast cef glean 2 60
mls rate-limit unicast ip rpf-failure 100 20
mls rate-limit unicast ip icmp redirect 100 20
mls rate-limit unicast ip icmp unreachable no-route 100 20
mls rate-limit unicast ip icmp unreachable acl-drop 100 20
mls rate-limit unicast ip errors 100 20
mls rate-limit all ttl-failure 50 10
mls rate-limit all mtu-failure 2000 10

core01#show ibc
Interface information:
Interface IBC0/0(idb 0x1D168E1C)
5 minute rx rate 32355000 bits/sec, 4757 packets/sec
5 minute tx rate 66046000 bits/sec, 9479 packets/sec
8378874987 packets input, 3566593581795 bytes
27602422 broadcasts received
8369906047 packets output, 3580275916961 bytes
5240 broadcasts sent
0 Bridge Packet loopback drops
8341070641 Packets CEF Switched, 6339 Packets Fast Switched
0 Packets SLB Switched, 0 Packets CWAN Switched
Label switched pkts dropped: 0Pkts dropped during dma: 2240
Invalid pkts dropped: 0Pkts dropped(not cwan consumed): 0
Pkts marked to drop by VLAN clients: 0
IPSEC pkts: 11637893
Xconnect pkts processed: 0, dropped: 0
Xconnect pkt reflection drops: 0
Total paks copied for process level 0
Total short paks sent in route cache 1437634096
Total throttle drops 2059Input queue drops 2373
total spd packets classified (29755971 low, 4041688 medium,
3902236 high)
total spd packets dropped (2070 low, 167 medium, 3 high)
spd prio pkts allowed in due to selective throttling (0 med, 0 high)
IBC resets   = 1; last at 09:02:16.943 UTC Wed Feb 2 2000



core02#show ibc
Interface information:
Interface IBC0/0(idb 0x1D168E1C)
5 minute rx rate 23000 bits/sec, 36 packets/sec
5 minute tx rate 3 bits/sec, 29 packets/sec
38909365 packets input, 3544558859 bytes
25109764 broadcasts received
15914616 packets output, 1867678797 bytes
1772317 broadcasts sent
0 Bridge Packet loopback drops
4775931 Packets CEF Switched, 6350 Packets Fast Switched
0 Packets SLB Switched, 0 Packets CWAN Switched
Label switched pkts dropped: 0Pkts dropped during dma: 2515
Invalid pkts dropped: 0Pkts dropped(not cwan consumed): 0
Pkts marked to drop by VLAN clients: 0
IPSEC pkts: 98
Xconnect pkts processed: 0, dropped: 0
Xconnect pkt reflection drops: 0
Total paks copied for process level 0
Total short paks sent in route cache 1274
Total throttle drops 1659Input queue drops 131
total spd packets classified (25137538 low, 5584530 medium,
3405016 high)
total spd packets dropped (2495 low, 12 medium, 8 high)
spd prio pkts allowed in due to selective throttling (0 med, 0 high)
IBC resets   = 1; last at 22:05:03.059 UTC Thu Nov 3 2011


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Interpreting DOM outputs

[John Brown]

Hi Rob,

I would also take real power meter readings from each transmitter, at the
source.
Compare that to what the DOM is saying to see how well calibrated your DOM
is.

Also, if you know the TX at the far side and now the RX at the near side
you can approx your loss across the link.

Recently I did a circuit turn up at a west coast carrier/colo and had 9dBm
of loss between the 17th floor and the 3rd floor.
WAY OUTSIDE of what it should have been.  After video scoping (never use a
mechanical scope) the connectors, we found lots of dirty connectors.
Despite people "cleaning them".

As we push more data, more waves, etc down these thin strands of glass it
will be critically important to have the right optical test get to QUICKLY
troubleshoot issues.

We graph our DOM data.

On 12/31/11 11:18 AM, "John Gill"  wrote:

>Hi Rob,
>-4.9 dBm is indeed stronger than -6.9dBm.
>For example:
>-4.9 dBm is  .32mW
>-6.9 dBm is  .20mW
>
>These are negative values since 0dBm is the reference point of 1mW and
>you are looking at values below this.
>
>A greater value indicates higher power.  So, you can say this is usually
>better, except in the extreme cases where you are flooding the receive
>path with too much light, maybe connecting different transceivers over
>short distances for example (LX and SX over 1m).
>
>Anton made a good point - there can be some variance in these
>measurements from component to component so don't use them as absolute
>fact, but rather look at the data over time which can indicate a fiber
>or even a transceiver problem.
>
>
>Regards,
>John Gill
>cisco
>
>On 12/31/11 12:10 PM, Robert Hass wrote:
>> On Sat, Dec 31, 2011 at 6:02 PM, Anton Kapela  wrote:
>>> That is, these measurements are best-used as a referential figure, not
>>> absolute -- meaning you ought to start polling&  storing them now for
>>> the most utility to be found in troubleshooting later. ;)
>>
>> Thanks for explanation.
>> But I'm still unsure regarding my questions of understanding:
>>
>> Tx Power '-4.9' better/stronger than '-6.9'
>> Rx Power '-9.6' is better/stronger than '-11.2'
>>
>> My above understanding is correct or incorrect ?
>>
>> Thanks,
>> Rob
>> ___
>> cisco-nsp mailing list  cisco-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>___
>cisco-nsp mailing list  cisco-nsp@puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Interpreting DOM outputs

[John Gill]

Hi Rob,
-4.9 dBm is indeed stronger than -6.9dBm.
For example:
-4.9 dBm is  .32mW
-6.9 dBm is  .20mW

These are negative values since 0dBm is the reference point of 1mW and 
you are looking at values below this.


A greater value indicates higher power.  So, you can say this is usually 
better, except in the extreme cases where you are flooding the receive 
path with too much light, maybe connecting different transceivers over 
short distances for example (LX and SX over 1m).


Anton made a good point - there can be some variance in these 
measurements from component to component so don't use them as absolute 
fact, but rather look at the data over time which can indicate a fiber 
or even a transceiver problem.



Regards,
John Gill
cisco

On 12/31/11 12:10 PM, Robert Hass wrote:

On Sat, Dec 31, 2011 at 6:02 PM, Anton Kapela  wrote:

That is, these measurements are best-used as a referential figure, not
absolute -- meaning you ought to start polling&  storing them now for
the most utility to be found in troubleshooting later. ;)


Thanks for explanation.
But I'm still unsure regarding my questions of understanding:

Tx Power '-4.9' better/stronger than '-6.9'
Rx Power '-9.6' is better/stronger than '-11.2'

My above understanding is correct or incorrect ?

Thanks,
Rob
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Interpreting DOM outputs

[Robert Hass]

On Sat, Dec 31, 2011 at 6:02 PM, Anton Kapela  wrote:
> That is, these measurements are best-used as a referential figure, not
> absolute -- meaning you ought to start polling & storing them now for
> the most utility to be found in troubleshooting later. ;)

Thanks for explanation.
But I'm still unsure regarding my questions of understanding:

Tx Power '-4.9' better/stronger than '-6.9'
Rx Power '-9.6' is better/stronger than '-11.2'

My above understanding is correct or incorrect ?

Thanks,
Rob
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] Interpreting DOM outputs

[Anton Kapela]

Rob,

> I have few LX SFPs with DOM but I'm unsure if I reading outputs correctly.
[..]
> Tx Power '-4.9' better than '-6.9' (i.e. signal is stronger if TX
> Power is '-4.9' comparing to '-6.9')
> Rx Power '-9.6' is btter than '-11.2' (i.e. signal at receiver in case
> of '-9.6')

LX can vary anywhere from -7 ish (sometimes I've seen things out of
the box at -9 via DOM/DDM), up to as much as -4 (near what you're
apparently being shown here). DDM is 'best-effort' in the sense the
measurements accuracy is not terribly high. Its precision, however,
can be good enough that over time, you can tell if things are heading
south for either modules or fiber paths. Events such as bends,
macrobends, patch panels getting disturbed, cuts/breaks, etc. will all
reveal themselves as relative changes to these measurements.

That is, these measurements are best-used as a referential figure, not
absolute -- meaning you ought to start polling & storing them now for
the most utility to be found in troubleshooting later. ;)

-Tk
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] Interpreting DOM outputs

[Robert Hass]

Hi

I have few LX SFPs with DOM but I'm unsure if I reading outputs correctly.

   Optical   Optical
   Temperature  Voltage  Current   Tx Power  Rx Power
Port   (Celsius)(Volts)  (mA)  (dBm) (dBm)
-  ---  ---      
Gi4/139.6   3.21  12.4  -4.9 -11.2
Gi4/242.9   3.20  11.8  -4.7  -9.6
Gi4/538.9   3.33  20.9  -6.9 -12.3
Gi4/645.5   3.23  11.2  -4.9 -12.0

Tx Power '-4.9' better than '-6.9' (i.e. signal is stronger if TX
Power is '-4.9' comparing to '-6.9')
Rx Power '-9.6' is btter than '-11.2' (i.e. signal at receiver in case
of '-9.6')

Rob
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] How to see interface configuration after card failure on ASR9K

[Mark Tinka]

On Saturday, December 31, 2011 02:00:58 PM Koch, Andrew 
wrote:

> That is not my experience with preconfigure.  If I have a
> MSC go missing, all of the interfaces associated with
> the line card become "interface preconfigure xxx" and
> will restore when the MSC does.  I have also seen the
> interfaces show a preconfigure state during a boot-up
> process where the MSC has not completed loading yet. 
> None of the interfaces seen in either of these cases
> were initially pre-configured before the MSC & PLIM were
> installed.

That would make sense in theory, as a fully serviceable line 
card in a CRS system is a combination of the PLIM + MSC/FP, 
which makes up a complete forwarding engine.

After all, no point of a PLIM if there's no MSC or FP to 
drive it.

> I am not sure if this is the same on the ASR9k, my only
> experience with IOS-XR is on the CRS.

My comments were based on the ASR9000. As you may know, this 
one is different from the CRS in that serviceable line cards 
are integrated components that handle both forwarding and 
physical connectivity.

The RP's only provide switch fabric connectivity between the 
different slots.

> I also am not
> certain what the state would be if only the PLIM is
> reported as missing.

Indeed, per my point above of having a PLIM + MSC/FP 
combination to form the entire line card.

> One thing to note, the names of the interfaces may be
> re-ordered by the additional word preconfigure.  You may
> need to look farther down the configuration than where
> the interfaces were previously listed (this can really
> make a mess of Rancid).

Yes, that's we also saw. 'preconfigure' interfaces appear at 
the bottom of the configuration.

Mark.


signature.asc
Description: This is a digitally signed message part.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/