Re: [c-nsp] Pkt forwarding query

[John Neiberger]

Would traffic mirroring work? I haven't used it much in IOS XR. I'm
not even sure a tunnel can be a destination, but it would be worth a
shot.

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/interfaces/configuration/guide/hc43xasr9kbook/hc43span.html#wp1400132

On Mon, Nov 2, 2015 at 12:18 PM, Hank Nussbacher  wrote:
> I am looking for a simple solution on IOS-XR where each and every pkt that
> comes out of a specific interface (Gi0/1) would be auto-fwded into tunnel0
> (uni-directional only).  No routing decisions, no BGP lookup, no static
> routing, no FIB, no RIB, just some sort of auto-fwd rule which would bypass
> the router entirely.  Possible?
>
> Thanks,
> Hank
>
> ___
> 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] IOS-XR and interface discards (input)

[John Neiberger]

You can check the NP drop counters using the show drops command on ASR.
You can get basically the same data by doing show controller np ports all
location location to find the relevant NP then do show controllers np
counters np location. There's usually a lot of data there and it can
be hard to wade through, but that's the best place to start, IMO.

John



On Thu, May 14, 2015 at 1:04 PM, Hank Nussbacher h...@efes.iucc.ac.il
wrote:

 We have an ASR 9010 running IOS-XR v 5.1.3.  We see a high level of input
 discards:

 TenGigE0/1/1/7 is up, line protocol is up
   Interface state transitions: 25
   Layer 1 Transport Mode is WAN
   MTU 9028 bytes, BW 1000 Kbit (Max: 1000 Kbit)
  reliability 255/255, txload 13/255, rxload 99/255
   Encapsulation ARPA,
   Full-duplex, 1Mb/s, link type is force-up
   output flow control is on, input flow control is on
   Carrier delay (up) is 100 msec, Carrier delay (down) is 4000 msec
   loopback not set,
   ARP type ARPA, ARP timeout 04:00:00
   Last input 00:00:00, output 00:00:00
   Last clearing of show interface counters 1d13h
   30 second input rate 3886868000 bits/sec, 392410 packets/sec
   30 second output rate 527057000 bits/sec, 154557 packets/sec
  55223825999 packets input, 63505398737673 bytes, 116320028 total
 input drops
  0 drops for unrecognized upper-level protocol
  Received 111 broadcast packets, 1499584 multicast packets
   0 runts, 0 giants, 0 throttles, 0 parity
  10 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

 The config on the interface looks like this:

 interface TenGigE0/1/1/7
  mtu 9028
  ipv4 unreachables disable
  ipv6 nd dad attempts 5
  ipv6 address 2001:798:28:20aa::6/126
  monitor-session No1 ethernet
  flow-control bidirectional
  carrier-delay up 100 down 4000
  load-interval 30
  flow ipv4 monitor fmp-nfsen sampler fsm-nfsen ingress
  transport-mode wan
  ipv4 access-group catch13-ing ingress
 !

 Any clue would be helpful for us to begin to debug this issue.

 Thanks,
 Hank

 ___
 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/

[c-nsp] Questions about ASR9K output buffers

[John Neiberger]

We've been running into an issue with early tail drops on A9K-8T-L cards
and I'm trying to wrap my head around how buffering works on these cards. I
get the impression that they don't have dedicated per-interface output
queues and instead use some sort of shared buffering mechanism. We have an
egress policy-map applied and originally had no queue limit configured. It
turns out that this caused the default class to have a 64 KB buffer, which
led to a huge number of tail drops earlier than expected since most of the
traffic on this link is default class.

We've started to bump up the queue limit value to see if it reduces the
tail drops. This traffic is not latency sensitive, so I'm not concerned
with increasing the buffer size. I just want to significantly reduce the
tail drops we're seeing. We tried a value of 128 KB and that helped a bit.
Then we tried 512 KB over the weekend and that seems to get us much closer
to the expected result. I think I'm going to bump it up to 768 KB and see
how that goes.

I don't really understand queueing on this box, though, to be honest. Based
on what I've read, it seems that instead of fixed per-interface output
buffers, they use virtual output queues. But I'd swear I've read somewhere
that VOQs are not related to output buffers like I'm thinking and that
they're more related to queues between linecards. Not sure about that one.

Can anyone shed some light on this?

Many thanks,
John
___
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] PIM register-source command for IOS XR

[John Neiberger]

Thanks! For whatever reason, I couldn't find it in the 5.x PIM command
references.

John


On Thu, Aug 21, 2014 at 2:32 AM, Rimestad, Steinar 
steinar.rimes...@altibox.no wrote:

 Hi John,

 Should be the following:

 conf t
 router pim
  address-family ipv4
   register-source Loopback0


 Or the obligatory oneliner:

 router pim address-family ipv4 register-source loopback 0

 Regards,
 Steinar




 On 20/08/14 22:04, John Neiberger jneiber...@gmail.com wrote:

 I have a use case where I really need to force some ASR9Ks to use their
 loopback addresses as the source for PIM register messages but there
 doesn't seem to be a way to do it. I've checked up to version 5.2 and
 there
 doesn't seem to be a command to do this like there is in IOS.
 
 Do any of you know a way to do this?
 
 Thanks,
 John
 ___
 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/

[c-nsp] PIM register-source command for IOS XR

[John Neiberger]

I have a use case where I really need to force some ASR9Ks to use their
loopback addresses as the source for PIM register messages but there
doesn't seem to be a way to do it. I've checked up to version 5.2 and there
doesn't seem to be a command to do this like there is in IOS.

Do any of you know a way to do this?

Thanks,
John
___
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] Odd problem with N7K and multicast

[John Neiberger]

We ran into an interesting problem this morning and I've been told that
we've run into this same problem a couple of times before with other N7Ks.
This is ASM. We have a receiver and a source connected to the N7K. The RP
is a 7600 elsewhere. The N7K was rebooted (upgraded to 6.1(3), actually)
and when it came back up, the receiver could not join the source.

There was a *,G entry on the N7K and we could see the IGMPv2 join coming
from the receiver. Up on the RP, we could also see the *,G route there.
However, there was no S,G and there should have been since the source was
active.

Here's where it gets weird. The workaround is for a second receiver to send
an SSM join (IGMPv3) directly to the source. This sets up the S,G state on
the N7K and suddenly everything starts working. Even the RP starts showing
the S,G route that should have been there all along.

It seems as if the N7K has a problem with Source-to-RP communication. I
have no idea what else it could be. At least we have a workaround, but it
is still quite frustrating when dealing with several sources that all have
to jiggled manually like that.

Have any of you seen this before?
___
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] Cisco 7600 and 'show mfib' commands

[John Neiberger]

This looks like a command that is new in 12.2(33)SRD or SRE. At my old job,
all of our 7600s were running 12.2(33)SRC2. My new job has quite a variety
of code running. The box I'm on right now is running SRE code and does have
these commands available. I'm just not sure what they're trying to tell me.
They're quite different from the mfib commands availalbe on XR, for
example. It seems to be providing additional information related to the
state of distributed multicast forwarding, but I have no idea about the
specifics. For example, what is a broker in this context?

router#show mfib linecard

IPv4 MFIB
 Slot Linecard statusBroker status
 3/0  inactive   inactive
 2/0  inactive   inactive
 1/0  sync   enabled

IPv6 MFIB
 Slot Linecard statusBroker status

IPv4:Default, 29 entries, 33 ioitems
Slot  Table state
1/0   Sync


router#show mfib linecard summary

IPv4 MFIB
 Slot Linecard statusBroker status
 3/0  inactive   inactive
 2/0  inactive   inactive
 1/0  sync   enabled

router#show mfib ?
  background  MFIB background processing
  broker  MFIB information related to update brokers
  error   MFIB error state
  linecardMFIB information related to linecards
  nsf MFIB SSO NSF statistics
  state   MFIB state
  table   MFIB master table record
  timers  MFIB timers

  cr

router#show mfib state
MFIB Status:
 RP instance
IPv4 MFIB Status:
 Enable state:   distributed enabled
 Running state:  running distributed
IPv6 MFIB Status:
 Enable state:   disabled
 Running state:  not running
RRP HA state:
 Is standby RRP: no
 RF Peer Presence:   no
 RF PeerComm reached:no
 Redundancy mode:sso(3)
 IPv4 MFIB NSF sync: disabled/not running
 IPv6 MFIB NSF sync: disabled/not running

MFIB ISSU Status:
  MFIB IPv4 pull
No slots are ISSU capable.


router#show mfib table
1 active IPv4 table
Table Entries  State Flags
v4:Default 29  Sync  DEF,LCS,CEN,CON,EOF,PRG




On Mon, Jul 28, 2014 at 7:50 PM, Tony td_mi...@yahoo.com wrote:

 Hi John,

 Yes, mfib = multicast FIB.

 Are the boxes in question running multicast ?  (hint: show run | i
 multicast)

 What were the previous tickets about (or opened for) ?

 I'm not sure why they would be used for anything other than
 troubleshooting multicast traffic, it could be specific to a linecard if
 that was the problem encountered.


 regards,
 Tony.


   --
  *From:* John Neiberger jneiber...@gmail.com
 *To:* cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net
 *Sent:* Tuesday, 29 July 2014 2:47 AM
 *Subject:* [c-nsp] Cisco 7600 and 'show mfib' commands

 I'm at a new job and was looking at a few recent trouble tickets. I see
 that TAC had them use variations of the 'show mfib' commands, like 'show
 mfib linecard summary'. At my previous job, we had a few hundred 7600s but
 I don't recall TAC ever directing us to use those commands. I took a peek
 at them and it's not clear what I'm looking at.

 When I see mfib, I assume multicast FIB. I can't really tell if that's what
 I'm looking at or not, or the significance of the commands.

 I wasn't able to find much good info about these commands on CCO. Do any of
 you have any idea what these are really looking at? It seems that they
 might be useful for troubleshooting linecard issues but I'm entirely
 unfamiliar with them.
 ___
 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] Cisco 7600 and 'show mfib' commands

[John Neiberger]

Thanks for the link, Pete. That's very helpful!

John


On Tue, Jul 29, 2014 at 8:49 AM, Pete Lumbis alum...@gmail.com wrote:

 MFIB was added in 12.4.24T (or maybe 15.0M) and...I want to say SRD code.
 You can think of it like multicast CEF. Just like the RIB builds FIB,
 mroute builds mfib.  It's also the code where you see the pim tunnel
 interfaces for encap (on the FHR) and decap (on the RP).

 This might be helpful.

 http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_mfib/configuration/xe-3s/Multicast_Forwarding_Information_Base_Overview.html


 On Tue, Jul 29, 2014 at 10:22 AM, John Neiberger jneiber...@gmail.com
 wrote:

 This looks like a command that is new in 12.2(33)SRD or SRE. At my old
 job,
 all of our 7600s were running 12.2(33)SRC2. My new job has quite a variety
 of code running. The box I'm on right now is running SRE code and does
 have
 these commands available. I'm just not sure what they're trying to tell
 me.
 They're quite different from the mfib commands availalbe on XR, for
 example. It seems to be providing additional information related to the
 state of distributed multicast forwarding, but I have no idea about the
 specifics. For example, what is a broker in this context?

 router#show mfib linecard

 IPv4 MFIB
  Slot Linecard statusBroker status
  3/0  inactive   inactive
  2/0  inactive   inactive
  1/0  sync   enabled

 IPv6 MFIB
  Slot Linecard statusBroker status

 IPv4:Default, 29 entries, 33 ioitems
 Slot  Table state
 1/0   Sync


 router#show mfib linecard summary

 IPv4 MFIB
  Slot Linecard statusBroker status
  3/0  inactive   inactive
  2/0  inactive   inactive
  1/0  sync   enabled

 router#show mfib ?
   background  MFIB background processing
   broker  MFIB information related to update brokers
   error   MFIB error state
   linecardMFIB information related to linecards
   nsf MFIB SSO NSF statistics
   state   MFIB state
   table   MFIB master table record
   timers  MFIB timers

   cr

 router#show mfib state
 MFIB Status:
  RP instance
 IPv4 MFIB Status:
  Enable state:   distributed enabled
  Running state:  running distributed
 IPv6 MFIB Status:
  Enable state:   disabled
  Running state:  not running
 RRP HA state:
  Is standby RRP: no
  RF Peer Presence:   no
  RF PeerComm reached:no
  Redundancy mode:sso(3)
  IPv4 MFIB NSF sync: disabled/not running
  IPv6 MFIB NSF sync: disabled/not running

 MFIB ISSU Status:
   MFIB IPv4 pull
 No slots are ISSU capable.


 router#show mfib table
 1 active IPv4 table
 Table Entries  State Flags
 v4:Default 29  Sync  DEF,LCS,CEN,CON,EOF,PRG




 On Mon, Jul 28, 2014 at 7:50 PM, Tony td_mi...@yahoo.com wrote:

  Hi John,
 
  Yes, mfib = multicast FIB.
 
  Are the boxes in question running multicast ?  (hint: show run | i
  multicast)
 
  What were the previous tickets about (or opened for) ?
 
  I'm not sure why they would be used for anything other than
  troubleshooting multicast traffic, it could be specific to a linecard if
  that was the problem encountered.
 
 
  regards,
  Tony.
 
 
--
   *From:* John Neiberger jneiber...@gmail.com
  *To:* cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net
  *Sent:* Tuesday, 29 July 2014 2:47 AM
  *Subject:* [c-nsp] Cisco 7600 and 'show mfib' commands

 
  I'm at a new job and was looking at a few recent trouble tickets. I see
  that TAC had them use variations of the 'show mfib' commands, like 'show
  mfib linecard summary'. At my previous job, we had a few hundred 7600s
 but
  I don't recall TAC ever directing us to use those commands. I took a
 peek
  at them and it's not clear what I'm looking at.
 
  When I see mfib, I assume multicast FIB. I can't really tell if that's
 what
  I'm looking at or not, or the significance of the commands.
 
  I wasn't able to find much good info about these commands on CCO. Do
 any of
  you have any idea what these are really looking at? It seems that they
  might be useful for troubleshooting linecard issues but I'm entirely
  unfamiliar with them.
  ___
  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

[c-nsp] Cisco 7600 and 'show mfib' commands

[John Neiberger]

I'm at a new job and was looking at a few recent trouble tickets. I see
that TAC had them use variations of the 'show mfib' commands, like 'show
mfib linecard summary'. At my previous job, we had a few hundred 7600s but
I don't recall TAC ever directing us to use those commands. I took a peek
at them and it's not clear what I'm looking at.

When I see mfib, I assume multicast FIB. I can't really tell if that's what
I'm looking at or not, or the significance of the commands.

I wasn't able to find much good info about these commands on CCO. Do any of
you have any idea what these are really looking at? It seems that they
might be useful for troubleshooting linecard issues but I'm entirely
unfamiliar with them.
___
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] Stuck route issues on 7600 and ASR1000

[John Neiberger]

On Thu, May 15, 2014 at 1:16 PM, Mack McBride mack.mcbr...@viawest.comwrote:

 CSCuh43027


​It looks like the bug is triggered when you have deterministic med
configured. Did you have that configured or did this bite you without it?

John​
___
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] Multicast group but no traffic

[John Neiberger]

If you see an mroute for it but the traffic is not arriving, either the
upstream router isn't sending it to your or the TTL is expiring. If this is
IOS, check show ip traffic for the bad hop count and see if it's rapidly
increasing. If it is, the TTL is expiring at your hop. Also check for ACLs
that could be blocking it. You may also have an RPF problem in certain
weird cases. Do show ip rpf source and make sure it shows the interface
you expect.

John


On Fri, May 9, 2014 at 11:53 AM, Scott Voll svoll.v...@gmail.com wrote:

 I'm working on rolling out my Multicast across my WAN.

 I can see the Multicast group on the WAN router and I can see it on the
 switch interface, but I'm not getting the traffic.  What should I be
 looking at?

 TIA

 Scott
 ___
 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] Multicast group but no traffic

[John Neiberger]

Also, if this is XR, a really nice way to verify ingress and egress traffic
is like this:

show mfib hardware route statistics source group location location

If this is an ASR9K, you can use show drops if the traffic is dying on
your router interface. If it's CRS and it's being dropped on your router,
you'll have to use the various show controllers commands to find it.

John


On Fri, May 9, 2014 at 11:58 AM, John Neiberger jneiber...@gmail.comwrote:

 If you see an mroute for it but the traffic is not arriving, either the
 upstream router isn't sending it to your or the TTL is expiring. If this is
 IOS, check show ip traffic for the bad hop count and see if it's rapidly
 increasing. If it is, the TTL is expiring at your hop. Also check for ACLs
 that could be blocking it. You may also have an RPF problem in certain
 weird cases. Do show ip rpf source and make sure it shows the interface
 you expect.

 John


 On Fri, May 9, 2014 at 11:53 AM, Scott Voll svoll.v...@gmail.com wrote:

 I'm working on rolling out my Multicast across my WAN.

 I can see the Multicast group on the WAN router and I can see it on the
 switch interface, but I'm not getting the traffic.  What should I be
 looking at?

 TIA

 Scott
 ___
 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/

[c-nsp] ACL TCAM LOU exhaustion on 7600 running 15.1 code

[John Neiberger]

We had an interesting issue arise on Friday and I'm still wrestling with
it. The short story is that we have a 7600 with a lot of ACLs on it, some
of which are very long and most ACEs are port specific. This uses up a lot
of ACL TCAM LOUs, or logical objects. I didn't discover that until later,
though.

An ACL was updated on this 7600. Four lines were added. That ACL is applied
to a single interface. It appears that after those lines were added,
traffic that is NOT traversing that interface was affected. The symptoms
were intermittent connectivity in some cases. When we removed the ACL, the
traffic in question apparently began functioning. When we added the ACL
back to the interface, the traffic began to break again. Remember, this ACL
is NOT in the transit path for the traffic in question.

My first thought was TCAM. I checked show platform hardware capacity acl
and saw that LOUdst was at 100% with the ACL applied, but it was at 81%
with the ACL removed.

I've heard that if TCAM is overloaded, some ACLs will be processed by the
CPU, which clearly could cause problems. However, I did not see any rise in
CPU usage during this period.

Also, if we just remove the four new lines that were added, the LOUdst
value is still at 100%. I remain unconvinced that this was actually the
root cause for the issue.

Do any of you have any experience with this? What would be the expected
outcome of running out of LOU space in the ACL TCAM?

Thanks,
John
___
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] Temporal buffer calculations on ASR9K

[John Neiberger]

I just want to get a sanity check on some WRED settings. This is a 100G
linecard. If I have a class with bandwidth remaining percent 1
configured, as well as random detect 10ms 20ms configured, I believe that
means that WRED kicks in when the allotted buffer space is 10 ms full. If
I'm reading the docs right, that means we calculate the buffer minimum
value by multiplying 0.010s * 1Gbps / 8, for a minimum buffer value of 1.25
MB. The docs say that value gets rounded up to 1.536 MB, so WRED kicks in
when the link is congested and the buffer has filled to at least 1.536 MB
and will do 100% taildrop when it fills to twice that value (20ms).

Is that about right or am I off base?

Thanks!
___
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] Multicast NAT

[John Neiberger]

In IOS or IOS XR, is there a way to convert an IGMPv3 join to one S,G into
a join to a different S,G?

For example, if a device on a router joins 10.1.1.1 / 232.1.1.1, is there a
way to translate that to 20.2.2.2 / 232.2.2.2?

I'm thinking of a case where the original S,G is unavailable but we don't
have the ability to change the configuration on the receiver. Can we
translate it on the router? I've never heard of such a thing but I think I
may have run across a case where I need it.

Thanks!
___
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] Multicast NAT

[John Neiberger]

In this particular use case, anycast won't work for administrative reasons
related to the application. That was my first thought.


On Mon, Feb 17, 2014 at 3:43 PM, Jason Lixfeld ja...@lixfeld.ca wrote:

 What about anycast'ing the source?

 Sent from my iPhone

  On Feb 17, 2014, at 5:37 PM, John Neiberger jneiber...@gmail.com
 wrote:
 
  In IOS or IOS XR, is there a way to convert an IGMPv3 join to one S,G
 into
  a join to a different S,G?
 
  For example, if a device on a router joins 10.1.1.1 / 232.1.1.1, is
 there a
  way to translate that to 20.2.2.2 / 232.2.2.2?
 
  I'm thinking of a case where the original S,G is unavailable but we don't
  have the ability to change the configuration on the receiver. Can we
  translate it on the router? I've never heard of such a thing but I think
 I
  may have run across a case where I need it.
 
  Thanks!
  ___
  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] IOS-XR: 6PE - next-hop manipulation in route-policy.

[John Neiberger]

I don't have time at the moment to look up the details, but I seem to
recall that beginning in XR 4.2, there are limitations (or maybe flat
out restrictions) on setting the next-hop on an ingress route policy.
I do know that we had to change several of our route policies to get
around this when doing upgrades to 4.2 or beyond.

John

On Mon, Feb 3, 2014 at 8:17 AM, Jonathan Hart johathan.h...@gmail.com wrote:
 Hi list,



 I am trying to manipulate the next-hop for community-tagged routes, inbound
 on a 6PE router. Routes are received from route-reflectors, and should be
 treated inbound. In this specific scenario I am trying to change a
 next-hop. The configuration is based on what we have in production on IOS
 today, where this works just fine.



 PE is ASR9000 running IOS-XR 4.3.2.



 My configuration;

 Non-essential configuration has been omitted.



 router static

  address-family ipv6 unicast

   2001:db8::160/128 Null0

   :::192.168.0.1/128 Null0



 router bgp asn

  neighbor-group IPv6RR

address-family ipv6 labeled-unicast

route-policy rr-edge-in in





 route-policy rr-edge-in

   if community matches-any (1000:6) and destination in (::/0 ge 64) then

 set next-hop 2001:db8::160

   endif

 pass

 end-policy



 Also tried this..


 route-policy rr-edge-in

   if community matches-any (1000:6) and destination in (::/0 ge 64) then

 set next-hop :::192.168.0.1

   endif

 pass

 end-policy



 The defined policy is processing the routes. I tried swapping the
 next-hop statement for a simple drop, and the prefix was dropped. In
 IOS, I use an IPv6 next-hop which works just fine. In IOS-XR, I tried with
 both a normal IPv6 unicast address, and with IPv4-mapped address - without
 success.



 I am sure there is a reasonable explanation for this, and I have a feeling
 it lies in the 6PE part of the next-hop magic. As it seems to be working
 just fine in IOS, I'm fairly confident it should be possible to do in XR as
 well.



 Any help is appreciated!
 ___
 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] Bug or feature? 7600s forgetting service policy

[John Neiberger]

It has pretty much always been on some flavor of 6748 card, but I
don't know if it has only happened on, for example, SFP blades or
copper blades.

Thanks,
John

On Wed, Jan 15, 2014 at 5:50 AM, Xuhu jstuxuhu0...@gmail.com wrote:
 Which line card u r running, I tested previous and found some line card will 
 reset dscp value by default, some will trust, e.g ES+ card.

 Br,

 On 15 Jan, 2014, at 12:27 pm, John Neiberger jneiber...@gmail.com wrote:

 We seem to run into this fairly often and I'm curious about it. We use
 service policies for ingress DSCP marking. Occasionally, an interface won't
 mark the traffic despite being configured correctly. The output of show
 mls qos ip interface will show zero packets marked. We've found that
 removing the service policy and adding it back resolves the problem.

 I've never noticed the trigger for this until today when a module reloaded.
 When it came back up, several interfaces and vlans associated with the line
 card never started making traffic until we removed and reapplied the
 policy.

 I always thought this was a software bug. We almost always saw it on 12.2,
 but today's incident was on 15.1(3).

 Do any of you have any evidence with this problem? Any idea if it's a
 software problem or just some funky quirk of the platform?

 Thanks,
 John
 ___
 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] SPAN destination on oversubscribed module

[John Neiberger]

On Thu, Jan 9, 2014 at 7:47 AM, Ben Hammadi, Kayssar (NSN - TN/Tunis)
kayssar.ben_hamm...@nsn.com wrote:
 WS-X6716-10T

I presume that this module uses Janus ASICs for replication. If so,
keep in mind that this chip doesn't have a huge amount of replication
capacity. The ingress Janus chip is responsible for replicating
traffic for ingress SPANs, so you're effectively doubling the load on
the chip if you add a single SPAN. If you have a lot of traffic or if
you ever do something insane like adding yet another SPAN on the same
chip, you'll start dropping traffic internally on the linecard in a
way that is very hard to find unless you know what to look for. If it
were me, I'd stay away from permanent SPANs on 10gig interfaces on
this platform and do something else, like a tap.

John
___
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 4948 default IPv6 RA Behavior

[John Neiberger]

I have a 4948 running 12.2(53)SG2 connected via trunk to an upstream
router. I need to do some testing (long, unrelated story) because
we're having some IPv6-related issues with devices in a certain VLAN
on that switch. I can't test to a production server, so I was thinking
about adding an IPv6 address to the SVI for that VLAN on the switch.
The switch currently does not have an SVI for that VLAN since the
upstream router is doing the router. I just want the switch to be an
IPv6 host on that subnet. My concern is that I don't want the switch
to start acting like a router, e.g. sending Router Advertisements.
That would be a bad thing.

The documentation for 12.2(53)SG2 doesn't even mention IPv6 but the
commands are there. What would be the best (safest) way to do this?
Should I configure ipv6 nd ra suppress and then configure an IPv6
address on the SVI?

It's sad that I'm so wary of this but this is a production vlan and I
don't want hosts on that switch to suddenly think the switch SVI is a
default router. I'm probably over-thinking it, but better safe than
sorry. I'm still trying to get a handle on first hop issues and FHRPs
in IPv6 and have to say that the landscape is a little confusing.

Any thoughts?

Thanks,
John
___
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] GRE and MSS adjust on ASR9K

[John Neiberger]

Thanks! My Google-Fu must be weak. That page didn't turn up for me
despite multiple searches with variations of IOS XR tcp mss and
things like that. I appreciate the help.

On Fri, Dec 6, 2013 at 11:16 PM, Blake Dunlap iki...@gmail.com wrote:
 Appears to be added in 9k 4.3.2 based on documentation.

 http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.3/general/release/notes/reln_432a9k.html#concept_49AEDFA126ED408DBD1B04048C1E24B8

 -Blake


 On Fri, Dec 6, 2013 at 10:40 PM, John Neiberger jneiber...@gmail.com
 wrote:

 A co-worker is replacing a 7600 with an ASR9K running 4.2.3. The 7600
 currently terminates a GRE tunnel that requires the tcp mss-adjust
 command. Neither one of us can find a similar feature in the XR
 command references. Are we just missing it or does this code not have
 that feature? It seems like I must just be overlooking it.
 ___
 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/

[c-nsp] GRE and MSS adjust on ASR9K

[John Neiberger]

A co-worker is replacing a 7600 with an ASR9K running 4.2.3. The 7600
currently terminates a GRE tunnel that requires the tcp mss-adjust
command. Neither one of us can find a similar feature in the XR
command references. Are we just missing it or does this code not have
that feature? It seems like I must just be overlooking it.
___
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] TAC hits a new record level of aggravation...

[John Neiberger]

 It would be great if Cisco focus-group tested these 'enhancements' before 
 rolling them out, and knock it off with the Java nonsense.

It was in beta for months before they released it publicly. I think
the current version is vastly better than when I first saw it. But I
guess they didn't have any Mac users in the beta.  :)
___
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] Dynamic output buffer allocation on Cisco 4948

[John Neiberger]

Thanks! I talked to our Cisco NCE about this and he gave me these commands:

show qos  interface gigabitEthernet x/y- will show you 4 queues and also
whether QoS is disabled or not

sh int gi x/y counters detail -you will see packet counters in queue #1-4
incrementing

Sh platform hardware interface g x/y stat | in TxB


I'm nearly certain that this big buffer issue is the answer to my high
variable latency problem, but there is still one mystery about this that
has me completely perplexed. The high variable latency was only occurring
in one direction (from VLAN A to VLAN B) but not in the other (from VLAN B
to VLAN A). What really makes that weird is that because of some hsrp
differences, we really had a circular topology for a bit. The path was
*exactly* the same no matter which direction you were pinging. The ICMP
packets had to travel around the same circle through the same devices and
interfaces. So if we have big buffers on congested interfaces that are
introducing variable latency, why would we only see it in one direction?


When VLAN A pings VLAN B, it is the initial ICMP packet that would have
been delayed, while the response would come in on a different interface
that wasn't congested. When VLAN B pings VLAN A, the initial ping would not
hit congested interfaces but the ping reply would. The total round trip
time should have been similar, but it never was. I'm completely stumped by
that. I even had Cisco HTTS on this for a couple of days and they couldn't
figure it out.


Thanks,

John


On Thu, Sep 26, 2013 at 1:50 AM, Terebizh, Evgeny etereb...@amt.ru wrote:

 Try also
 show platform hardware interface gigabitEthernet 1/1 tx-queue.
 I guess it's gonna show the actual values for queue utilisation.
 Please let me know if this helps.

 /ET




 On 9/24/13 11:17 PM, John Neiberger jneiber...@gmail.com wrote:

 I've been helping to troubleshoot an interesting problem with variable
 latency through a 4948. I haven't run into this before. I usually have
 seen
 really low latency through 4948s, but this particular application requires
 consistent low latency and they've been noticing that latency goes up on
 average as load goes up. It didn't seem to be a problem on their servers,
 but communication through busy interfaces seemed to dramatically increase
 the latency. They were used to 1ms latency and it was bouncing up to 20+
 ms at times. I'm starting to think this is due to the shared output buffer
 in the 4948 causing the output buffer on the uplink to dynamically get
 bigger.
 
 I've been trying to find more details on how the 4948 handles its shared
 output queue space, but I haven't been able to find anything. Do any of
 you
 know more about how this works and what commands I could use to
 troubleshoot? I can't find anything that might show how much buffer space
 a
 particular interface is using at any given time, or if it even makes sense
 to think of it that way. If I knew the size of the buffer at any given
 moment, I could calculate the expected latency and prove whether or not
 that was the problem.
 
 Thanks!
 John
 ___
 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] Dynamic output buffer allocation on Cisco 4948

[John Neiberger]

It was host to host, so it was really Host A to Host B and vice versa. The
expected RTT was less than a millisecond, which is what they often got, but
the latency would spike regularly up to as high as 24 ms. I initially
thought it was a problem on one of the hosts but they can ping to and from
devices on the same vlan with no variable latency. The latency only occurs
in one direction when going from one vlan to the other. We manipulated the
HSRP configs to shift traffic to different routers and switches but the
behavior didn't change. From Host A to Host B we saw variable latency, but
never ever did we see it if the ping originated from Host B even though,
depending on the HSRP configuration, the packets were traversing exactly
the same path. It has me completely stumped.


On Thu, Sep 26, 2013 at 9:04 AM, Blake Dunlap iki...@gmail.com wrote:

 This may seem like a stupid question, but when you were pinging, were you
 pinging from hosts, or from the routers?

 -Blake


 On Thu, Sep 26, 2013 at 9:38 AM, John Neiberger jneiber...@gmail.comwrote:

 Thanks! I talked to our Cisco NCE about this and he gave me these
 commands:

 show qos  interface gigabitEthernet x/y- will show you 4 queues and also
 whether QoS is disabled or not

 sh int gi x/y counters detail -you will see packet counters in queue #1-4
 incrementing

 Sh platform hardware interface g x/y stat | in TxB


 I'm nearly certain that this big buffer issue is the answer to my high
 variable latency problem, but there is still one mystery about this that
 has me completely perplexed. The high variable latency was only occurring
 in one direction (from VLAN A to VLAN B) but not in the other (from VLAN B
 to VLAN A). What really makes that weird is that because of some hsrp
 differences, we really had a circular topology for a bit. The path was
 *exactly* the same no matter which direction you were pinging. The ICMP
 packets had to travel around the same circle through the same devices and
 interfaces. So if we have big buffers on congested interfaces that are
 introducing variable latency, why would we only see it in one direction?


 When VLAN A pings VLAN B, it is the initial ICMP packet that would have
 been delayed, while the response would come in on a different interface
 that wasn't congested. When VLAN B pings VLAN A, the initial ping would
 not
 hit congested interfaces but the ping reply would. The total round trip
 time should have been similar, but it never was. I'm completely stumped by
 that. I even had Cisco HTTS on this for a couple of days and they couldn't
 figure it out.


 Thanks,

 John


 On Thu, Sep 26, 2013 at 1:50 AM, Terebizh, Evgeny etereb...@amt.ru
 wrote:

  Try also
  show platform hardware interface gigabitEthernet 1/1 tx-queue.
  I guess it's gonna show the actual values for queue utilisation.
  Please let me know if this helps.
 
  /ET
 
 
 
 
  On 9/24/13 11:17 PM, John Neiberger jneiber...@gmail.com wrote:
 
  I've been helping to troubleshoot an interesting problem with variable
  latency through a 4948. I haven't run into this before. I usually have
  seen
  really low latency through 4948s, but this particular application
 requires
  consistent low latency and they've been noticing that latency goes up
 on
  average as load goes up. It didn't seem to be a problem on their
 servers,
  but communication through busy interfaces seemed to dramatically
 increase
  the latency. They were used to 1ms latency and it was bouncing up to
 20+
  ms at times. I'm starting to think this is due to the shared output
 buffer
  in the 4948 causing the output buffer on the uplink to dynamically get
  bigger.
  
  I've been trying to find more details on how the 4948 handles its
 shared
  output queue space, but I haven't been able to find anything. Do any of
  you
  know more about how this works and what commands I could use to
  troubleshoot? I can't find anything that might show how much buffer
 space
  a
  particular interface is using at any given time, or if it even makes
 sense
  to think of it that way. If I knew the size of the buffer at any given
  moment, I could calculate the expected latency and prove whether or not
  that was the problem.
  
  Thanks!
  John
  ___
  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] Dynamic output buffer allocation on Cisco 4948

[John Neiberger]

Host to host on the same VLAN was always far less than 1ms RTT. I never
once saw it go over that. It was usually far less. We only saw the problem
when going from a host in VLAN A to a host in VLAN B, never the other way
around. I thought this was a problem on the host in VLAN B, but any other
server in the same VLAN could ping it with no latency problems at all.


On Thu, Sep 26, 2013 at 9:12 PM, Fwissue fwis...@gmail.com wrote:

 I would try host to host on the same vlan, then consider flow-control
 impact

 Thanks

 ~mike

 On Sep 26, 2013, at 8:18 AM, John Neiberger jneiber...@gmail.com wrote:

  It was host to host, so it was really Host A to Host B and vice versa.
 The
  expected RTT was less than a millisecond, which is what they often got,
 but
  the latency would spike regularly up to as high as 24 ms. I initially
  thought it was a problem on one of the hosts but they can ping to and
 from
  devices on the same vlan with no variable latency. The latency only
 occurs
  in one direction when going from one vlan to the other. We manipulated
 the
  HSRP configs to shift traffic to different routers and switches but the
  behavior didn't change. From Host A to Host B we saw variable latency,
 but
  never ever did we see it if the ping originated from Host B even though,
  depending on the HSRP configuration, the packets were traversing exactly
  the same path. It has me completely stumped.
 
 
  On Thu, Sep 26, 2013 at 9:04 AM, Blake Dunlap iki...@gmail.com wrote:
 
  This may seem like a stupid question, but when you were pinging, were
 you
  pinging from hosts, or from the routers?
 
  -Blake
 
 
  On Thu, Sep 26, 2013 at 9:38 AM, John Neiberger jneiber...@gmail.com
 wrote:
 
  Thanks! I talked to our Cisco NCE about this and he gave me these
  commands:
 
  show qos  interface gigabitEthernet x/y- will show you 4 queues and
 also
  whether QoS is disabled or not
 
  sh int gi x/y counters detail -you will see packet counters in queue
 #1-4
  incrementing
 
  Sh platform hardware interface g x/y stat | in TxB
 
 
  I'm nearly certain that this big buffer issue is the answer to my high
  variable latency problem, but there is still one mystery about this
 that
  has me completely perplexed. The high variable latency was only
 occurring
  in one direction (from VLAN A to VLAN B) but not in the other (from
 VLAN B
  to VLAN A). What really makes that weird is that because of some hsrp
  differences, we really had a circular topology for a bit. The path was
  *exactly* the same no matter which direction you were pinging. The ICMP
  packets had to travel around the same circle through the same devices
 and
  interfaces. So if we have big buffers on congested interfaces that are
  introducing variable latency, why would we only see it in one
 direction?
 
 
  When VLAN A pings VLAN B, it is the initial ICMP packet that would have
  been delayed, while the response would come in on a different interface
  that wasn't congested. When VLAN B pings VLAN A, the initial ping would
  not
  hit congested interfaces but the ping reply would. The total round trip
  time should have been similar, but it never was. I'm completely
 stumped by
  that. I even had Cisco HTTS on this for a couple of days and they
 couldn't
  figure it out.
 
 
  Thanks,
 
  John
 
 
  On Thu, Sep 26, 2013 at 1:50 AM, Terebizh, Evgeny etereb...@amt.ru
  wrote:
 
  Try also
  show platform hardware interface gigabitEthernet 1/1 tx-queue.
  I guess it's gonna show the actual values for queue utilisation.
  Please let me know if this helps.
 
  /ET
 
 
 
 
  On 9/24/13 11:17 PM, John Neiberger jneiber...@gmail.com wrote:
 
  I've been helping to troubleshoot an interesting problem with
 variable
  latency through a 4948. I haven't run into this before. I usually
 have
  seen
  really low latency through 4948s, but this particular application
  requires
  consistent low latency and they've been noticing that latency goes up
  on
  average as load goes up. It didn't seem to be a problem on their
  servers,
  but communication through busy interfaces seemed to dramatically
  increase
  the latency. They were used to 1ms latency and it was bouncing up to
  20+
  ms at times. I'm starting to think this is due to the shared output
  buffer
  in the 4948 causing the output buffer on the uplink to dynamically
 get
  bigger.
 
  I've been trying to find more details on how the 4948 handles its
  shared
  output queue space, but I haven't been able to find anything. Do any
 of
  you
  know more about how this works and what commands I could use to
  troubleshoot? I can't find anything that might show how much buffer
  space
  a
  particular interface is using at any given time, or if it even makes
  sense
  to think of it that way. If I knew the size of the buffer at any
 given
  moment, I could calculate the expected latency and prove whether or
 not
  that was the problem.
 
  Thanks!
  John
  ___
  cisco

Re: [c-nsp] Dynamic output buffer allocation on Cisco 4948

[John Neiberger]

We played around with HSRP to end up with a couple of different topologies
to help eliminate potential issues. We were still seeing this issue when it
was as simple as this:

[host A] -- [switch 1] - [7600]  [switch 2]  [host B]

There is another 7600 that both switches are connected to, as well, and we
toyed with redundancy to shift traffic around to different links and such,
but nothing made the slightest bit of difference. We ultimately added
another 1-gig link to the switch uplinks and made them a port channel,
which seems to have gotten their latency down to something manageable. The
next step would be to tweak the QoS to treat this as EF, as you suggested.
I guess we'll see if things stay good or if they run into problems as they
add more load in the future.

This app isn't the only thing on these switches, but it accounts for the
bulk of the load and it's the only thing we know of that was having
problems. It's a pretty odd situation, and I haven't done a good job of
explaining how everything is connected. I suck at text diagrams.  :)  But
even Cisco HTTS was pretty stumped. They looked at it for quite a while and
weren't able to nail down the cause. I sure it was the buffer issue,
though.

Thanks,
John


On Thu, Sep 26, 2013 at 9:55 PM, Blake Dunlap iki...@gmail.com wrote:

 Its hard to make any inferences on your vodoo 1 way round trip latency
 without more detail like diagrams, so i'll take a step back and ask is this
 overly delay sensitive app the main load on the switch, or just a rounding
 error as far as total traffic?

 If it is the first option, honestly I don't really know what you can do
 besides upgrading your uplinks with the next step in speed, using more
 active channels/paths, lowering your oversubscription ratio with more
 hardware, or just giving up and choosing between delaying the microbursts
 or dropping them. If it is the second, then have you tried setting up LLQ
 and treating your app as EF?

 -Blake


 On Thu, Sep 26, 2013 at 10:34 PM, John Neiberger jneiber...@gmail.comwrote:

 Host to host on the same VLAN was always far less than 1ms RTT. I never
 once saw it go over that. It was usually far less. We only saw the problem
 when going from a host in VLAN A to a host in VLAN B, never the other way
 around. I thought this was a problem on the host in VLAN B, but any other
 server in the same VLAN could ping it with no latency problems at all.


 On Thu, Sep 26, 2013 at 9:12 PM, Fwissue fwis...@gmail.com wrote:

 I would try host to host on the same vlan, then consider flow-control
 impact

 Thanks

 ~mike

 On Sep 26, 2013, at 8:18 AM, John Neiberger jneiber...@gmail.com
 wrote:

  It was host to host, so it was really Host A to Host B and vice versa.
 The
  expected RTT was less than a millisecond, which is what they often
 got, but
  the latency would spike regularly up to as high as 24 ms. I initially
  thought it was a problem on one of the hosts but they can ping to and
 from
  devices on the same vlan with no variable latency. The latency only
 occurs
  in one direction when going from one vlan to the other. We manipulated
 the
  HSRP configs to shift traffic to different routers and switches but the
  behavior didn't change. From Host A to Host B we saw variable latency,
 but
  never ever did we see it if the ping originated from Host B even
 though,
  depending on the HSRP configuration, the packets were traversing
 exactly
  the same path. It has me completely stumped.
 
 
  On Thu, Sep 26, 2013 at 9:04 AM, Blake Dunlap iki...@gmail.com
 wrote:
 
  This may seem like a stupid question, but when you were pinging, were
 you
  pinging from hosts, or from the routers?
 
  -Blake
 
 
  On Thu, Sep 26, 2013 at 9:38 AM, John Neiberger jneiber...@gmail.com
 wrote:
 
  Thanks! I talked to our Cisco NCE about this and he gave me these
  commands:
 
  show qos  interface gigabitEthernet x/y- will show you 4 queues and
 also
  whether QoS is disabled or not
 
  sh int gi x/y counters detail -you will see packet counters in queue
 #1-4
  incrementing
 
  Sh platform hardware interface g x/y stat | in TxB
 
 
  I'm nearly certain that this big buffer issue is the answer to my
 high
  variable latency problem, but there is still one mystery about this
 that
  has me completely perplexed. The high variable latency was only
 occurring
  in one direction (from VLAN A to VLAN B) but not in the other (from
 VLAN B
  to VLAN A). What really makes that weird is that because of some hsrp
  differences, we really had a circular topology for a bit. The path
 was
  *exactly* the same no matter which direction you were pinging. The
 ICMP
  packets had to travel around the same circle through the same
 devices and
  interfaces. So if we have big buffers on congested interfaces that
 are
  introducing variable latency, why would we only see it in one
 direction?
 
 
  When VLAN A pings VLAN B, it is the initial ICMP packet that would
 have
  been delayed, while the response

[c-nsp] Dynamic output buffer allocation on Cisco 4948

[John Neiberger]

I've been helping to troubleshoot an interesting problem with variable
latency through a 4948. I haven't run into this before. I usually have seen
really low latency through 4948s, but this particular application requires
consistent low latency and they've been noticing that latency goes up on
average as load goes up. It didn't seem to be a problem on their servers,
but communication through busy interfaces seemed to dramatically increase
the latency. They were used to 1ms latency and it was bouncing up to 20+
ms at times. I'm starting to think this is due to the shared output buffer
in the 4948 causing the output buffer on the uplink to dynamically get
bigger.

I've been trying to find more details on how the 4948 handles its shared
output queue space, but I haven't been able to find anything. Do any of you
know more about how this works and what commands I could use to
troubleshoot? I can't find anything that might show how much buffer space a
particular interface is using at any given time, or if it even makes sense
to think of it that way. If I knew the size of the buffer at any given
moment, I could calculate the expected latency and prove whether or not
that was the problem.

Thanks!
John
___
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] Dynamic output buffer allocation on Cisco 4948

[John Neiberger]

Sure, I get that. I'm just curious to know if there is a way to tell the
depth of the queue on an interface at any given time. I'm nearly certain
this is the cause of the variable latency we were seeing. What I don't know
is if there is a way to see it happening on the switch. We may need to
tweak the output queue settings for this particular application. It sounds
like it is extremely sensitive to variable latency.

Thanks,
John


On Tue, Sep 24, 2013 at 2:32 PM, Blake Dunlap iki...@gmail.com wrote:

 The point of the large buffers of that switch is to prevent drops under
 port congestion. If you want drops or something like LLQ to occur instead
 for your app traffic, you can tweak the QoS settings appropriately for your
 app / switch.

 -Blake


 On Tue, Sep 24, 2013 at 2:17 PM, John Neiberger jneiber...@gmail.comwrote:

 I've been helping to troubleshoot an interesting problem with variable
 latency through a 4948. I haven't run into this before. I usually have
 seen
 really low latency through 4948s, but this particular application requires
 consistent low latency and they've been noticing that latency goes up on
 average as load goes up. It didn't seem to be a problem on their servers,
 but communication through busy interfaces seemed to dramatically increase
 the latency. They were used to 1ms latency and it was bouncing up to 20+
 ms at times. I'm starting to think this is due to the shared output buffer
 in the 4948 causing the output buffer on the uplink to dynamically get
 bigger.

 I've been trying to find more details on how the 4948 handles its shared
 output queue space, but I haven't been able to find anything. Do any of
 you
 know more about how this works and what commands I could use to
 troubleshoot? I can't find anything that might show how much buffer space
 a
 particular interface is using at any given time, or if it even makes sense
 to think of it that way. If I knew the size of the buffer at any given
 moment, I could calculate the expected latency and prove whether or not
 that was the problem.

 Thanks!
 John
 ___
 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] IOS XR Null darknet traffic at border without impacting convergence time

[John Neiberger]

If I understand the problem, you can implement selective BGP next hop
filtering. That allows you to use a route policy to determine which next
hops are valid. We use it to ensure that no prefix shorter than a /29 is
used to validate next hops in certain situations.

This is the basic idea:


router bgp AS

 address-family ipv4 unicast

  nexthop route-policy NEXT-HOP-TRACKING


 route-policy NEXT-HOP-TRACKING

  if destination in (0.0.0.0/0 ge 29) then

pass

  endif

end-policy



You can probably tweak that policy to get the desired results.


HTH,

John


On Fri, Sep 6, 2013 at 11:10 AM, Drew Weaver drew.wea...@thenap.com wrote:

 Hi,

 There is a chance I am going about this design in a sub-optimal way; so if
 that is the case feel free to let me know.

 We have a facility in location A which hosts some content behind our
 core/distribution routers.
 We have a facility in location B which is basically just used for peering
 and transit connectivity.

 The routers in location A announce our public prefixes to the routers in
 location B which in turn announce those prefixes to the Internet because
 there are 500 miles between location A and location B we would rather not
 transit packets for /32s which have no route in our IGP (darknet). (The
 quantity of direct connectivity available in location A makes hauling the
 traffic ourselves a priority).

 To this end when we announce the prefixes from the core to the border the
 next hop is set to 192.0.2.1 which is nailed as a static route to null at
 the border.

 When the link between location A and location B fails (which happens
 occasionally even though it's protected) IOS XR's next hop tracking
 immediately realizes that the routers which originate the prefixes are
 unreachable. However, because there is still a static route to 192.0.2.1,
 the prefixes are not withdrawn until the regular BGP timer expires and the
 session falls.

 This is what sh bgp nexthops looks like before the link goes down:


   RIB Related Information

 Gateway: reachable, non-Connected route, prefix length 32

 And after:


 RIB Related Information

 Gateway: unreachable, non-Connected route, prefix length 49374

 During the time between when the link fails and the BGP session expires
 the ASR obviously continues to announce that it is a valid path for those
 prefixes to the Internet, thus essentially creating a black hole for a
 brief (but not brief enough) period of time. Although this condition has
 only happened twice in a number of years, I would like to avoid it
 altogether.

 Does anyone know of a configurable way to tell IOS XR to immediately
 withdrawal prefixes which _originate_ from an unreachable nexthop?

 Thanks for any ideas you may have regarding this.

 -Drew





 ___
 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] Multicast

[John Neiberger]

show int interface counters

show ip multicast interface

show ip mroute group count


On Thu, Sep 5, 2013 at 7:33 AM, Harry Hambi harry.ha...@bbc.co.uk wrote:

 Wanted to see the multicast traffic counters incrementing/or not, on a
 specific port


 Rgds
 Harry

 Harry Hambi BEng(Hons)  MIET  Rsgb

 -Original Message-
 From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
 Phil Mayers
 Sent: 05 September 2013 14:29
 To: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Multicast

 On 05/09/13 14:17, Harry Hambi wrote:
  Hi all,
  Is there a command on the 6500 that will show the Multicast traffic
  in/out of a port?. Thanks in advance

 What does show multicast traffic mean?

 If you want to see the raw data packets, you'll need to use SPAN or
 R/ERSPAN.

 If you want to see IGMP joins, sh ip igmp and sub-commands.

 If you want to see output routes, sh ip mroute and sub-commands.

 Be more specific!
 ___
 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/


 -
 http://www.bbc.co.uk
 This e-mail (and any attachments) is confidential and
 may contain personal views which are not the views of the BBC unless
 specifically stated.
 If you have received it in
 error, please delete it from your system.
 Do not use, copy or disclose the
 information in any way nor act in reliance on it and notify the sender
 immediately.
 Please note that the BBC monitors e-mails
 sent or received.
 Further communication will signify your consent to
 this.
 -

 ___
 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/

[c-nsp] Initializing trace files on CRS

[John Neiberger]

I'm trying to run a couple of trace commands and I'm running into something
unusual. When I try show pim trace I get a handful of lines but nothing
useful at all. I should be getting page after page of output, or at least I
would expect that since that's what I see on other CRS that I deal with. If
I try show bgp trace, I get the following error:

Trace files(s) not found or has not been initialized

I get that same message when trying several other trace commands. However,
some trace commands work, like show arp trace.

Any idea why PIM and BGP traces aren't enabled? I haven't been able to find
any command that initializes trace files. We don't have anything like that
on the other routers I usually work on and I have no problems with those.

In case it's relevant, this is on XR 4.2.4.

Thanks,
John
___
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] Temporarily disable all forwarding on ASR9K

[John Neiberger]

We need to upgrade some ASR9Ks that have a lot of connected devices with
complex interrelationships and we have to do a lot of work to make sure all
the correct redundancy is in place prior to the upgrade. Since the router
takes so long to reload, I'd like to find a way to essentially simulate the
loss of forwarding for a minute or so to verify that our redundancy
preparations were thorough, but I need to be able to back out of it
quickly. I thought about shutting down the linecards but that's still a
fairly long restart. I'm hoping to find some method much faster than that.

The simplest and most straightforward way is to shut down all the
interfaces manually and then rollback if necessary. We can take it out of
routing by setting the overload bit in ISIS, but that still leaves routing
and forwarding in place for locally connected interfaces, which is what we
want to stop. We were tossing around some ideas and wondered, probably just
academically, if there were a way to completely stop forwarding temporarily.

Is there a way to disable forwarding through an ASR9K that is easily and
quickly reversible? We'll probably do the interface shutdown method since
it's so simple, but now I'm curious what other options might be available.
___
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] Temporarily disable all forwarding on ASR9K

[John Neiberger]

In my case, the best result would be to simulate taking the entire device
offline, but I don't know if that's possible to reverse quickly. Taking the
interfaces down would be great. Really, the simplest thing to do is just
spend a minute to create a SMOP that shuts down the interfaces and be done
with it. I'm just curious if there are other interesting ways to accomplish
something similar. I wonder if there are some processes that can be killed
to take the router offline and then restarted to bring it back online. Even
if that were possible, I'm sure it would be a fairly bad idea. lol

Another thought was to shutdown the linecards but leave them powered up. I
haven't tried it but I wondered if maybe bringing them back up from a
shutdown state would be faster than doing it from a fully powered down
state. If so, that might be another option. Not even close to as fast as
just shutting them down and rolling back, if necessary. That's going to be
tough to beat.


On Wed, Aug 14, 2013 at 7:43 PM, Pete Lumbis alum...@gmail.com wrote:

 This raises a good point.

 Is the goal to simulate a black-hole that could be seen with an incorrect
 adjacency, where control plane is healthy but data plane is broken, or is
 the goal to simulate taking this device offline?

 Do we care about carrier on the interfaces?


 On Wed, Aug 14, 2013 at 6:19 PM, arulgobinath emmanuel arulg...@gmail.com
  wrote:

 null0 doesn't cause the NHRP to trigger IMHO  this will be a disaster  .
 shut / no shut is the easiest but it doesn't simulate the whole part.
 real test comes when the modules crash when reloading specially after
 couple of years... :)
 what if we copy a empty config ??? and rollback the config ? i didn't
 test this anyway .


 On Wed, Aug 14, 2013 at 10:13 PM, Pete Lumbis alum...@gmail.com wrote:

 Copy/paste a bunch of null0 routes?

 deny any acls on interfaces?


 On Wed, Aug 14, 2013 at 10:54 AM, John Neiberger jneiber...@gmail.com
 wrote:

  We need to upgrade some ASR9Ks that have a lot of connected devices
 with
  complex interrelationships and we have to do a lot of work to make
 sure all
  the correct redundancy is in place prior to the upgrade. Since the
 router
  takes so long to reload, I'd like to find a way to essentially
 simulate the
  loss of forwarding for a minute or so to verify that our redundancy
  preparations were thorough, but I need to be able to back out of it
  quickly. I thought about shutting down the linecards but that's still a
  fairly long restart. I'm hoping to find some method much faster than
 that.
 
  The simplest and most straightforward way is to shut down all the
  interfaces manually and then rollback if necessary. We can take it out
 of
  routing by setting the overload bit in ISIS, but that still leaves
 routing
  and forwarding in place for locally connected interfaces, which is
 what we
  want to stop. We were tossing around some ideas and wondered, probably
 just
  academically, if there were a way to completely stop forwarding
  temporarily.
 
  Is there a way to disable forwarding through an ASR9K that is easily
 and
  quickly reversible? We'll probably do the interface shutdown method
 since
  it's so simple, but now I'm curious what other options might be
 available.
  ___
  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] BGP Signalled VPLS

[John Neiberger]

I was about to ask the same question.  :-)  I'm curious what SR stands for
in this context.


On Wed, Aug 7, 2013 at 9:18 AM, Blake Dunlap iki...@gmail.com wrote:

 Ok, I'll bite, what does SR stand for and I'll happily google it myself?

 -Blake


 On Wed, Aug 7, 2013 at 3:51 AM, Mark Tinka mark.ti...@seacom.mu wrote:

  On Wednesday, August 07, 2013 08:08:10 AM Saku Ytti wrote:
 
   Guilty as charged, as penance I'll implement full-mesh
   RSVP topologies for rest of the day.
 
  Not to worry, I'm sold on SR :-).
 
  Mark.
 
  ___
  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] ASR9000 LC CPU Punt

[John Neiberger]

As I understand it, LPTS handles any locally destined traffic, which would
include the following (according to the book IOS XR Fundamentals):


* All IPv4, IPv6, and MPLS traffic related to routing protocols, or control
plane such as MPLS LDP or RSVP. The control plane computations for
protocols are done on the Router Processor (RP) of the router. Therefore,
whenever routing or MPLS control plane traffic is received on a line card
interface, it needs to be delivered to the RP of the router.
* MPLS packets with the Router Alert label
* IPv4, IPv6, or MPLS packets with a TTL less than 2
* IPv4 or IPv6 packets with options
* IP packets requiring fragmentation or reassembly
* Layer 2 keepalives
* Address Resolution Protocol (ARP) packets
* ICMP message generation and response




On Tue, Aug 6, 2013 at 3:57 PM, Kasper Adel karim.a...@gmail.com wrote:

 Doesnt lpts handle for-us packets only?

 Whats the command to see punted traffic?

 Kim


 On Tuesday, August 6, 2013, John Neiberger wrote:

 Check the LPTS counters. LPTS (Local Packet Transport Service) is
 essentially control plane policing. Here's a page that talks about it.
 Most
 of the commands are not very user friendly, but it seems to be fairly
 powerful.

 https://supportforums.cisco.com/docs/DOC-23032

 I thing the command you'll need will be some variation of show lpts pifib
 hardware entry location location, but I'm not at a router right now to
 play around with it.

 HTH,
 John


 On Mon, Aug 5, 2013 at 6:14 PM, Sami Joseph sami.jos...@gmail.com
 wrote:

  Hello,
 
  How do i check if the LC CPU is getting packets punted to it ?
 
  Thanks,
  Sam
  ___
  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] ASR9000 LC CPU Punt

[John Neiberger]

Check the LPTS counters. LPTS (Local Packet Transport Service) is
essentially control plane policing. Here's a page that talks about it. Most
of the commands are not very user friendly, but it seems to be fairly
powerful.

https://supportforums.cisco.com/docs/DOC-23032

I thing the command you'll need will be some variation of show lpts pifib
hardware entry location location, but I'm not at a router right now to
play around with it.

HTH,
John


On Mon, Aug 5, 2013 at 6:14 PM, Sami Joseph sami.jos...@gmail.com wrote:

 Hello,

 How do i check if the LC CPU is getting packets punted to it ?

 Thanks,
 Sam
 ___
 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/

[c-nsp] Label still appearing in traceroute after disabling ttl propagation

[John Neiberger]

W
e're running into an interesting problem. We have a simple lab setup like
this:

CE1 -- PE1 --- P1 --- P2 --- PE2 --- CE2

We have mpls ip-ttl-propagate disable on all PE and P routers, but if we
trace from CE1 to CE2, we still see an MPLS label coming from the PE2
router. If we trace CE2 to CE1, we see a label on the hop from P1 to PE1.

If we have ttl propagation completely disabled, why would we still see the
label and P-to-PE link in the path?

All P and PE routers are IOS XR running 4.1.0.

Thanks,
John
___
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] Label still appearing in traceroute after disabling ttl propagation

[John Neiberger]

I think either we're just doing something wrong or perhaps we're running
into a bug. I did find this one, which sounds similar:

https://tools.cisco.com/bugsearch/bug/CSCtd17126

I'm not sure if that is fixed in 4.1.0 or not.


On Tue, Jul 30, 2013 at 11:01 AM, John Neiberger jneiber...@gmail.comwrote:

 W
 e're running into an interesting problem. We have a simple lab setup like
 this:

 CE1 -- PE1 --- P1 --- P2 --- PE2 --- CE2

 We have mpls ip-ttl-propagate disable on all PE and P routers, but if we
 trace from CE1 to CE2, we still see an MPLS label coming from the PE2
 router. If we trace CE2 to CE1, we see a label on the hop from P1 to PE1.

 If we have ttl propagation completely disabled, why would we still see the
 label and P-to-PE link in the path?

 All P and PE routers are IOS XR running 4.1.0.

 Thanks,
 John

___
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] Label still appearing in traceroute after disabling ttl propagation

[John Neiberger]

After a little more investigation, I think the problem is that our P2
router is not learning a set of prefixes via LDP that it should be, so it
is sending them unlabeled to PE2. We assumed that both P routers had the
right labels, but that doesn't appear to be the case.


On Tue, Jul 30, 2013 at 12:20 PM, John Neiberger jneiber...@gmail.comwrote:

 I guess I should rephrase. We have configured mpls ip-ttl-propagate
 disable to try to hide the labeled part of the path. For whatever reason,
 we always get something like the following:
 CE1#trace 10.6.10.1 source lo0
 Type escape sequence to abort.
 Tracing the route to 10.6.10.1
 VRF info: (vrf in name/id, vrf out name/id)
   1 192.168.105.50 0 msec 0 msec 0 msec
   2 192.168.62.2 [MPLS: Label 16018 Exp 0] 4 msec 0 msec 0 msec
   3 192.168.62.60 0 msec 0 msec 0 msec
   4 192.168.106.61 4 msec *  0 msec
 CE1#
 If I trace from CE1 to the loopback of PE2, which is the same path, it
 works as expected and the labeled part of the path is hidden:

 CE5#trace 10.6.1.1 source lo0
 Type escape sequence to abort.
 Tracing the route to 10.6.1.1
 VRF info: (vrf in name/id, vrf out name/id)
   1 192.168.105.50 4 msec 0 msec 0 msec
   2 192.168.62.60 0 msec *  0 msec


 On Tue, Jul 30, 2013 at 11:43 AM, Jared Mauch ja...@puck.nether.netwrote:

 Disable TTL != don't copy label into ICMP TTL Expired message.

 - Jared

 On Jul 30, 2013, at 1:37 PM, John Neiberger jneiber...@gmail.com wrote:

  I think either we're just doing something wrong or perhaps we're running
  into a bug. I did find this one, which sounds similar:
 
  https://tools.cisco.com/bugsearch/bug/CSCtd17126
 
  I'm not sure if that is fixed in 4.1.0 or not.
 
 
  On Tue, Jul 30, 2013 at 11:01 AM, John Neiberger jneiber...@gmail.com
 wrote:
 
  W
  e're running into an interesting problem. We have a simple lab setup
 like
  this:
 
  CE1 -- PE1 --- P1 --- P2 --- PE2 --- CE2
 
  We have mpls ip-ttl-propagate disable on all PE and P routers, but
 if we
  trace from CE1 to CE2, we still see an MPLS label coming from the PE2
  router. If we trace CE2 to CE1, we see a label on the hop from P1 to
 PE1.
 
  If we have ttl propagation completely disabled, why would we still see
 the
  label and P-to-PE link in the path?
 
  All P and PE routers are IOS XR running 4.1.0.
 
  Thanks,
  John
 
  ___
  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] Label still appearing in traceroute after disabling ttl propagation

[John Neiberger]

I guess I should rephrase. We have configured mpls ip-ttl-propagate
disable to try to hide the labeled part of the path. For whatever reason,
we always get something like the following:
CE1#trace 10.6.10.1 source lo0
Type escape sequence to abort.
Tracing the route to 10.6.10.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.105.50 0 msec 0 msec 0 msec
  2 192.168.62.2 [MPLS: Label 16018 Exp 0] 4 msec 0 msec 0 msec
  3 192.168.62.60 0 msec 0 msec 0 msec
  4 192.168.106.61 4 msec *  0 msec
CE1#
If I trace from CE1 to the loopback of PE2, which is the same path, it
works as expected and the labeled part of the path is hidden:

CE5#trace 10.6.1.1 source lo0
Type escape sequence to abort.
Tracing the route to 10.6.1.1
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.105.50 4 msec 0 msec 0 msec
  2 192.168.62.60 0 msec *  0 msec


On Tue, Jul 30, 2013 at 11:43 AM, Jared Mauch ja...@puck.nether.net wrote:

 Disable TTL != don't copy label into ICMP TTL Expired message.

 - Jared

 On Jul 30, 2013, at 1:37 PM, John Neiberger jneiber...@gmail.com wrote:

  I think either we're just doing something wrong or perhaps we're running
  into a bug. I did find this one, which sounds similar:
 
  https://tools.cisco.com/bugsearch/bug/CSCtd17126
 
  I'm not sure if that is fixed in 4.1.0 or not.
 
 
  On Tue, Jul 30, 2013 at 11:01 AM, John Neiberger jneiber...@gmail.com
 wrote:
 
  W
  e're running into an interesting problem. We have a simple lab setup
 like
  this:
 
  CE1 -- PE1 --- P1 --- P2 --- PE2 --- CE2
 
  We have mpls ip-ttl-propagate disable on all PE and P routers, but if
 we
  trace from CE1 to CE2, we still see an MPLS label coming from the PE2
  router. If we trace CE2 to CE1, we see a label on the hop from P1 to
 PE1.
 
  If we have ttl propagation completely disabled, why would we still see
 the
  label and P-to-PE link in the path?
 
  All P and PE routers are IOS XR running 4.1.0.
 
  Thanks,
  John
 
  ___
  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] Label still appearing in traceroute after disabling ttl propagation

[John Neiberger]

For the record, someone had applied some LDP label filtering for testing,
which caused one of the P routers not to have labels for a set of prefixes
and allowed the original IP traceroute packet to be exposed within the core
before it reached the PE router. Once we removed the filtering, all was
well.


On Tue, Jul 30, 2013 at 12:28 PM, John Neiberger jneiber...@gmail.comwrote:

 After a little more investigation, I think the problem is that our P2
 router is not learning a set of prefixes via LDP that it should be, so it
 is sending them unlabeled to PE2. We assumed that both P routers had the
 right labels, but that doesn't appear to be the case.


 On Tue, Jul 30, 2013 at 12:20 PM, John Neiberger jneiber...@gmail.comwrote:

 I guess I should rephrase. We have configured mpls ip-ttl-propagate
 disable to try to hide the labeled part of the path. For whatever reason,
 we always get something like the following:
 CE1#trace 10.6.10.1 source lo0
 Type escape sequence to abort.
 Tracing the route to 10.6.10.1
 VRF info: (vrf in name/id, vrf out name/id)
   1 192.168.105.50 0 msec 0 msec 0 msec
   2 192.168.62.2 [MPLS: Label 16018 Exp 0] 4 msec 0 msec 0 msec
   3 192.168.62.60 0 msec 0 msec 0 msec
   4 192.168.106.61 4 msec *  0 msec
 CE1#
 If I trace from CE1 to the loopback of PE2, which is the same path, it
 works as expected and the labeled part of the path is hidden:

 CE5#trace 10.6.1.1 source lo0
 Type escape sequence to abort.
 Tracing the route to 10.6.1.1
 VRF info: (vrf in name/id, vrf out name/id)
   1 192.168.105.50 4 msec 0 msec 0 msec
   2 192.168.62.60 0 msec *  0 msec


 On Tue, Jul 30, 2013 at 11:43 AM, Jared Mauch ja...@puck.nether.netwrote:

 Disable TTL != don't copy label into ICMP TTL Expired message.

 - Jared

 On Jul 30, 2013, at 1:37 PM, John Neiberger jneiber...@gmail.com
 wrote:

  I think either we're just doing something wrong or perhaps we're
 running
  into a bug. I did find this one, which sounds similar:
 
  https://tools.cisco.com/bugsearch/bug/CSCtd17126
 
  I'm not sure if that is fixed in 4.1.0 or not.
 
 
  On Tue, Jul 30, 2013 at 11:01 AM, John Neiberger jneiber...@gmail.com
 wrote:
 
  W
  e're running into an interesting problem. We have a simple lab setup
 like
  this:
 
  CE1 -- PE1 --- P1 --- P2 --- PE2 --- CE2
 
  We have mpls ip-ttl-propagate disable on all PE and P routers, but
 if we
  trace from CE1 to CE2, we still see an MPLS label coming from the PE2
  router. If we trace CE2 to CE1, we see a label on the hop from P1 to
 PE1.
 
  If we have ttl propagation completely disabled, why would we still
 see the
  label and P-to-PE link in the path?
 
  All P and PE routers are IOS XR running 4.1.0.
 
  Thanks,
  John
 
  ___
  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] multicast issue

[John Neiberger]

Yep, same here. Lots of multicast video with IQ probes all over the place.
I really like them. They've saved my neck many times during overnight
maintenance. It's nice to know for sure what is happening around the
network as you make your changes.


On Tue, Jul 16, 2013 at 8:51 PM, jean-francois.d...@videotron.com wrote:

 We use IneoQuest gear to monitor multicast data after it leaves the source
 and before it enters the destination.

 The boxes give nice reports of both IP and MPEG, and are MDI compliant
 (RFC4445)


 Cheers,

 JF

 cisco-nsp cisco-nsp-boun...@puck.nether.net a écrit sur 2013-07-16
 12:53:23 :

  De : R S dim0...@hotmail.com
  A : cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net,
  Date : 2013-07-16 12:59
  Objet : [c-nsp] multicast issue
  Envoyé par : cisco-nsp cisco-nsp-boun...@puck.nether.net
 
  Hi all
 
  Just a brainstorming and your possible help.
 
 
  I manage a network where multicast is the most important traffic and
  sometimes I get issue by customer where they state that some packetsare
 lost…
 
 
  Does anybody have an idea or can help me in understanding a possible
  solution in monitoring traffic in real time manner, maybe with the use of
 some
  software or appliance or whatelse.
 
  In my idea I could monitor traffic on the source and on the destination,
  then with  a sort of parsing understand
  if it’s my network loosing the packets or not…
 
 
 
  Any idea ? suggestion ?
 
 
  tks
  ___
  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] multicast issue

[John Neiberger]

I
neoQuest is just for video applications.


On Tue, Jul 16, 2013 at 9:12 PM, dim0sal dim0...@hotmail.com wrote:

 Hi all
 Thanks.

 But is this IQ used only for multicast video or also for other mcast
 applications like financial applications?

 Sorry but I don t know IneoQuest.

 Tks



 Sent with Mobile


  Messaggio originale 
 Da: John Neiberger jneiber...@gmail.com
 Data:
 A: jean-francois.d...@videotron.com
 Cc: james lavespa dim0...@hotmail.com,cisco-nsp 
 cisco-nsp-boun...@puck.nether.net,cisco-nsp@puck.nether.net
 Oggetto: Re: [c-nsp] multicast issue


 Yep, same here. Lots of multicast video with IQ probes all over the place.
 I really like them. They've saved my neck many times during overnight
 maintenance. It's nice to know for sure what is happening around the
 network as you make your changes.


 On Tue, Jul 16, 2013 at 8:51 PM, jean-francois.d...@videotron.com wrote:

 We use IneoQuest gear to monitor multicast data after it leaves the source
 and before it enters the destination.

 The boxes give nice reports of both IP and MPEG, and are MDI compliant
 (RFC4445)


 Cheers,

 JF

 cisco-nsp cisco-nsp-boun...@puck.nether.net a écrit sur 2013-07-16
 12:53:23 :

  De : R S dim0...@hotmail.com
  A : cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net,
  Date : 2013-07-16 12:59
  Objet : [c-nsp] multicast issue
  Envoyé par : cisco-nsp cisco-nsp-boun...@puck.nether.net
 
  Hi all
 
  Just a brainstorming and your possible help.
 
 
  I manage a network where multicast is the most important traffic and
  sometimes I get issue by customer where they state that some packetsare
 lost…
 
 
  Does anybody have an idea or can help me in understanding a possible
  solution in monitoring traffic in real time manner, maybe with the use
 of
 some
  software or appliance or whatelse.
 
  In my idea I could monitor traffic on the source and on the destination,
  then with  a sort of parsing understand
  if it’s my network loosing the packets or not…
 
 
 
  Any idea ? suggestion ?
 
 
  tks
  ___
  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/

[c-nsp] Finding source of ISIS authentication failure

[John Neiberger]

This one has me and TAC stumped. Let's say you have a 7600 with multiple
devices connected to it running ISIS. One of them has the wrong
authentication key, so you see a bunch of this in the logs:

%CLNS-4-AUTH_FAIL: ISIS: LSP authentication failed

How do you find out what neighbor is causing that? We have not found any
show command or debug command, either ISIS or CLNS, that would show us the
source of the problem. This is very easy in OSPF, but it's starting to look
pretty dang hard to do with ISIS.

Does anyone know what ninja commands or procedure I need to find the source
of ISIS authentication failures from the router CLI?

Thanks,
John
___
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] Finding source of ISIS authentication failure

[John Neiberger]

We've tried pretty much every relevant isis and clns debug and haven't
found one that works. It's pretty strange. I wonder if this is just a quirk
of the code we're running.


On Mon, Jul 1, 2013 at 10:31 AM, Aaron dudep...@gmail.com wrote:

 debug isis
 possibly add lsp at the end


 On Mon, Jul 1, 2013 at 11:41 AM, John Neiberger jneiber...@gmail.comwrote:

 This one has me and TAC stumped. Let's say you have a 7600 with multiple
 devices connected to it running ISIS. One of them has the wrong
 authentication key, so you see a bunch of this in the logs:

 %CLNS-4-AUTH_FAIL: ISIS: LSP authentication failed

 How do you find out what neighbor is causing that? We have not found any
 show command or debug command, either ISIS or CLNS, that would show us the
 source of the problem. This is very easy in OSPF, but it's starting to
 look
 pretty dang hard to do with ISIS.

 Does anyone know what ninja commands or procedure I need to find the
 source
 of ISIS authentication failures from the router CLI?

 Thanks,
 John
 ___
 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] Finding source of ISIS authentication failure

[John Neiberger]

This box is running 12.2(33)SRC code. The TAC engineer and I haven't really
found a good way to find what we're looking for. I have found some debugs
that confirm that we're having an authentication problem but they also
don't show the source of the problem. Not even an interface.


On Mon, Jul 1, 2013 at 10:17 AM, Alan Buxey a.l.m.bu...@lboro.ac.uk wrote:

  Hi

  Odd.  Unless the 7600 is missing a whole load of things then you
 shouldn't have any issues running the standard debug commands for ISIS...I
 certainly did to find source of an issue onour 6500. This was on SXI
 release of 12.2(18) or such.. we're on 15.x now

  alan

___
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] Finding source of ISIS authentication failure

[John Neiberger]

Yep, that's the one we were looking for. I don't know how we missed it
before. I tried it now and it gave us the info I was looking for. I know I
tried it before, but I think maybe I had it enabled along with other debug
commands and just missed it in the flood of info. It's easy to spot when
you only have that one enabled.

Thanks!
John


On Mon, Jul 1, 2013 at 11:38 AM, Thomas Sillaber tlis...@t-online.dewrote:

 Hi,

 have you tried debug isis update-packets? Works on SRC2:

 000484: Jul  1 19:27:57.428: ISIS-Upd (proc): Rec L2 LSP ID, seq 1D, ht
 65171,
 000485: Jul  1 19:27:57.428: ISIS-Upd (proc): from SNPA ID
 (GigabitEthernet2/0/0)
 000486: Jul  1 19:27:57.428: %CLNS-4-AUTH_FAIL: ISIS: LSP authentication
 failed
 000487: Jul  1 19:27:57.428: ISIS-Upd (proc): LSP authentication failed

 br

 Thomas

 -Ursprüngliche Nachricht-
 Von: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] Im Auftrag von
 John Neiberger
 Gesendet: Montag, 1. Juli 2013 18:31
 An: Alan Buxey
 Cc: cisco-nsp@puck.nether.net
 Betreff: Re: [c-nsp] Finding source of ISIS authentication failure

 This box is running 12.2(33)SRC code. The TAC engineer and I haven't really
 found a good way to find what we're looking for. I have found some debugs
 that confirm that we're having an authentication problem but they also
 don't
 show the source of the problem. Not even an interface.


 On Mon, Jul 1, 2013 at 10:17 AM, Alan Buxey a.l.m.bu...@lboro.ac.uk
 wrote:

   Hi
 
   Odd.  Unless the 7600 is missing a whole load of things then you
  shouldn't have any issues running the standard debug commands for
  ISIS...I certainly did to find source of an issue onour 6500. This was
  on SXI release of 12.2(18) or such.. we're on 15.x now
 
   alan
 
 ___
 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] Finding source of ISIS authentication failure

[John Neiberger]

Thanks!

On a related note, I'm stumped by the bewildering array of authentication
options and commands in 12.2. We know that some authentication problem
exists between this 7600 and another device but I don't know exactly what
it is.

We have the following on our interfaces:

isis authentication mode md5
isis authentication key-chain OurChain

It is my understanding that in IOS, this enables hello authentication only.
Not sure if that is even remotely correct.

We have the same thing under router isis:

router isis
 authentication mode md5
 authentication key-chain OurChain

I thought that this enabled area authentication in IOS, but I'm reading a
12.2 ISIS configuration guide that seems to indicate otherwise. So, I'm
confused. What exactly are we authenticating as currently configured? We do
not have an explicit area password or domain password set. It was my
assumption that the current config was doing hello and area authentication,
but the more I read, the more I realize that I don't know what IOS is doing
here.

Thanks!
John



On Mon, Jul 1, 2013 at 12:07 PM, daniel@reaper.nu wrote:



 As pointed out to me by Ytti I was doing interface authentication
 and you are doing LSP autentication. I changed my lab and got the
 following debug from debug isis update-packets:

 ISIS-Upd: Rec L1 LSP
 ..0002.00-00, seq 4, ht 1199,
 ISIS-Upd: from SNPA c201.22dc.
 (FastEthernet0/0)
 %CLNS-4-AUTH_FAIL: ISIS: LSP authentication failed


 So there you have the system ID which was 000..0002 for my NET
 which was 49.0001...0002

 This URL seems to explain it pretty
 well:



 http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080093f36.shtml#tshoot
 [3]

 Best regards,

 Daniel Dib

 CCIE #37149

 2013-07-01 19:33 skrev
 daniel@reaper.nu:

  When testing on 12.4 code I get the following
 from debug isis
  adj-packets and debug isis authentication information:

 
  ISIS-Adj: Rec
  L2 IIH from c201.0d84. (FastEthernet0/0), cir
 type L1L2, cir id
  ..0002.01, length 1497
  ISIS-AuthInfo:
 Packet failed the md5
  check, 1497 bytes, type 16
  ISIS-Adj:
 Authentication failed
 
  So the MAC
  address and interface is
 recorded. Don't you have these debugs or do
  your debugs not show this
 information?
 
  Best regards,
 
  Daniel Dib
 
  CCIE #37149
 
 
 2013-07-01 18:31 skrev John Neiberger:
 
  This box is
 
  running
 12.2(33)SRC code. The TAC engineer and I haven't really
 
  found
 
 
 a good way to find what we're looking for. I have found some debugsthat
 confirm that we're having an authentication problem but they alsodon't
 show the source of the problem. Not even an interface.




 Links:
 --
 [1] http://puck.nether.net/pipermail/cisco-nsp/
 [2]
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 [3]

 http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080093f36.shtml#tshoot
 ___
 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] Weird IPv6 problem passing Layer3 traffic

[John Neiberger]

Do you have CoPP configured? I've seen this exact behavior when I didn't
have a permit statement for my neighbor or link address in the right ACL,
so it was getting rate-limited to death.


On Fri, Jun 28, 2013 at 8:33 AM, Matthew Huff mh...@ox.com wrote:

 Trying to bring up a new BGP peering session with a ISP. IPv4 peering is
 working fine on the same interface. The BGP peering fails early in trying
 to go active. Using debug tcp transactions, I see the SYN going out, but
 no ACK ever returning. I can't telnet to their box on port 179 either
 (debug packet shows it doing the same, SYN begin sent, but no packets,
 including ACK). However, I can ping their interface.

 The interface config has been stripped, and still doesn't work. I've reset
 the interface, and even rebooted our router, with no change in behavior.

 We have a Cisco 7204VXR with NPE-G2, running 15.2(4)S1. I have an
 identical router with same version connected to another ISP and a tunnel to
 HE.net. It's not my first time at the rodeo. We are connected via metro
 Ethernet to a sub-interface on a JunOS box (model and version unknown). My
 suspicion is that either they have an ACL that's blocking it, or their BGP
 process isn't listening on that sub-interface. But they claim that it isn't
 their problem. I have zero JunOS experience and they seem to be flopping
 around.

 Anyone have any idea what else the problem might be?

 From our side (simplied config to test):


 interface FastEthernet2/1
  ip address 162.211.110.2 255.255.255.252
  speed auto
  duplex auto
  ipv6 address 2607:F518:15F::2/126
  ipv6 enable
 end

 rtr-inet2#show ipv6 cef 2607:F518:15F::1
 2607:F518:15F::1/128
   attached to FastEthernet2/1

 rtr-inet2#show ipv6 cef exact-route 2607:F518:15F::2 2607:F518:15F::1
 2607:F518:15F::2 - 2607:F518:15F::1 = IPV6 adj out of FastEthernet2/1,
 addr 2607:F518:15F::1

 rtr-inet2#show ipv6 neighbors
 IPv6 Address  Age Link-layer Addr State
 Interface
 2607:F518:15F::10 0021.5903.1367  REACH Fa2/1

 rtr-inet2#ping  2607:F518:15F::1
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2607:F518:15F::1, timeout is 2 seconds:
 !
 Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

 
 Matthew Huff | 1 Manhattanville Rd
 Director of Operations   | Purchase, NY 10577
 OTA Management LLC   | Phone: 914-460-4039


 ___
 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] Weird IPv6 problem passing Layer3 traffic

[John Neiberger]

I wonder if they have something similar to CoPP configured on their side. I
only have a little Juniper experience, but I think they may have a routing
engine filter inbound on their router (applied to their loopback interface)
that may be limiting this traffic. It's worth checking into. It's easy to
miss since they're probably looking at the BGP and interface configs. They
might not even be thinking about the RE filter. Hopefully someone with more
Juniper experience will come along and straighten me out if I'm wrong.

John


On Fri, Jun 28, 2013 at 8:59 AM, Matthew Huff mh...@ox.com wrote:

 No, I don’t have any CoPP defined (at least at the moment trying to debug
 it). No ACLs or anything else like that. The ISP keeps wanting me to send
 them my BGP configuration (which I’ve sent to at least 3 different people),
 rarther than looking at the obvious that BGP won’t ever come up if we
 can’t get a TCP session established.

 ** **

 

 Matthew Huff | 1 Manhattanville Rd

 Director of Operations   | Purchase, NY 10577

 OTA Management LLC   | Phone: 914-460-4039

 ** **

 *From:* John Neiberger [mailto:jneiber...@gmail.com]
 *Sent:* Friday, June 28, 2013 10:56 AM
 *To:* Matthew Huff
 *Cc:* cisco-nsp (cisco-nsp@puck.nether.net); ipv6-...@lists.cluenet.de
 *Subject:* Re: [c-nsp] Weird IPv6 problem passing Layer3 traffic

 ** **

 Do you have CoPP configured? I've seen this exact behavior when I didn't
 have a permit statement for my neighbor or link address in the right ACL,
 so it was getting rate-limited to death.

 ** **

 On Fri, Jun 28, 2013 at 8:33 AM, Matthew Huff mh...@ox.com wrote:

 Trying to bring up a new BGP peering session with a ISP. IPv4 peering is
 working fine on the same interface. The BGP peering fails early in trying
 to go active. Using debug tcp transactions, I see the SYN going out, but
 no ACK ever returning. I can't telnet to their box on port 179 either
 (debug packet shows it doing the same, SYN begin sent, but no packets,
 including ACK). However, I can ping their interface.

 The interface config has been stripped, and still doesn't work. I've reset
 the interface, and even rebooted our router, with no change in behavior.

 We have a Cisco 7204VXR with NPE-G2, running 15.2(4)S1. I have an
 identical router with same version connected to another ISP and a tunnel to
 HE.net. It's not my first time at the rodeo. We are connected via metro
 Ethernet to a sub-interface on a JunOS box (model and version unknown). My
 suspicion is that either they have an ACL that's blocking it, or their BGP
 process isn't listening on that sub-interface. But they claim that it isn't
 their problem. I have zero JunOS experience and they seem to be flopping
 around.

 Anyone have any idea what else the problem might be?

 From our side (simplied config to test):


 interface FastEthernet2/1
  ip address 162.211.110.2 255.255.255.252
  speed auto
  duplex auto
  ipv6 address 2607:F518:15F::2/126
  ipv6 enable
 end

 rtr-inet2#show ipv6 cef 2607:F518:15F::1
 2607:F518:15F::1/128
   attached to FastEthernet2/1

 rtr-inet2#show ipv6 cef exact-route 2607:F518:15F::2 2607:F518:15F::1
 2607:F518:15F::2 - 2607:F518:15F::1 = IPV6 adj out of FastEthernet2/1,
 addr 2607:F518:15F::1

 rtr-inet2#show ipv6 neighbors
 IPv6 Address  Age Link-layer Addr State
 Interface
 2607:F518:15F::10 0021.5903.1367  REACH Fa2/1

 rtr-inet2#ping  2607:F518:15F::1
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2607:F518:15F::1, timeout is 2 seconds:
 !
 Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

 
 Matthew Huff | 1 Manhattanville Rd
 Director of Operations   | Purchase, NY 10577
 OTA Management LLC   | Phone: 914-460-4039


 ___
 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] RESOLVED: Weird IPv6 problem passing Layer3 traffic

[John Neiberger]

Sweet! I've had CoPP filters bite me many times. Everything else will look
right but the dang thing just won't work. It can be pretty frustrating to
troubleshoot since CoPP usually isn't the first thing people think of.

John


On Fri, Jun 28, 2013 at 9:20 AM, Matthew Huff mh...@ox.com wrote:

 The issue was a CoPP filter on the ISP side. The session is up now.

 Been working on them with them for 3 days, and each engineer kept coming
 back to our BGP configuration.

 
 Matthew Huff | 1 Manhattanville Rd
 Director of Operations   | Purchase, NY 10577
 OTA Management LLC   | Phone: 914-460-4039


  -Original Message-
  From: Matthew Huff
  Sent: Friday, June 28, 2013 10:34 AM
  To: 'cisco-nsp (cisco-nsp@puck.nether.net)'; 'ipv6-...@lists.cluenet.de'
  Subject: Weird IPv6 problem passing Layer3 traffic
 
  Trying to bring up a new BGP peering session with a ISP. IPv4 peering is
 working fine on the same
  interface. The BGP peering fails early in trying to go active. Using
 debug tcp transactions, I see
  the SYN going out, but no ACK ever returning. I can't telnet to their
 box on port 179 either (debug
  packet shows it doing the same, SYN begin sent, but no packets,
 including ACK). However, I can ping
  their interface.
 
  The interface config has been stripped, and still doesn't work. I've
 reset the interface, and even
  rebooted our router, with no change in behavior.
 
  We have a Cisco 7204VXR with NPE-G2, running 15.2(4)S1. I have an
 identical router with same version
  connected to another ISP and a tunnel to HE.net. It's not my first time
 at the rodeo. We are connected
  via metro Ethernet to a sub-interface on a JunOS box (model and version
 unknown). My suspicion is that
  either they have an ACL that's blocking it, or their BGP process isn't
 listening on that sub-
  interface. But they claim that it isn't their problem. I have zero JunOS
 experience and they seem to
  be flopping around.
 
  Anyone have any idea what else the problem might be?
 
  From our side (simplied config to test):
 
 
  interface FastEthernet2/1
   ip address 162.211.110.2 255.255.255.252
   speed auto
   duplex auto
   ipv6 address 2607:F518:15F::2/126
   ipv6 enable
  end
 
  rtr-inet2#show ipv6 cef 2607:F518:15F::1
  2607:F518:15F::1/128
attached to FastEthernet2/1
 
  rtr-inet2#show ipv6 cef exact-route 2607:F518:15F::2 2607:F518:15F::1
  2607:F518:15F::2 - 2607:F518:15F::1 = IPV6 adj out of FastEthernet2/1,
 addr 2607:F518:15F::1
 
  rtr-inet2#show ipv6 neighbors
  IPv6 Address  Age Link-layer Addr State
 Interface
  2607:F518:15F::10 0021.5903.1367  REACH Fa2/1
 
  rtr-inet2#ping  2607:F518:15F::1
  Type escape sequence to abort.
  Sending 5, 100-byte ICMP Echos to 2607:F518:15F::1, timeout is 2 seconds:
  !
  Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
 
  
  Matthew Huff | 1 Manhattanville Rd
  Director of Operations   | Purchase, NY 10577
  OTA Management LLC   | Phone: 914-460-4039


 ___
 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] sh mfib route rate

[John Neiberger]

I'm not at a router right now, so I can't check this, but do you you get
better (or different) results if you do show mfib hardware route
statistics instead? That doesn't show rate information, but it seems to
update very quickly as I recall.

John


On Wed, Jun 26, 2013 at 3:07 AM, Adam Vitkovsky adam.vitkov...@swan.skwrote:

 Hi Folks,

 Is there a knob (may be hidden) to speed up the refresh interval of sh
 mfib
 route rate output please?

 The inactive streams seem to be hanging in there for at least 10 minutes or
 so which is always annoying during troubleshooting.



 adam





 ___
 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] BGP Cease notifications with Graceful Restart

[John Neiberger]

That's an excellent point. The 7600 in our scenario does not have dual RPs.
The Cisco BU is involved, so I will mention this to them.

Thanks!
John


On Wed, May 22, 2013 at 12:24 AM, Mikael Abrahamsson swm...@swm.pp.sewrote:

 On Tue, 21 May 2013, John Neiberger wrote:

  the 7600, which the CRS immediately recognized, but the CRS continued to
 use those BGP routes until the neighbor's graceful restart timer expired.


 It's my experience that Cisco has a GR implemention that leaves some to be
 desired on a lot of platforms. I have escalated this several times to no
 avail.

 A 7600 will advertise itself as GR capable even if there is a single RP,
 and the BU didn't feel the need to implmement bgp graceful-restart
 helper-only even after several requests.

 So in our network, 7600 have no graceful restart configured. Please talk
 to your account team and ask them to talk to the BU and get them to fix
 this.

 Desired behaviour:

 On a dual RP system, advertise yourself as GR capable.
 On a single RP system, only do GR helper.

 Either auto detect this or make it configurable.

 --
 Mikael Abrahamssonemail: swm...@swm.pp.se

___
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] BGP Cease notifications with Graceful Restart

[John Neiberger]

We ran into an interesting issue recently and I'm not sure what to think of
it. We have a 7600 and a CRS peering via eBGP. The session was shutdown on
the 7600, which the CRS immediately recognized, but the CRS continued to
use those BGP routes until the neighbor's graceful restart timer expired.
The default for that timer is 120 seconds. RFC 4724 says that if a neighbor
notifies a peer that it is restarting, routes learned from the restarting
router should be marked as stale, but they must not be treated differently
than other routes in the BGP table. That makes sense if the router receives
a notification that the peer is restarting, but why does that make any
sense at all if it receives a notification that the session as been
administratively shutdown?

I contend that it makes more sense to immediately purge those routes from
the BGP table instead of continuing to use them until the restart timer
expires. This seems to be how the 7600 behaves if we shut the session down
from the CRS. But if we shut the session down from the 7600, the CRS does
not purge the routes for two minutes.

What are your thoughts on this? What sort of behavior should we be
expecting?

Thanks,
John
___
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] PIM convergence problem

[John Neiberger]

We ran into an interesting problem last night and I'm a little stumped. It
appears that PIM did not follow a unicast routing change after a BGP peer
was shutdown. Imagine this simple topology:

[A] - [B] -- [C] ---  [D]
 |
 |
 |
 [D]

Router A is a CRS and is forwarding PIM joins toward Router D, which is
directly attached. We are not running an IGP here. There is only an eBGP
session between two ASes that we manage. We shutdown the BGP session
between A and D, which caused unicast traffic to switch to the path toward
Router B. However, it looks like Router A did not tear down the PIM joins
that are now no longer valid. It seems that it was still joining a lot of
traffic that it could no longer do anything with since it would now fail
RPF checks.

We didn't get snapshots during the event, so I can't prove that is what
happened, but it is the only thing we've found that makes any sense. We've
had quite a few engineers looking at it and we do have TAC on the case, but
I thought I'd check here, as well.

Have any of you seen a situation where PIM joins stay up even when they
shouldn't? Is there possibly an issue with an interaction between PIM and
BGP? I've never seen this sort of behavior before, so I'm not quite sure
what to think.

Thanks,
John
___
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] Monday morning brain teaser

[John Neiberger]

This is one of the strangest things I've ever seen. We have an ASR9K
(Router A) connected to a 7600 (Router B) via simple L3 link with no ACLs.
We can ping from Router A to Router B, and we can ping from Router A to a
different L3 interface on Router B. However, we cannot trace from Router A
to that other L3 interface on Router B. That alone is weird because this is
simple routing and no ACLs. That's enough of a brain teaser. However, it
gets worse.

We have a network management station that is polling these routers. While
the traceroute is running (and failing), the NMS can't poll the ASR9K and
starts to report it as down. The NMS is polling the loopback address of the
router. As soon as we stop the trace, the NMS starts getting replies from
Router A again.

So, two brain teasers:

1. Why would trace fail where ping succeeds? There are no ACLs, so this
really stumps me. We do not have CoPP configured.

2. While the trace is failing, why would our NMS stop getting replies from
the ASR9K?

I honestly don't know what to think about this. I don't think I've ever
seen anything like it.

Any thoughts?
___
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] Monday morning brain teaser

[John Neiberger]

I've verified that we have no policy maps or route maps in place. The
interfaces in question are plain L3 interfaces with barely more than an IP
address configured. I'm not nearly awake enough to deal with this sort of
weird behavior.  :)


On Mon, Apr 1, 2013 at 9:39 AM, Rick Coloccia coloc...@geneseo.edu wrote:

 On 4/1/2013 11:36 AM, John Neiberger wrote:

 I honestly don't know what to think about this. I don't think I've ever
 seen anything like it.

 I didn't have an ACL in the way, but I did have a policy route map in
 place, which was a little too aggressive, one upon a time. Similar
 symptoms.  May be something to look at...

 --
 Rick Coloccia, Jr.
 Network Manager
 State University of NY College at Geneseo
 1 College Circle, 119 South Hall
 Geneseo, NY 14454
 V: 585-245-5577
 F: 585-245-5579


___
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] Monday morning brain teaser

[John Neiberger]

It should be sourced from the directly connected interface. I see nothing
in the config that would cause it to be sourced from something else.
However, this led to try a test that turned up something else really weird.
If I ping the destination normally from Router A, the ping begins
immediately. But if I ping the destination and source it from Router A's
loopback0 interface, the ping waits about 7-8 seconds before it sends the
pings. The RTT is the same, but there is always a 7-8 second pause after I
hit enter if I source the pings from Loopback0. WTH? Something is very
funky on this router.


On Mon, Apr 1, 2013 at 10:10 AM, Harold 'Buz' Dale buz.d...@usg.edu wrote:

 Is your traceroute sourced from a different IP?

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net [mailto:
 cisco-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
 Sent: Monday, April 01, 2013 11:43
 To: Rick Coloccia
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Monday morning brain teaser

 I've verified that we have no policy maps or route maps in place. The
 interfaces in question are plain L3 interfaces with barely more than an IP
 address configured. I'm not nearly awake enough to deal with this sort of
 weird behavior.  :)


 On Mon, Apr 1, 2013 at 9:39 AM, Rick Coloccia coloc...@geneseo.edu
 wrote:

  On 4/1/2013 11:36 AM, John Neiberger wrote:
 
  I honestly don't know what to think about this. I don't think I've
  ever seen anything like it.
 
  I didn't have an ACL in the way, but I did have a policy route map in
  place, which was a little too aggressive, one upon a time. Similar
  symptoms.  May be something to look at...
 
  --
  Rick Coloccia, Jr.
  Network Manager
  State University of NY College at Geneseo
  1 College Circle, 119 South Hall
  Geneseo, NY 14454
  V: 585-245-5577
  F: 585-245-5579
 
 
 ___
 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] Monday morning brain teaser

[John Neiberger]

That was my initial thought, but we do not have CoPP configured.


On Mon, Apr 1, 2013 at 10:15 AM, Manuel 5k7k6rk...@snkmail.com wrote:

 CoPP related perhaps...

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net [mailto:
 cisco-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
 jneiberger-at-gmail.com |puck.nether.net nsp nph|
 Sent: Monday, April 01, 2013 9:43 AM
 To: Manuel Berrocal (mberroca); Rick Coloccia
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Monday morning brain teaser

 I've verified that we have no policy maps or route maps in place. The
 interfaces in question are plain L3 interfaces with barely more than an IP
 address configured. I'm not nearly awake enough to deal with this sort of
 weird behavior.  :)


 On Mon, Apr 1, 2013 at 9:39 AM, Rick Coloccia coloc...@geneseo.edu
 wrote:

  On 4/1/2013 11:36 AM, John Neiberger wrote:
 
  I honestly don't know what to think about this. I don't think I've
  ever seen anything like it.
 
  I didn't have an ACL in the way, but I did have a policy route map in
  place, which was a little too aggressive, one upon a time. Similar
  symptoms.  May be something to look at...
 
  --
  Rick Coloccia, Jr.
  Network Manager
  State University of NY College at Geneseo
  1 College Circle, 119 South Hall
  Geneseo, NY 14454
  V: 585-245-5577
  F: 585-245-5579
 
 
 ___
 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] Monday morning brain teaser

[John Neiberger]

I'm leaning toward some sort of bug. I've expanded my testing and see that
any time I trace to something that is not replying, ICMP polls to the ASR9K
fail. As soon as I kill the failing trace, polling is immediately
successful.


On Mon, Apr 1, 2013 at 10:29 AM, John Neiberger jneiber...@gmail.comwrote:

 It should be sourced from the directly connected interface. I see nothing
 in the config that would cause it to be sourced from something else.
 However, this led to try a test that turned up something else really weird.
 If I ping the destination normally from Router A, the ping begins
 immediately. But if I ping the destination and source it from Router A's
 loopback0 interface, the ping waits about 7-8 seconds before it sends the
 pings. The RTT is the same, but there is always a 7-8 second pause after I
 hit enter if I source the pings from Loopback0. WTH? Something is very
 funky on this router.


 On Mon, Apr 1, 2013 at 10:10 AM, Harold 'Buz' Dale buz.d...@usg.eduwrote:

 Is your traceroute sourced from a different IP?

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net [mailto:
 cisco-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
 Sent: Monday, April 01, 2013 11:43
 To: Rick Coloccia
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Monday morning brain teaser

 I've verified that we have no policy maps or route maps in place. The
 interfaces in question are plain L3 interfaces with barely more than an IP
 address configured. I'm not nearly awake enough to deal with this sort of
 weird behavior.  :)


 On Mon, Apr 1, 2013 at 9:39 AM, Rick Coloccia coloc...@geneseo.edu
 wrote:

  On 4/1/2013 11:36 AM, John Neiberger wrote:
 
  I honestly don't know what to think about this. I don't think I've
  ever seen anything like it.
 
  I didn't have an ACL in the way, but I did have a policy route map in
  place, which was a little too aggressive, one upon a time. Similar
  symptoms.  May be something to look at...
 
  --
  Rick Coloccia, Jr.
  Network Manager
  State University of NY College at Geneseo
  1 College Circle, 119 South Hall
  Geneseo, NY 14454
  V: 585-245-5577
  F: 585-245-5579
 
 
 ___
 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] Monday morning brain teaser

[John Neiberger]

This has been confirmed as a known bug. I can't believe I haven't run into
it before. We're running this same code on several routers and I've never
noticed it. I guess that's yet another reason to upgrade.  :)


On Mon, Apr 1, 2013 at 10:39 AM, John Neiberger jneiber...@gmail.comwrote:

 I'm leaning toward some sort of bug. I've expanded my testing and see that
 any time I trace to something that is not replying, ICMP polls to the ASR9K
 fail. As soon as I kill the failing trace, polling is immediately
 successful.


 On Mon, Apr 1, 2013 at 10:29 AM, John Neiberger jneiber...@gmail.comwrote:

 It should be sourced from the directly connected interface. I see nothing
 in the config that would cause it to be sourced from something else.
 However, this led to try a test that turned up something else really weird.
 If I ping the destination normally from Router A, the ping begins
 immediately. But if I ping the destination and source it from Router A's
 loopback0 interface, the ping waits about 7-8 seconds before it sends the
 pings. The RTT is the same, but there is always a 7-8 second pause after I
 hit enter if I source the pings from Loopback0. WTH? Something is very
 funky on this router.


 On Mon, Apr 1, 2013 at 10:10 AM, Harold 'Buz' Dale buz.d...@usg.eduwrote:

 Is your traceroute sourced from a different IP?

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net [mailto:
 cisco-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
 Sent: Monday, April 01, 2013 11:43
 To: Rick Coloccia
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] Monday morning brain teaser

 I've verified that we have no policy maps or route maps in place. The
 interfaces in question are plain L3 interfaces with barely more than an IP
 address configured. I'm not nearly awake enough to deal with this sort of
 weird behavior.  :)


 On Mon, Apr 1, 2013 at 9:39 AM, Rick Coloccia coloc...@geneseo.edu
 wrote:

  On 4/1/2013 11:36 AM, John Neiberger wrote:
 
  I honestly don't know what to think about this. I don't think I've
  ever seen anything like it.
 
  I didn't have an ACL in the way, but I did have a policy route map in
  place, which was a little too aggressive, one upon a time. Similar
  symptoms.  May be something to look at...
 
  --
  Rick Coloccia, Jr.
  Network Manager
  State University of NY College at Geneseo
  1 College Circle, 119 South Hall
  Geneseo, NY 14454
  V: 585-245-5577
  F: 585-245-5579
 
 
 ___
 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] Monday morning brain teaser

[John Neiberger]

On Mon, Apr 1, 2013 at 12:42 PM, Jeff Aitken jait...@aitken.com wrote:

 On Mon, Apr 01, 2013 at 10:45:29AM -0600, John Neiberger wrote:
  This has been confirmed as a known bug. I can't believe I haven't run
 into
  it before. We're running this same code on several routers and I've never
  noticed it. I guess that's yet another reason to upgrade.  :)

 Out of curiosity which code are you running that has this bug (and can you
 share the BugID)?

 Thanks,


 --Jeff


Sure. This particular router is running old code, 4.0.1. The bug ID is
CSCtk36798.

John
___
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] BGP neighbor fall-over vs BFD

[John Neiberger]

I was just reading a bit about next-hop tracking and neighbor fall-over and
now I'm a little confused about what fall-over actually does. The docs say
that it enables fast peering session deactivation, but I can't tell what
that really means. The wording in the docs makes it sound a lot like BFD,
but not exactly. In fact, fall-over can be used with BFD.

Can someone shed some light on this? What is fall-over really doing and
when might it be useful?

Thanks,
John
___
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] BGP neighbor fall-over vs BFD

[John Neiberger]

On Mon, Mar 11, 2013 at 11:12 AM, Oliver Boehmer (oboehmer) 
oboeh...@cisco.com wrote:


 
 Can someone shed some light on this? What is fall-over really doing and
 when might it be useful?


 sorry for the confusion ;-)   neighbor fall-over (without the BFD keyword)
 is for multihop/non-directly-connected peers like the default behaviour
 fast-external-fallover for directly connected neighbours: the session will
 be torn down. It works by monitoring/tracking the next-hop address, so if
 something removes the route to the peer, the session will be torn down. It
 works pretty much the same way as Next-hop-Tracking (monitoring the RIB),
 but it tears down the session (while NHT only declares the nexthop as
 invalid).

 fall-over bfd isn't monitoring the RIB, it uses BFD to monitor neighbour
 reachability  liveliness, and it will tear down the session if BFD
 signals a failure.

 So fall-over is actually much more than a single feature.. did I apologize
 for the confusion? ;-)

 oli


In the case I'm thinking of using it, we do all over our internal BGP
peering to loopbacks, which are in OSPF. If we enable fallover, it sounds
like the peer will be torn down as soon as that next hop is removed from
the routing table. One problem we have that I'm trying to solve is that we
also have a null0 static route used for aggregation for the loopback
addresses. This static route stops the BGP routes from being invalidated
until the peer goes down because the next hop is technically still
reachable, although via Null0. I'm pondering the use of selective next-hop
filtering so that only /32 routes in OSPF can be used to validate next
hops, but I wonder if just enabling fallover would be better option. We
aren't using BFD right now. Not sure why. It seems like using fallover with
BFD would be an excellent solution to this problem.

Thanks!
John
___
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] BGP neighbor fall-over vs BFD

[John Neiberger]

On Mon, Mar 11, 2013 at 11:29 AM, Bruce Pinsky b...@whack.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 John Neiberger wrote:

  In the case I'm thinking of using it, we do all over our internal BGP
  peering to loopbacks, which are in OSPF. If we enable fallover, it sounds
  like the peer will be torn down as soon as that next hop is removed from
  the routing table. One problem we have that I'm trying to solve is that
 we
  also have a null0 static route used for aggregation for the loopback
  addresses. This static route stops the BGP routes from being invalidated
  until the peer goes down because the next hop is technically still
  reachable, although via Null0. I'm pondering the use of selective
 next-hop
  filtering so that only /32 routes in OSPF can be used to validate next
  hops, but I wonder if just enabling fallover would be better option. We
  aren't using BFD right now. Not sure why. It seems like using fallover
 with
  BFD would be an excellent solution to this problem.
 

 As I mentioned, there is no dampening mechanism on fast fall-over and peers
 are dropped immediately when the next hop is lost.  If the next-hop of the
 routing entries is the same as the peering address, then next-hop tracking
 should be sufficient to cause the routes to flush from the RIB if
 reachability is lost and next-hop tracking has a delay/dampening mechanism
 built in.


Ah, yes. That makes sense. I was planning on doing selective next-hop
filtering but while I was researching it I ran across fast fall-over, so I
thought I'd better check into it. I think I like the idea of having a
little bit of a delay built in. It sounds like this would be a better
option for what we're trying to do.

Thanks,
John
___
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] IOS XR and router rib rump always-replicate

[John Neiberger]

Thanks, Oliver! That explains exactly what we were seeing. We doing have a
multicast AF enabled in our IGP on the affected routers, so now I
understand why we needed the additional replication commands.

Thanks again,
John


On Fri, Mar 1, 2013 at 5:06 AM, Oliver Boehmer (oboehmer) 
oboeh...@cisco.com wrote:



 On 01/03/2013 10:58, Mikael Abrahamsson swm...@swm.pp.se wrote:

 On Fri, 1 Mar 2013, Christian Meutes wrote:
 
  On 01.03.2013, at 10:01, Mikael Abrahamsson swm...@swm.pp.se wrote:
 
  On Fri, 1 Mar 2013, Christian Meutes
  Do you have your sources addresses in IGP?
 
  Nope, BGP SAFI unicast.
 
 Well, your experience contradicts mine. I have had to solve issues with
 multicast not working and started working when the sources were put in
 SAFI multicast with as late software as XR 4.2.1.
 
 I'll defer to someone more knowledgable to explain how this really works.

 Once you enable the mcast AF in your IGP or BGP, IOS-XR will populate the
 muRIB, and PIM will use this one for RPF (before it used the unicast
 RIB/uRIB). This requires that all sources will be in the muRIB. This is
 different from IOS where RPF would fall back to the unicast RIB, as
 Michael described.

 The rump always-replicate command will replicate uRIB to muRIB, so we
 effectively achieve the IOS behaviour.

 oli


 ___
 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/

[c-nsp] IOS XR and router rib rump always-replicate

[John Neiberger]

I ran into an issue today that I hadn't seen before. I was helping someone
troubleshoot some multicast problems where everything seemed to be correct
but the joins weren't working. I was totally stumped until someone noticed
the following:

router rib
 address-family ipv4 unicast
  rump always-replicate MULTICAST_ROUTES

There is an ACL called MULTICAST_ROUTES that matches prefixes that we want
to be available as multicast sources. I've never seen this before, so I'm
wondering what exactly it does. I read the command reference and it wasn't
exactly clear.

It seems that it is filtering what unicast routes are available as
potential RPF neighbors. If a PIM join arrives and there is no valid RPF
neighbor, it seems to just get dropped. The RPF entry for prefixes not in
the ACL look like this:

RP/0/RP0/CPU0:router#   show pim rpf 1.2.3.4
Fri Mar  1 05:28:33.026 utc

Table: IPv4-Multicast-default
* 1.2.3.4/32 [4294967295/4294967295]
via Null with rpf neighbor 0.0.0.0


Entries for prefixes that are in the access list look like you would expect
and those PIM joins succeed. So what exactly does rump always-replicate
do? Am I right that it's basically only allowing the prefixes in the ACL to
be used for multicast RPF?


Thanks,

John
___
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] OSPF OOB Resync and peer stuck in EXSTART (SeqNumberMismatch)

[John Neiberger]

It's a new-ish Checkpoint firewall, but I have no idea what code it is
running. I was sent a snippet of their logs and I see a lot of the
following:

OSPF LSA: different instance of lsa on retranmission list received: type
RTR
OSPF LSA: different instance of lsa on retranmission list received: type
NTW

I verified the the firewall *is* setting the LR-bit indicating that it is
capable of OOB Resync. The RFC says that if the LR-bit is set in the hello
messages, DBD packets should have the R-bit set during an OOB Resync. If
those DBD packets do not have the R-bit set, the receiving device is
supposed to drop them and log a sequence number mismatch. I suspect that is
what happened here. It looks like something is causing their database to
become unsynchronized and the firewall triggers an OOB Resync but then
doesn't set the R-bit in the DBD packets. I'm not exactly sure, though.
That's just what I'm thinking, so far.


On Sat, Feb 9, 2013 at 3:25 AM, Phil Mayers p.may...@imperial.ac.uk wrote:

 On 02/09/2013 05:05 AM, John Neiberger wrote:

  1. What triggered the OOB resync in the first place?


 I assume there is nothing in the logs for the device, or adjacent devices,
 at the time?


  2. If the firewall isn't capable of doing OOB resync, why would it send
 DBD
 packets with the R-bit set? (Perhaps it is capable and just wasn't
 previously setting the LR-bit in hello messages)


 You didn't specify the model of the firewall and it's software version, so
 it's difficult to say.

 __**_
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at 
 http://puck.nether.net/**pipermail/cisco-nsp/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] OSPF OOB Resync and peer stuck in EXSTART (SeqNumberMismatch)

[John Neiberger]

Here's another interesting tidbit I found while researching this
synchronization problem:

--
When the OSPF in a router restarts, neighbors with adjacencies to the
restarting router learn about the OSPF restart. How does a neighboring
router find out about the OSPF restart? A neighbor detects the restart
event on an adjacency when the associated hold timer expires, or when it
receives a Hello packet containing incomplete information. For example, the
Hello does not mention the receiving router in the neighbor list.

When neighbors learn about the OSPF restart, they cycle their adjacencies
to the restarting router through the down state. To keep the LSDB
synchronized, a change in adjacency state (up to down) forces the
neighboring routers to advertise new LSAs. The complete reliable flooding
and installation of these LSAs in the LSDB will force the SPF to run in the
entire area or routing domain.

In the original OSPF specification, the main objective of this protocol
behavior was reducing the possibility of incorrect forwarding by routing
around the restarting router while its database is being resynchronized.
This OSPF protocol behavior is necessary in the case of a restarting router
that is incapable of preserving its FIB across the restart. This inability
is due to the fact that if traffic is allowed to pass through such a
restarting router, there is an increased likelihood of incorrect forwarding
because of an incomplete database and the FIB. Therefore, to reduce the
possibility of incorrect forwarding, such as routing loops and black holes,
OSPF deliberately routes around the restarting router.
--


The adjacency between our router and the firewall never times out, so it
doesn't appear that we have communication problems. Something is just
triggering a resychronization of the LSDB. I believe this corresponds with
the first log message the router sees:

Feb  8 23:32:45.777 UTC: %OSPF-5-ADJCHG: Process 65300, Nbr 1.2.3.4 on
Vlan7 from FULL to EXSTART, OOB-Resynchronization Feb

The OSPF spec says that if a neighbor starts sending Hello packets that do
not list the receiving router as a neighbor, the receiving router should
change the state of that relationship to DOWN. However, since both the
firewall and the router are advertising that they're capable of OOB Resync,
maybe the router puts it into EXSTART state instead. Subsequent messages
from the firewall apparently (this is assumption) do not have the R-bit
set, which is why the router logs a sequence number mismatch and then
ignores the packets.

If the above is correct then it seems that something is causing the
firewall to restart OSPF, or at least behave in a way that makes the router
think it is restarting. It's really difficult to tell. I'd never even heard
of OOB Resync until last night, so much of this is new to me.


On Sat, Feb 9, 2013 at 8:26 AM, John Neiberger jneiber...@gmail.com wrote:

 It's a new-ish Checkpoint firewall, but I have no idea what code it is
 running. I was sent a snippet of their logs and I see a lot of the
 following:

 OSPF LSA: different instance of lsa on retranmission list received: type
 RTR
 OSPF LSA: different instance of lsa on retranmission list received: type
 NTW

 I verified the the firewall *is* setting the LR-bit indicating that it is
 capable of OOB Resync. The RFC says that if the LR-bit is set in the hello
 messages, DBD packets should have the R-bit set during an OOB Resync. If
 those DBD packets do not have the R-bit set, the receiving device is
 supposed to drop them and log a sequence number mismatch. I suspect that is
 what happened here. It looks like something is causing their database to
 become unsynchronized and the firewall triggers an OOB Resync but then
 doesn't set the R-bit in the DBD packets. I'm not exactly sure, though.
 That's just what I'm thinking, so far.


 On Sat, Feb 9, 2013 at 3:25 AM, Phil Mayers p.may...@imperial.ac.ukwrote:

 On 02/09/2013 05:05 AM, John Neiberger wrote:

  1. What triggered the OOB resync in the first place?


 I assume there is nothing in the logs for the device, or adjacent
 devices, at the time?


  2. If the firewall isn't capable of doing OOB resync, why would it send
 DBD
 packets with the R-bit set? (Perhaps it is capable and just wasn't
 previously setting the LR-bit in hello messages)


 You didn't specify the model of the firewall and it's software version,
 so it's difficult to say.

 __**_
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at 
 http://puck.nether.net/**pipermail/cisco-nsp/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/

[c-nsp] OSPF OOB Resync and peer stuck in EXSTART (SeqNumberMismatch)

[John Neiberger]

This is a new one on me. We had a situation where OSPF between a router and
a firewall seemed to go insane and it involves something I've never heard
of before: Out of band Resync. Here are the logs from the beginning of the
event:

Feb  8 23:32:45.777 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from FULL to EXSTART, OOB-Resynchronization
Feb  8 23:32:50.777 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from EXSTART to EXCHANGE, Negotiation Done
Feb  8 23:34:49.830 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions
Feb  8 23:35:49.830 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from DOWN to DOWN, Neighbor Down: Ignore timer expired
Feb  8 23:35:50.790 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from DOWN to INIT, Received Hello
Feb  8 23:35:50.790 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from INIT to 2WAY, 2-Way Received
Feb  8 23:35:50.790 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from 2WAY to EXSTART, AdjOK?
Feb  8 23:35:50.810 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from EXSTART to EXSTART, SeqNumberMismatch
Feb  8 23:36:00.814 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from EXSTART to EXSTART, SeqNumberMismatch
Feb  8 23:36:10.814 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from EXSTART to EXSTART, SeqNumberMismatch
Feb  8 23:36:25.814 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from EXSTART to EXSTART, SeqNumberMismatch
Feb  8 23:36:30.818 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
from EXSTART to EXSTART, SeqNumberMismatch

Something happens to trigger an out-of-band resync and then the neighbor
gets stuck in EXSTART because of a sequence number mismatch. I first
thought we had an MTU mismatch, but the MTUs seem to check out. I read
somewhere that sequence number mismatches can be caused by a software
error. This just isn't something I've run into before.

First, I don't know what OOB Resynchronization is or what all it entails,
so I'm going to read some more about that to find out what triggers it and
what it is supposed to be doing under the hood. Second, why would a peer
that had been working just fine suddenly divebomb into the ground and then
get stuck in exstart?

We ultimately resolved the problem by clearing the OSPF process a couple of
times. Eventually all seemed to clear up and things are working fine. I
suspect a buggy OSPF implementation on the firewall but that's really just
a guess. The router is running 12.2(33)SRE3 code, which I think has a
pretty mature OSPF code.

Any thoughts?

Thanks,
John
___
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] OSPF OOB Resync and peer stuck in EXSTART (SeqNumberMismatch)

[John Neiberger]

I think I may have found a clue in the informational RFC for OOB Resync:

When a DBD packet is received with the R-bit set and the sender is
   known to be OOB-incapable, the packet should be dropped and a
   SeqNumber-Mismatch event should be generated for the neighbor.


My router must have received a DBD from the firewall with the R-bit set,
which means the neighbor is participating in OOB resync; however, if the
router did not previously recognize the firewall as being capable of OOB
Resync, it will drop the packet and log a sequence number mismatch.

That may explain part of what we were seeing. Several questions now remain:

1. What triggered the OOB resync in the first place?
2. If the firewall isn't capable of doing OOB resync, why would it send DBD
packets with the R-bit set? (Perhaps it is capable and just wasn't
previously setting the LR-bit in hello messages)

John


On Fri, Feb 8, 2013 at 9:28 PM, John Neiberger jneiber...@gmail.com wrote:

 This is a new one on me. We had a situation where OSPF between a router
 and a firewall seemed to go insane and it involves something I've never
 heard of before: Out of band Resync. Here are the logs from the beginning
 of the event:

 Feb  8 23:32:45.777 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from FULL to EXSTART, OOB-Resynchronization
 Feb  8 23:32:50.777 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from EXSTART to EXCHANGE, Negotiation Done
 Feb  8 23:34:49.830 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions
 Feb  8 23:35:49.830 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from DOWN to DOWN, Neighbor Down: Ignore timer expired
 Feb  8 23:35:50.790 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from DOWN to INIT, Received Hello
 Feb  8 23:35:50.790 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from INIT to 2WAY, 2-Way Received
 Feb  8 23:35:50.790 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from 2WAY to EXSTART, AdjOK?
 Feb  8 23:35:50.810 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from EXSTART to EXSTART, SeqNumberMismatch
 Feb  8 23:36:00.814 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from EXSTART to EXSTART, SeqNumberMismatch
 Feb  8 23:36:10.814 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from EXSTART to EXSTART, SeqNumberMismatch
 Feb  8 23:36:25.814 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from EXSTART to EXSTART, SeqNumberMismatch
 Feb  8 23:36:30.818 UTC: %OSPF-5-ADJCHG: Process 100, Nbr 1.2.3.4 on Vlan7
 from EXSTART to EXSTART, SeqNumberMismatch

 Something happens to trigger an out-of-band resync and then the neighbor
 gets stuck in EXSTART because of a sequence number mismatch. I first
 thought we had an MTU mismatch, but the MTUs seem to check out. I read
 somewhere that sequence number mismatches can be caused by a software
 error. This just isn't something I've run into before.

 First, I don't know what OOB Resynchronization is or what all it entails,
 so I'm going to read some more about that to find out what triggers it and
 what it is supposed to be doing under the hood. Second, why would a peer
 that had been working just fine suddenly divebomb into the ground and then
 get stuck in exstart?

 We ultimately resolved the problem by clearing the OSPF process a couple
 of times. Eventually all seemed to clear up and things are working fine. I
 suspect a buggy OSPF implementation on the firewall but that's really just
 a guess. The router is running 12.2(33)SRE3 code, which I think has a
 pretty mature OSPF code.

 Any thoughts?

 Thanks,
 John

___
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] MPLS VPN over mGRE

[John Neiberger]

I bet you're right. I should keep digging for some Cisco Live presentation
or something. I was hoping someone from Cisco would respond and explain the
magic fairy dust in this configuration. As you said, it must be that the
inbound route-map also causes the neighbors to use SAFI 64 in outbound
updates. The docs I've seen so far don't say how it happens, they just
said, And in this step, magic happens or something similar.  :)

John


On Thu, Jan 31, 2013 at 1:02 AM, Adam Vitkovsky adam.vitkov...@swan.skwrote:

 Aah I see, so it’s got to be the route-map than, mapping the particular
 neighbor with a profile –causing the neighbors to negotiate safi 64
 support. 

 You could try issuing  “sh ip b vpnv4 a nei x.x.x.x” to see whether safi
 64 has indeed been negotiated between the peers. 

 ** **

 I bet the insides are explained in some cisco presentation. 

 ** **

 adam

 ** **

 *From:* John Neiberger [mailto:jneiber...@gmail.com]
 *Sent:* Wednesday, January 30, 2013 6:16 PM
 *To:* David Prall
 *Cc:* Adam Vitkovsky; cisco-nsp@puck.nether.net

 *Subject:* Re: [c-nsp] MPLS VPN over mGRE

 ** **

 That's exactly right. The part I can't figure out is what triggers the
 proper signalling. The BGP config for outbound vpnv4 updates looks like
 standard L3VPN. I'm trying to understand what causes it to send the tunnel
 information in the NLRI. I believe it is using SAFI 64. What causes it to
 use SAFI 64 instead of 128, which is what would normally be used for MPLS
 VPNs?

 ** **

 That's the part that's baking my noodle. I'm just not sure how it's
 working under the hood.

 ** **

 John

 ** **

 On Wed, Jan 30, 2013 at 9:15 AM, David Prall d...@dcptech.com wrote:

 Sounds like you are using BGP Signaled MPLS VPN over mGRE which uses a
 Route-Map on the neighbor relationship to provide the tunnel information.

 http://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/xe-3s/ir
 -mpls-vpnomgre-xe.htmlhttp://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/xe-3s/ir-mpls-vpnomgre-xe.html

 David

 --
 http://dcp.dcptech.com



  -Original Message-
  From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
  boun...@puck.nether.net] On Behalf Of John Neiberger
  Sent: Wednesday, January 30, 2013 10:55 AM
  To: Adam Vitkovsky
  Cc: cisco-nsp@puck.nether.net
  Subject: Re: [c-nsp] MPLS VPN over mGRE
 

  The type of MPLS VPN over mGRE that we're using doesn't use a
  preconfigured
  tunnel interface or NHRP. As I understand it, the peers share
  tunnel-related information in vpnv4 updates using a SAFI of 64. This
 tells
  the other peers that those prefixes are related to the mgre tunnel and
 that
  signals the receiving router to set up an adjacency over the multipoint
  tunnel, but I'm not quite sure how it does this. I don't understand what
  element of the config tells the router to use SAFI 64 in the vpnv4
 updates
  instead of just treating them like regular L3VPN vpnv4 updates. It's kind
  of confusing. There seems to be a lot of magic happening under the hood
  here that I'm missing.
 
  John
 
 
  On Wed, Jan 30, 2013 at 1:15 AM, Adam Vitkovsky
  adam.vitkov...@swan.skwrote:
 
   Wow they really shrunk it down to three commands plus the route-map,
  now
   that's something.
  
or is there some other mechanism that triggers tunnel endpoint
  discovery?
   I believe since it's called mGRE it has to be NHRP taking care of
   everything
   in the background.
   Does the loopback IP has to be allocated from a common range that has
 to
  be
   shared among the PEs?
  
   I thought it's done via standard mGRE tunnels:
  
   interface Tunnel0
   ip address 192.168.1.1 255.255.255.0
   ip mtu 1440
   ip nhrp authentication cisco123
   ip nhrp map multicast dynamic
   ip nhrp network-id 1
   tunnel source FastEthernet0/0
   tunnel mode gre multipoint
   tunnel key 0
   ip router isis 1
  
   -maybe mpls ip cmd. wouldn't work with mGRE Tunnel Int.
  
  
   adam
  
  

  ___
  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] MPLS VPN over mGRE

[John Neiberger]

The type of MPLS VPN over mGRE that we're using doesn't use a preconfigured
tunnel interface or NHRP. As I understand it, the peers share
tunnel-related information in vpnv4 updates using a SAFI of 64. This tells
the other peers that those prefixes are related to the mgre tunnel and that
signals the receiving router to set up an adjacency over the multipoint
tunnel, but I'm not quite sure how it does this. I don't understand what
element of the config tells the router to use SAFI 64 in the vpnv4 updates
instead of just treating them like regular L3VPN vpnv4 updates. It's kind
of confusing. There seems to be a lot of magic happening under the hood
here that I'm missing.

John


On Wed, Jan 30, 2013 at 1:15 AM, Adam Vitkovsky adam.vitkov...@swan.skwrote:

 Wow they really shrunk it down to three commands plus the route-map, now
 that's something.

  or is there some other mechanism that triggers tunnel endpoint discovery?
 I believe since it's called mGRE it has to be NHRP taking care of
 everything
 in the background.
 Does the loopback IP has to be allocated from a common range that has to be
 shared among the PEs?

 I thought it's done via standard mGRE tunnels:

 interface Tunnel0
 ip address 192.168.1.1 255.255.255.0
 ip mtu 1440
 ip nhrp authentication cisco123
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 0
 ip router isis 1

 -maybe mpls ip cmd. wouldn't work with mGRE Tunnel Int.


 adam


___
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] MPLS VPN over mGRE

[John Neiberger]

That's exactly right. The part I can't figure out is what triggers the
proper signalling. The BGP config for outbound vpnv4 updates looks like
standard L3VPN. I'm trying to understand what causes it to send the tunnel
information in the NLRI. I believe it is using SAFI 64. What causes it to
use SAFI 64 instead of 128, which is what would normally be used for MPLS
VPNs?

That's the part that's baking my noodle. I'm just not sure how it's working
under the hood.

John


On Wed, Jan 30, 2013 at 9:15 AM, David Prall d...@dcptech.com wrote:

 Sounds like you are using BGP Signaled MPLS VPN over mGRE which uses a
 Route-Map on the neighbor relationship to provide the tunnel information.

 http://www.cisco.com/en/US/docs/ios-xml/ios/interface/configuration/xe-3s/ir
 -mpls-vpnomgre-xe.html

 David

 --
 http://dcp.dcptech.com


  -Original Message-
  From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
  boun...@puck.nether.net] On Behalf Of John Neiberger
  Sent: Wednesday, January 30, 2013 10:55 AM
  To: Adam Vitkovsky
  Cc: cisco-nsp@puck.nether.net
  Subject: Re: [c-nsp] MPLS VPN over mGRE
 
  The type of MPLS VPN over mGRE that we're using doesn't use a
  preconfigured
  tunnel interface or NHRP. As I understand it, the peers share
  tunnel-related information in vpnv4 updates using a SAFI of 64. This
 tells
  the other peers that those prefixes are related to the mgre tunnel and
 that
  signals the receiving router to set up an adjacency over the multipoint
  tunnel, but I'm not quite sure how it does this. I don't understand what
  element of the config tells the router to use SAFI 64 in the vpnv4
 updates
  instead of just treating them like regular L3VPN vpnv4 updates. It's kind
  of confusing. There seems to be a lot of magic happening under the hood
  here that I'm missing.
 
  John
 
 
  On Wed, Jan 30, 2013 at 1:15 AM, Adam Vitkovsky
  adam.vitkov...@swan.skwrote:
 
   Wow they really shrunk it down to three commands plus the route-map,
  now
   that's something.
  
or is there some other mechanism that triggers tunnel endpoint
  discovery?
   I believe since it's called mGRE it has to be NHRP taking care of
   everything
   in the background.
   Does the loopback IP has to be allocated from a common range that has
 to
  be
   shared among the PEs?
  
   I thought it's done via standard mGRE tunnels:
  
   interface Tunnel0
   ip address 192.168.1.1 255.255.255.0
   ip mtu 1440
   ip nhrp authentication cisco123
   ip nhrp map multicast dynamic
   ip nhrp network-id 1
   tunnel source FastEthernet0/0
   tunnel mode gre multipoint
   tunnel key 0
   ip router isis 1
  
   -maybe mpls ip cmd. wouldn't work with mGRE Tunnel Int.
  
  
   adam
  
  
  ___
  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/

[c-nsp] MPLS VPN over mGRE

[John Neiberger]

I was reading through the configuration guide for MPLS VPN over mGRE to try
to reverse engineer a configuration we have at work. This kind of hurts my
head, but I think I've almost got it. The method we use is basically the
same as this:

http://www.cisco.com/en/US/docs/ios/interface/configuration/guide/ir_mplsvpnomgre.html

The config basically consists of:

* VRF with RD and import/export RTs
* l3vpn encapsulation method using GRE as the protocol
* VPNv4 peer relationships between all endpoints needing access to this VPN
* An ingress route policy on the VPNv4 peers that set the ip next-hop
encapsulation to the l3vpn encapsulation method configured earlier

That seems to be about it. The thing I don't yet understand is what starts
the endpoint discovery process. I read somewhere that VPNv4 prefixes
related to tunnels use a SAFI of 64, so when a peer receives those prefixes
it would know that the sender wants to participate in the multipoint GRE
VPN. If that's the case, what is it about the configuration that would
cause the router to use that SAFI in the VPNv4 updates?

I see nothing in the VRF or BGP config that specifically would cause it to
behave any different. Why wouldn't it send regular VPNv4 routes? Other than
the ingress route policy that associates incoming routes to the mGRE, I
don't see what would cause the router to set the SAFI to 64 on advertised
routes.

Is that even how this works, or is there some other mechanism that triggers
tunnel endpoint discovery?

Thanks!
John
___
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] Confirmation of Gigabit Ethernet autonegotiation behavior

[John Neiberger]

A few of us at work have been discussing autonegotiation in gigabit
Ethernet networks and I wanted to get a clarification. I know that on Cisco
devices with Fast Ethernet, if you manually set speed and duplex, this
disables Nway autonegotiation completely. However, I don't think that is
the case for gigabit links since the autonegotiation process is so much
more important. I believe that it still participates in autonegotiation but
only offers the configured speed and duplex setting in the negotiation
process.

Can anyone shed some light on this? I've tried searching CCO for a while
and haven't found the information I'm looking for.

Thanks,
John
___
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] Rationale for ISIS default origination behavior

[John Neiberger]

We have static routes on the ASBRs that point to the loopback of the eBGP
peer, then we redistribute those statics into ISIS. If a peer loopback goes
away, the network converges pretty quickly to the other available
connections.

But thinking about that, it once again makes me wonder why we are
redistributing the default into ISIS. If the default already exists in iBGP
and the next-hop is in ISIS, that's going to converge pretty quickly. I'll
have to think about this some more. There's probably some obvious factor
that I'm overlooking.



On Tue, Jan 22, 2013 at 1:09 AM, Adam Vitkovsky adam.vitkov...@swan.skwrote:

  However, we also configure the routers with eBGP peers to originate
 defaults into the IGP, presumably for faster convergence, although given
 the
 design I really don't know that convergence will be that much faster.


 So than you must also be using the bgp nexthop route-map or nexthop
 route-policy in order to control what routes are valid for iBGP next-hops
 right?
 Cause if the /32 route for some peer's loopback/iBGP next-hop disappears
 form ISIS I guess you don't want to follow default route to get to that
 peer


 adam


___
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] Rationale for ISIS default origination behavior

[John Neiberger]

In the part of the network I'm thinking of, we do use iBGP, so the peers
all learn the default in BGP. However, we also configure the routers with
eBGP peers to originate defaults into the IGP, presumably for faster
convergence, although given the design I really don't know that convergence
will be that much faster.  ISIS carries loopbacks, internal links, and a
default. It's single area, all L2, and we have default-info originate in
ISIS. Everything else is in iBGP. I'll have to ponder that design decision
a bit more. It seems that we'd get fewer complications if we didn't
originate a default into ISIS and just let iBGP deal with it.

Conditional advertisement is a recent choice by our design engineers to
solve this problem, but it seems like it shouldn't be necessary if ISIS
were implemented more like OSPF. OSPF won't originate a default if it is
learning an external OSPF default from another router. This is far more
sensible. ISIS does not seem to make that distinction. As long as it has a
default in the RIB, no matter what the source, it will generate its own
default into the area.

Thanks!
John


On Mon, Jan 21, 2013 at 12:11 PM, David Freedman 
david.freed...@uk.clara.net wrote:

 I've been discussing this with some other engineers at work and no one has
 any idea why Cisco would implement it this way.

 I doubt many people make use of an IS-IS default (as I'm sure the L1/ATT
 behaviour is also seen as an annoyance in modern IP networks), many
 networks I've seen running IS-IS and BGP tend to do all their routing in
 the iBGP and keep IS-IS for pure infrastructure prefixes (loopbacks and
 sometimes transfer networks).

 In your scenario, the default can be brought from your external peers into
 your iBGP, this would seem quite sensible since you would be avoiding
 redistribution and/or conditional default advertisement (which you can
 achieve with IS-IS through the use of route-maps).

 Dave.





 ___
 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/

[c-nsp] Rationale for ISIS default origination behavior

[John Neiberger]

This is sort of a follow-up to a question I had a few weeks ago about how
to configure conditional default origination in IOS XR. It seems that ISIS
default origination in both IOS and IOS XR behaves in a pretty suboptimal
way. I don't have a lot of history with IS-IS, so I'm curious about this.

Take this topology as an example:

[E1]-[RA]--[RB]-[RC]--[RD]--[E2]

RA, RB, RC and RD are running ISIS. E1 and E2 are external BGP peers to RA
and RD. E1 and E2 are advertising a default. If you want to get the default
into ISIS, we can configure default-information originate on RA and RD.
This seems to work as expected.

Now, imagine that RD loses its link to E2. It loses the external BGP
default in the RIB and now only has a default route in ISIS that it learned
via RC. RD will start sending all traffic to RC, but RC will send all
traffic back to RD because that is the nearest default route.

It makes absolutely no sense for RD to use the ISIS default in its RIB to
originate a default, but both IOS and IOS XR will happily do just that. In
order to stop this insane behavior, you have to configure conditional
default advertisement.

OSPF does not behave in this way. If we were using OSPF, RD would not use
the OSPF default in its RIB to generate yet another default, so the routing
loop between RC and RD would never form.

Is this behavior something specific to Cisco's implementation of IS-IS, or
is there something in the standard that would suggest this behavior? It
seems like an odd choice. You certainly would not recommend to OSPF users
that they go around configuring default-information originate always all
the time, so why make that essentially the behavior in IS-IS?

Wouldn't it be more sensible to adopt the behavior of default origination
in OSPF for IS-IS, at least when doing it by using the default-information
originate command?

I've been discussing this with some other engineers at work and no one has
any idea why Cisco would implement it this way.

Thanks,
John
___
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] show command for active multicast kbps rate

[John Neiberger]

I do recall opening a TAC case on something like this about a year ago. We
also were not seeing rates in our multicast traffic. As I recall, they said
it was a bug, but I don't have any details. I'll see if I can find the case
notes. We were running 4.0.1 at the time.


On Fri, Jan 11, 2013 at 12:03 PM, Aaron aar...@gvtc.com wrote:

 I think I enabled that too on my asr9k's and recall not seeing any rates
 either.  Wondering if there is a known issue with this.  Anyone know
 anything about that ?

 Aaron

 -Original Message-
 From: cisco-nsp-boun...@puck.nether.net [mailto:
 cisco-nsp-boun...@puck.nether.net] On Behalf Of Erçin TORUN
 Sent: Friday, January 11, 2013 12:07 PM
 To: Adam Vitkovsky
 Cc: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] show command for active multicast kbps rate

 Hi again,

 I've enabled the rate-per-route command but still cant see the per flow
 rates. Have any idea ? I'm sure that there is a flow cause i'm watching it
 and it passes throughout the backbone.


 #show mfib route 233.88.168.176 detail


 IP Multicast Forwarding Information Base Entry flags: C -
 Directly-Connected Check, S - Signal, D - Drop,
   IA - Inherit Accept, IF - Inherit From, MA - MDT Address,
   ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,
   MH - MDT interface handle, CD - Conditional Decap,
   DT - MDT Decap True, EX - Extranet
   MoFE - MoFRR Enabled, MoFS - MoFRR State Interface flags: F - Forward, A
 - Accept, IC - Internal Copy,
   NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
   EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,
   EX - Extranet, A2 - Secondary Accept
 Forwarding/Replication Counts: Packets in/Packets out/Bytes out Failure
 Counts: RPF / TTL / Empty Olist / Encap RL / Other

 (x.x.x.x,233.88.168.176),   Flags:
   Up: 00:02:02
   Last Used: never
   SW Forwarding Counts: 0/0/0
   SW Replication Counts: 0/0/0
   SW Failure Counts: 0/0/0/0/0
   Route ver: 0x2f34
   MVPN Info :-
 MDT Handle: 0x0, MDT Probe:N [N], Rate:Y, Acc:N
 MDT SW Ingress Encap V4/V6, Egress decap: 0 / 0, 0
 Encap ID: 0 RPF ID: 0
 Local Receiver: True Turnaround: False
   TenGigE0/0/0/0 Flags:  NS, Up:00:02:02
   GigabitEthernet0/1/0/4.112 Flags:  A, Up:00:02:02

 #show mrib route 233.88.168.176 detail


 IP Multicast Routing Information Base
 Entry flags: L - Domain-Local Source, E - External Source to the Domain,
 C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
 IF - Inherit From, D - Drop, MA - MDT Address, ME - MDT Encap,
 MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
 CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX -
 Extranet
 MoFE - MoFRR Enabled, MoFS - MoFRR State Interface flags: F - Forward,
 A - Accept, IC - Internal Copy,
 NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
 II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
 LD - Local Disinterest, DI - Decapsulation Interface
 EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
 EX - Extranet, A2 - Secondary Accept

 (x.x.x.x ,233.88.168.176) Ver: 0x2f34 RPF nbr: x.x.x.x Flags:, FMA:
 0x501bfba0 FGID: 0x4 MGID: 0x9a2c
   Up: 00:02:19
   Incoming Interface List
 GigabitEthernet0/1/0/4.112 Flags: A, Up: 00:02:19
   Outgoing Interface List
 TenGigE0/0/0/0 Flags: F NS, Up: 00:02:19

 # show ip route x.x.x.x
 Fri Jan 11 20:00:24.076 Turkiye

 Routing entry for x.x.x.x/28
   Known via connected, distance 0, metric 0 (connected)
   Installed Dec 20 00:12:02.128 for 3w1d
   Routing Descriptor Blocks
 directly connected, via GigabitEthernet0/1/0/4.112
   Route metric is 0
   Redist Advertisers:
 ospf 1

  nsf
   multipath hash source-nexthop
   ssm range abcde
   rate-per-route
   ssm allow-override


 2013/1/8 Erçin TORUN ercinto...@gmail.com

  Hi Adam,
 
  Thanks for quick response. I used the sh mrib route before but
  without rate-per-route config, will check asap.
 
  2013/1/8 Adam Vitkovsky adam.vitkov...@swan.sk
 
  In XR its sh mrib route/sh mfib route but in order to get the bw rate
  you have to have the following cmd enabled:
 
  multicast-routing
   rate-per-route
 
  adam
 
 
 
 
  --
  ERCIN TORUN




 --
 ERCIN TORUN
 ___
 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/

[c-nsp] IOS XR and IS-IS default origination

[John Neiberger]

I've noticed that in IOS XR, if you have default-information originate
configured in ISIS, it will behave similar to default-information
originate always in OSPF. It will advertise a default whether or not it
has learned one from an external source. I thought this was a bug, but now
I'm starting to wonder if this is expected behavior.

I also see that a route policy could be added to conditionally advertise a
default. If ISIS in XR always originates a default when that command is
configured, what would a route policy look like that would only allow a
default to be advertised if it was learned via eBGP? I'd swear I've done
something similar in IOS before, but it's been a while.

Any thoughts?

Thanks,
John
___
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] IOS XR and IS-IS default origination

[John Neiberger]

Ah, Nevermind. I found it. You configure a route policy that matches on if
rib-has-route and you specify the next-hop you're looking for. In my case,
that will work just fine.


On Wed, Jan 9, 2013 at 3:25 PM, John Neiberger jneiber...@gmail.com wrote:

 I've noticed that in IOS XR, if you have default-information originate
 configured in ISIS, it will behave similar to default-information
 originate always in OSPF. It will advertise a default whether or not it
 has learned one from an external source. I thought this was a bug, but now
 I'm starting to wonder if this is expected behavior.

 I also see that a route policy could be added to conditionally advertise a
 default. If ISIS in XR always originates a default when that command is
 configured, what would a route policy look like that would only allow a
 default to be advertised if it was learned via eBGP? I'd swear I've done
 something similar in IOS before, but it's been a while.

 Any thoughts?

 Thanks,
 John

___
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] IOS XR mtu changes and OSPF

[John Neiberger]

I just noticed something that I thought was interesting. In IOS, at least
on the platform and image I tested, changing an interface MTU after an OSPF
adjacency is full will not affect the adjacency. So, if you need to change
a link MTU after OSPF is up and running, it should not affect routing.

However, XR seems to behave differently. I just changed the MTU on some
links on a router running IOS XR and it caused a routing flap. Why would
OSPF flap due to an MTU change that occurs after the adjacency is up? Is
this something specific to XR or am I just confused?  :-)
___
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] ASR9k: BGP state = Idle (No route to multi-hop neighbor)

[John Neiberger]

I'm still a noob to this sort of configuration, so I just have a question.
Does it matter that the next hop is in the default global table and not in
the VRF?

John


On Fri, Dec 28, 2012 at 2:58 PM, Jason Lixfeld ja...@lixfeld.ca wrote:

 Hi there,


 Unless I'm doing something really silly, I can't seem to get a multi-hop
 ebgp session up on an ASR9k.  I'm wondering if anyone can spot something I
 might have overlooked or am just not aware of :

 The neighbor reports:

 BGP state = Idle (No route to multi-hop neighbor)

 Which is odd because there is a route for this in the BGP table already.
  It's pingable, etc.

 RP/0/RSP0/CPU0:asr9k#show route vrf Inetv4 1.1.1.254
 Fri Dec 28 16:49:58.718 EST

 Routing entry for 1.1.1.252/30
   Known via bgp 1, distance 200, metric 1, type internal
   Installed Dec 21 16:54:49.859 for 6d23h
   Routing Descriptor Blocks
 2.2.2.2, from 3.3.3.3
   Nexthop in Vrf: default, Table: default, IPv4 Unicast, Table Id:
 0xe000
   Route metric is 1
   No advertising protos.
 RP/0/RSP0/CPU0:asr9k#

 !
 router bgp 1
  vrf Inetv4
   neighbor 1.1.1.254
remote-as 65535
ebgp-multihop 255
update-source Loopback1
ignore-connected-check
address-family ipv4 unicast
 remove-private-AS
!
   !
  !
 !

 RP/0/RSP0/CPU0:asr9k#sh bgp vrf Inetv4 neighbors 1.1.1.254
 Fri Dec 28 16:47:11.630 EST

 BGP neighbor is 1.1.1.254, vrf Inetv4
  Remote AS 65535, local AS 1, external link
  Remote router ID 0.0.0.0
   BGP state = Idle (No route to multi-hop neighbor)
   Last read 00:00:00, Last read before reset 00:00:00
   Hold time is 180, keepalive interval is 60 seconds
   Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
   Last write 00:00:00, attempted 0, written 0
   Second last write 00:00:00, attempted 0, written 0
   Last write before reset 00:00:00, attempted 0, written 0
   Second last write before reset 00:00:00, attempted 0, written 0
   Last write pulse rcvd  not set last full not set pulse count 0
   Last write pulse rcvd before reset 00:00:00
   Socket not armed for io, not armed for read, not armed for write
   Last write thread event before reset 00:00:00, second last 00:00:00
   Last KA expiry before reset 00:00:00, second last 00:00:00
   Last KA error before reset 00:00:00, KA not sent 00:00:00
   Last KA start before reset 00:00:00, second last 00:00:00
   Precedence: internet
   Graceful restart is enabled
   Restart time is 120 seconds
   Stale path timeout time is 360 seconds
   Enforcing first AS is enabled
   Multi-protocol capability not received
   Received 0 messages, 0 notifications, 0 in queue
   Sent 0 messages, 0 notifications, 0 in queue
   Minimum time between advertisement runs is 0 secs

  For Address Family: IPv4 Unicast
   BGP neighbor version 0
   Update group: 0.6 Filter-group: 0.0  No Refresh request being processed
   eBGP neighbor with no inbound or outbound policy; defaults to 'drop'
   Private AS number removed from updates to this neighbor
   AF-dependent capabilities:
 Graceful Restart capability advertised
   Local restart time is 120, RIB purge time is 600 seconds
   Maximum stalepath time is 360 seconds
   Route refresh request: received 0, sent 0
   0 accepted prefixes, 0 are bestpaths
   Cumulative no. of prefixes denied: 0.
   Prefix advertised 0, suppressed 0, withdrawn 0
   Maximum prefixes allowed 1048576
   Threshold for warning message 75%, restart interval 0 min
   An EoR was not received during read-only mode
   Last ack version 0, Last synced ack version 0
   Outstanding version objects: current 0, max 0
   Additional-paths operation: None

   Connections established 0; dropped 0
   Local host: 0.0.0.0, Local port: 0
   Foreign host: 1.1.1.254, Foreign port: 0
   Last reset 00:00:00
   External BGP neighbor may be up to 255 hops away.
 RP/0/RSP0/CPU0:asr9k#

 Thanks in advance.
 ___
 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] IPv6 weirdness

[John Neiberger]

On Fri, Dec 7, 2012 at 10:52 PM, Randy a...@djlab.com wrote:

 On 12/07/2012 5:57 pm, Justin M. Streiner wrote:

 On Fri, 7 Dec 2012, Randy wrote:

  User complained his ipv6 gw on his vlan interface was down.  On
 checking, I couldn't ping it either from the local router.

 This looked interesting to me on a sh ipv6 route for the gw IP (note
 'backup from...' line):


 What does the interface config look like?


 Very basic.

 interface VlanXX
  ip address x.x.x.x x.x.x.x
  no ip redirects
  no ip unreachables
  no ip proxy-arp
  ipv6 address x.x.x:6::1/64
 end

 --
 ~Randy


The interesting thing to me is that in the first case you have a /64 of
type connected, but in the second case you have a /128 of type receive. I
think the /128 type receive just means that the ip address is on the router
itself. So, the question remains why you got different results before and
after bouncing the interface.
___
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] BGP Path Selection and next-hop reachability (IGP vs BGP)

[John Neiberger]

I ran into an interesting situation where I think I understand what is
happening, but I can't find any documentation about the path selection
process that specifically addresses this.

We have a router--let's call it Router A--that has learned a prefix via
iBGP from two route reflector clients. The next hop addresses in those
advertisements are the loopback addresses of the advertising routers. Those
loopback addresses are being advertised into OSPF. So, this router has two
available paths for this prefix:

1: 4.4.4.4 (loopback address of first RR client, learned via OSPF)
2: 5.5.5.5 (loopback address of second RR client, learned via OSPF)

Now, the weirdness happens when the second router experiences
unidirectional traffic and stops advertising anything at all to its
upstream neighbor. Within just a few seconds, OSPF times out, so 5.5.5.5
disappears from OSPF because that router is now isolated.

Now, you must know that Router A also has learned a default route via eBGP.
So, the available paths in the BGP table for a particular prefix now look
like this:

1: 4.4.4.4 (learned via OSPF)
2: 5.5.5.5 (recursively reachable via 0/0 learned from eBGP)

The router switches to the second path, errantly sending packets with a
next hop of 5.5.5.5--which is actually unreachable--out to the upstream
router advertising the default route.

Here is the BGP table before the outage:

R2#show ip bgp 100.100.100.0/24
BGP routing table entry for 100.100.100.0/24, version 12
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Flag: 0x900
  Advertised to update-groups:
123
  Local, (Received from a RR-client)
5.5.5.5 (metric 102) from 5.5.5.5 (100.100.100.100)
  Origin incomplete, metric 0, localpref 100, valid, internal
  Local
5.5.5.5 (metric 102) from 23.23.23.3 (35.35.35.3)
  Origin incomplete, metric 0, localpref 100, valid, internal
  Originator: 100.100.100.100, Cluster list: 35.35.35.3
  Local, (Received from a RR-client)
4.4.4.4 (metric 101) from 4.4.4.4 (4.4.4.4)
  Origin incomplete, metric 0, localpref 100, valid, internal, best

The best path is--correctly--through 4.4.4.4. Here is what the BGP table
looked like when 5.5.5.5 disappeared from OSPF:

R2#show ip bgp 100.100.100.0/24
BGP routing table entry for 100.100.100.0/24, version 13
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x900
  Advertised to update-groups:
123
  Local, (Received from a RR-client)
5.5.5.5 from 5.5.5.5 (100.100.100.100)
  Origin incomplete, metric 0, localpref 100, valid, internal, best
  Local
5.5.5.5 from 23.23.23.3 (35.35.35.3)
  Origin incomplete, metric 0, localpref 100, valid, internal
  Originator: 100.100.100.100, Cluster list: 35.35.35.3
  Local, (Received from a RR-client)
4.4.4.4 (metric 101) from 4.4.4.4 (4.4.4.4)
  Origin incomplete, metric 0, localpref 100, valid, internal


My question is this: Why specifically does this router switch to the path
with a next hop learned via BGP? I'm assuming that a next hop reachable by
eBGP is preferred to a next hop reachable via an IGP, but I don't see
anything in the stated path selection process that would account for that.
Nothing else about the paths changed since BGP hadn't changed. The only
thing that changed was how the second loopback was reachable. It originally
was OSPF and now is recursively reachable through the default route.

Once the BGP session to the failed router times out, the second path is
removed and all is well again.

Any thoughts? I feel like I'm missing something obvious. I've been staring
at this too long.  :)
___
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] BGP Path Selection and next-hop reachability (IGP vs BGP)

[John Neiberger]

I've been doing some more testing and I even talked to a couple of guys
from Cisco Advanced Services and I still don't understand exactly what is
happening.

To summarize, a router has two iBGP paths available for a particular
prefix. The next hop for both paths is learned via OSPF, so the router
selects the path with the lowest IGP metric. Then a network change occurs
such that the next hop for one of the paths is no longer learned via OSPF.
Instead, it is learned via BGP. The router switches to using that path, but
I can't figure out why. It appears that a path with a next hop reachable
via BGP is preferred, but I can't find any documentation that says that.

At first I thought I'd follow the usual path selection criteria for
choosing between two iBGP paths. At that point in the process, the first
question is router ID. Is it switching to the path with the lowest router
ID? Nope. What about cluster length? Nope, it's the same. Lastly, is it
choosing this new path because the neighbor's IP address is lowest?
AgainNO!

So, what the heck? I'm really stumped.


On Fri, Nov 30, 2012 at 2:42 PM, John Neiberger jneiber...@gmail.comwrote:

 I ran into an interesting situation where I think I understand what is
 happening, but I can't find any documentation about the path selection
 process that specifically addresses this.

 We have a router--let's call it Router A--that has learned a prefix via
 iBGP from two route reflector clients. The next hop addresses in those
 advertisements are the loopback addresses of the advertising routers. Those
 loopback addresses are being advertised into OSPF. So, this router has two
 available paths for this prefix:

 1: 4.4.4.4 (loopback address of first RR client, learned via OSPF)
 2: 5.5.5.5 (loopback address of second RR client, learned via OSPF)

 Now, the weirdness happens when the second router experiences
 unidirectional traffic and stops advertising anything at all to its
 upstream neighbor. Within just a few seconds, OSPF times out, so 5.5.5.5
 disappears from OSPF because that router is now isolated.

 Now, you must know that Router A also has learned a default route via
 eBGP. So, the available paths in the BGP table for a particular prefix now
 look like this:

 1: 4.4.4.4 (learned via OSPF)
 2: 5.5.5.5 (recursively reachable via 0/0 learned from eBGP)

 The router switches to the second path, errantly sending packets with a
 next hop of 5.5.5.5--which is actually unreachable--out to the upstream
 router advertising the default route.

 Here is the BGP table before the outage:

 R2#show ip bgp 100.100.100.0/24
 BGP routing table entry for 100.100.100.0/24, version 12
 Paths: (3 available, best #3, table Default-IP-Routing-Table)
 Flag: 0x900
   Advertised to update-groups:
 123
   Local, (Received from a RR-client)
 5.5.5.5 (metric 102) from 5.5.5.5 (100.100.100.100)
   Origin incomplete, metric 0, localpref 100, valid, internal
   Local
 5.5.5.5 (metric 102) from 23.23.23.3 (35.35.35.3)
   Origin incomplete, metric 0, localpref 100, valid, internal
   Originator: 100.100.100.100, Cluster list: 35.35.35.3
   Local, (Received from a RR-client)
 4.4.4.4 (metric 101) from 4.4.4.4 (4.4.4.4)
   Origin incomplete, metric 0, localpref 100, valid, internal, best

 The best path is--correctly--through 4.4.4.4. Here is what the BGP table
 looked like when 5.5.5.5 disappeared from OSPF:

 R2#show ip bgp 100.100.100.0/24
 BGP routing table entry for 100.100.100.0/24, version 13
 Paths: (3 available, best #1, table Default-IP-Routing-Table)
 Flag: 0x900
   Advertised to update-groups:
 123
   Local, (Received from a RR-client)
 5.5.5.5 from 5.5.5.5 (100.100.100.100)
   Origin incomplete, metric 0, localpref 100, valid, internal, best
   Local
 5.5.5.5 from 23.23.23.3 (35.35.35.3)
   Origin incomplete, metric 0, localpref 100, valid, internal
   Originator: 100.100.100.100, Cluster list: 35.35.35.3
   Local, (Received from a RR-client)
 4.4.4.4 (metric 101) from 4.4.4.4 (4.4.4.4)
   Origin incomplete, metric 0, localpref 100, valid, internal


 My question is this: Why specifically does this router switch to the path
 with a next hop learned via BGP? I'm assuming that a next hop reachable by
 eBGP is preferred to a next hop reachable via an IGP, but I don't see
 anything in the stated path selection process that would account for that.
 Nothing else about the paths changed since BGP hadn't changed. The only
 thing that changed was how the second loopback was reachable. It originally
 was OSPF and now is recursively reachable through the default route.

 Once the BGP session to the failed router times out, the second path is
 removed and all is well again.

 Any thoughts? I feel like I'm missing something obvious. I've been staring
 at this too long.  :)

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman

Re: [c-nsp] BGP Path Selection and next-hop reachability (IGP vs BGP)

[John Neiberger]

I thought I'd post an update since I found my answer. Marko Milivojevic
answered on another mailing list. As it turns out, the router still
compares metrics for the next hop even if they're not both learned from
IGPs. So, the path with an OSPF metric of 101 is losing out to a path with
a BGP-learned next hop with a MED of 0. I wouldn't have expected that
behavior at all!


On Fri, Nov 30, 2012 at 6:55 PM, John Neiberger jneiber...@gmail.comwrote:

 I've been doing some more testing and I even talked to a couple of guys
 from Cisco Advanced Services and I still don't understand exactly what is
 happening.

 To summarize, a router has two iBGP paths available for a particular
 prefix. The next hop for both paths is learned via OSPF, so the router
 selects the path with the lowest IGP metric. Then a network change occurs
 such that the next hop for one of the paths is no longer learned via OSPF.
 Instead, it is learned via BGP. The router switches to using that path, but
 I can't figure out why. It appears that a path with a next hop reachable
 via BGP is preferred, but I can't find any documentation that says that.

 At first I thought I'd follow the usual path selection criteria for
 choosing between two iBGP paths. At that point in the process, the first
 question is router ID. Is it switching to the path with the lowest router
 ID? Nope. What about cluster length? Nope, it's the same. Lastly, is it
 choosing this new path because the neighbor's IP address is lowest?
 AgainNO!

 So, what the heck? I'm really stumped.


 On Fri, Nov 30, 2012 at 2:42 PM, John Neiberger jneiber...@gmail.comwrote:

 I ran into an interesting situation where I think I understand what is
 happening, but I can't find any documentation about the path selection
 process that specifically addresses this.

 We have a router--let's call it Router A--that has learned a prefix via
 iBGP from two route reflector clients. The next hop addresses in those
 advertisements are the loopback addresses of the advertising routers. Those
 loopback addresses are being advertised into OSPF. So, this router has two
 available paths for this prefix:

 1: 4.4.4.4 (loopback address of first RR client, learned via OSPF)
 2: 5.5.5.5 (loopback address of second RR client, learned via OSPF)

 Now, the weirdness happens when the second router experiences
 unidirectional traffic and stops advertising anything at all to its
 upstream neighbor. Within just a few seconds, OSPF times out, so 5.5.5.5
 disappears from OSPF because that router is now isolated.

 Now, you must know that Router A also has learned a default route via
 eBGP. So, the available paths in the BGP table for a particular prefix now
 look like this:

 1: 4.4.4.4 (learned via OSPF)
 2: 5.5.5.5 (recursively reachable via 0/0 learned from eBGP)

 The router switches to the second path, errantly sending packets with a
 next hop of 5.5.5.5--which is actually unreachable--out to the upstream
 router advertising the default route.

 Here is the BGP table before the outage:

 R2#show ip bgp 100.100.100.0/24
 BGP routing table entry for 100.100.100.0/24, version 12
 Paths: (3 available, best #3, table Default-IP-Routing-Table)
 Flag: 0x900
   Advertised to update-groups:
 123
   Local, (Received from a RR-client)
 5.5.5.5 (metric 102) from 5.5.5.5 (100.100.100.100)
   Origin incomplete, metric 0, localpref 100, valid, internal
   Local
 5.5.5.5 (metric 102) from 23.23.23.3 (35.35.35.3)
   Origin incomplete, metric 0, localpref 100, valid, internal
   Originator: 100.100.100.100, Cluster list: 35.35.35.3
   Local, (Received from a RR-client)
 4.4.4.4 (metric 101) from 4.4.4.4 (4.4.4.4)
   Origin incomplete, metric 0, localpref 100, valid, internal, best

 The best path is--correctly--through 4.4.4.4. Here is what the BGP table
 looked like when 5.5.5.5 disappeared from OSPF:

 R2#show ip bgp 100.100.100.0/24
 BGP routing table entry for 100.100.100.0/24, version 13
 Paths: (3 available, best #1, table Default-IP-Routing-Table)
 Flag: 0x900
   Advertised to update-groups:
 123
   Local, (Received from a RR-client)
 5.5.5.5 from 5.5.5.5 (100.100.100.100)
   Origin incomplete, metric 0, localpref 100, valid, internal, best
   Local
 5.5.5.5 from 23.23.23.3 (35.35.35.3)
   Origin incomplete, metric 0, localpref 100, valid, internal
   Originator: 100.100.100.100, Cluster list: 35.35.35.3
   Local, (Received from a RR-client)
 4.4.4.4 (metric 101) from 4.4.4.4 (4.4.4.4)
   Origin incomplete, metric 0, localpref 100, valid, internal


 My question is this: Why specifically does this router switch to the path
 with a next hop learned via BGP? I'm assuming that a next hop reachable by
 eBGP is preferred to a next hop reachable via an IGP, but I don't see
 anything in the stated path selection process that would account for that.
 Nothing else about the paths changed since BGP hadn't changed. The only
 thing that changed

Re: [c-nsp] Port-to-Janus or Port-to-Metro mappings on 7600

[John Neiberger]

Thanks, that's exactly what I was looking for! I appreciate the help.

John

On Sat, Oct 20, 2012 at 1:59 AM, Saku Ytti s...@ytti.fi wrote:
 On (2012-10-19 09:22 -0600), John Neiberger wrote:

 I've been beating my head against my desk to remember the command that
 shows the port-to-Janus mappings and the port-to-Metro mappings. I

 Both Janus (PFC3B) and Metropolis (PFC3C) are fabric asics, this should give
 you clue how many there are and which ports are behind them, as you also
 already know you have two fabric channels per card.

 I.e. metropolis/janus map 1:1 same as fabric channel.

 With 'service internal' you can see fabric channel mapping like this:

 le_ruuter#show fabric fpoe interface ten1/1
 fpoe for TenGigabitEthernet1/1 is 9
 le_ruuter#show fabric fpoe interface ten1/2
 fpoe for TenGigabitEthernet1/2 is 9
 le_ruuter#show fabric fpoe interface ten1/3
 fpoe for TenGigabitEthernet1/3 is 0
 le_ruuter#show fabric fpoe interface ten1/4
 fpoe for TenGigabitEthernet1/4 is 0
 le_ruuter#

 le_ruuter#show fabric fpoe map
 slot   channel   fpoe
  10   0
  11   9

 --
   ++ytti
 ___
 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/

[c-nsp] Port-to-Janus or Port-to-Metro mappings on 7600

[John Neiberger]

I've been beating my head against my desk to remember the command that
shows the port-to-Janus mappings and the port-to-Metro mappings. I
thought for sure there was one. I can never remember how ports are
mapped to the Metropolis asics. I just remember it's some oddball
mapping. Do any of you remember the command to check the mapping?

Thanks,
John
___
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] Giants and input errors but no MTU mismatch 7600-to-4948

[John Neiberger]

I have an interface on a 4948 that is reporting increasing giants and
input errors. The MTU is the default 1500 and so is the interface on
the other side of the link. This is a dot1q trunk, if that is
relevant.

7600 Side:

GigabitEthernet3/3 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 7081.058f.471e (bia 7081.058f.471e)
  MTU 1500 bytes, BW 100 Kbit/sec, DLY 10 usec,
 reliability 255/255, txload 6/255, rxload 6/255
  Input queue: 0/2000/15/0 (size/max/drops/flushes); Total output drops: 52636
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 2556 bits/sec, 3911 packets/sec
  30 second output rate 25889000 bits/sec, 2481 packets/sec
 103422624782 packets input, 96894603872012 bytes, 0 no buffer
 Received 421340 broadcasts (390040 multicasts)
 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 15 overrun, 0 ignored
 0 watchdog, 0 multicast, 0 pause input
 0 input packets with dribble condition detected

4948 Side:

GigabitEthernet1/46 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet Port, address is e05f.b919.522d (bia
e05f.b919.522d)
  MTU 1500 bytes, BW 100 Kbit, DLY 10 usec,
 reliability 255/255, txload 6/255, rxload 7/255
  Last input 00:00:00, output never, output hang never
  Last clearing of show interface counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 27555000 bits/sec, 2622 packets/sec
  5 minute output rate 2503 bits/sec, 3827 packets/sec
 103432206170 packets input, 100545576069607 bytes, 0 no buffer
 Received 401659764 broadcasts (377463573 multicasts)
 0 runts, 1892602 giants, 0 throttles
 1892602 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
 0 input packets with dribble condition detected

Any idea how I could be getting giants inbound to the 4948 when the
interface on the 7600 is set to 1500? I could see it if both sides
were not set to dot1q, but they are:

Gi3/3   on   802.1q trunking  1

Gi1/46 on   802.1q trunking  1

What in the world is going on here?
___
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 inactive configuration on ASR9K during card failure

[John Neiberger]

On Mon, Sep 10, 2012 at 1:55 AM, Gergely Antal sk...@skoal.name wrote:
 Hi

 As this doc states the config should be visible in the running config:
 http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.2/system_management/configuration/guide/b_sysman_cg42asr9k_chapter_0110.html#con_58280

Very interesting! That is definitely not happening for us. This
particular router is running 4.0.1, which is fairly old already and
probably pretty buggy. I wonder if we're just running into a bug. I'll
check into that.






 On 09/10/2012 09:42 AM, Gergely Antal wrote:
 Hi

 Is this working for you:

 show configuration history last 10
 show configuration commit changes commit-id

 This is on ver 4.2.1...

 On 09/10/2012 12:28 AM, John Neiberger wrote:
 On Sun, Sep 9, 2012 at 3:36 PM, Gary Buhrmaster
 gary.buhrmas...@gmail.com wrote:
 On Sun, Sep 9, 2012 at 5:08 PM, John Neiberger jneiber...@gmail.com 
 wrote:
 ... In other words, how do I see
 what config will be enabled once a new linecard is inserted?

 Check your rancid (backup) configuration files?

 Yes, that would easily work but I was curious to find a way to do it
 from the router. There surely must be a way to see what configuration
 will be applied when a new module is inserted, but even the TAC
 engineer I was working with earlier didn't know how to do it.




___
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] How to see inactive configuration on ASR9K during card failure

[John Neiberger]

We had a linecard fail on an ASR9K and I wanted to verify what was
connected to it. However, since the card was down, all configuration
information was hidden. How do I see the interface configurations for
a module that is not currently active? In other words, how do I see
what config will be enabled once a new linecard is inserted?

Thanks!
John
___
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 inactive configuration on ASR9K during card failure

[John Neiberger]

On Sun, Sep 9, 2012 at 3:36 PM, Gary Buhrmaster
gary.buhrmas...@gmail.com wrote:
 On Sun, Sep 9, 2012 at 5:08 PM, John Neiberger jneiber...@gmail.com wrote:
 ... In other words, how do I see
 what config will be enabled once a new linecard is inserted?

 Check your rancid (backup) configuration files?

Yes, that would easily work but I was curious to find a way to do it
from the router. There surely must be a way to see what configuration
will be applied when a new module is inserted, but even the TAC
engineer I was working with earlier didn't know how to do it.
___
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] Fabric buffer-reserve high: what does it actually do?

[John Neiberger]

An app owner (Oracle database) has recommended that we enable fabric
buffer-reserve high to solve some Oracle problem they seem to be
running into. We haven't had a chance to investigate their problem
yet, so we're not going to change that just because they asked us to.
However, I'm curious about what it actually does and how it interacts
with the hardware buffers on the 67xx line cards. I did a quick Google
search, but didn't find a lot of detail.

Thanks,
John
___
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] Increasing hold-queue to alleviate microbursts with small hardware queues

[John Neiberger]

This has come up a few times recently. We continue to run into new
situations where we see lots of output queue drops on 6748 blades,
especially in cases where a 10g link is feeding a 1g link. We see OQDs
long before the interface approaches anything close to line rate on
average. Cisco has never recommended this when I've talked to them
about it, but I have seen a recommendation elsewhere to use something
like hold-queue 1024 out on the 1g interfaces to smooth out those
microbursts. I think that will add a tiny amount of latency to the
path, but would there be any other significant performance impacts?
Would this even do what we want? I'm not sure how it would interact
with the hardware queues. It seems as if it creates software-based
buffer space in front of the hardware output queues to store any
bursty traffic. Is it possible that the solution to this particular
problem is this simple?

I can only assume that since Cisco has never recommended trying this,
there must be a reason for it. Either it won't work at all or it has
unfortunate side effects. But I'm considering giving it a try.

Any thoughts?

Many thanks, as usual!

John
___
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] Increasing hold-queue to alleviate microbursts with small hardware queues

[John Neiberger]

Thanks, I suspected that was the case or it would have been mentioned
before. We have played around with different queuing parameters and queue
depths, but I'm trying to find some other potential solutions.

Would a shaping service policy work for this? I'm wondering what the impact
would be on microbursts if we enabled shaping. Would that give us any
additional short-term buffer space?

Thanks again,
John
On Aug 17, 2012 2:44 AM, Phil Mayers p.may...@imperial.ac.uk wrote:

 On 08/17/2012 07:02 AM, John Neiberger wrote:

 This has come up a few times recently. We continue to run into new
 situations where we see lots of output queue drops on 6748 blades,
 especially in cases where a 10g link is feeding a 1g link. We see OQDs
 long before the interface approaches anything close to line rate on
 average.


 As I'm sure you're aware, but just for the archives, average rate is
 pretty irrelevant in this scenario. All that matters is the burst rate at
 the ingress (10 gig) port.

 6748 cards have ~1.3Mb of per-port output buffer, which at 9Gbit/sec (10
 in minus 1 out) will fill in ~1.1 milliseconds. At some fraction of that
 load (e.g. 5 in, 1 out) it'll scale appropriately.

 If you are doing QoS with the default queue parameters, you'll get
 (possibly much) less than that.

  bursty traffic. Is it possible that the solution to this particular
 problem is this simple?


 As others have said, no. It won't do anything.

 You're sure you've either disabled QoS or reconfigured the queues to
 allocate space appropriately i.e. in proportion to the offered load?

 TBH microburst problems on this platform don't come up on the list very
 often, as far as I can see. It's usually the lower-end catalysts.
 __**_
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/**mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at 
 http://puck.nether.net/**pipermail/cisco-nsp/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] Increasing hold-queue to alleviate microbursts with small hardware queues

[John Neiberger]

On Aug 17, 2012 7:57 AM, Phil Mayers p.may...@imperial.ac.uk wrote:

 On 17/08/12 14:48, John Neiberger wrote:

 Thanks, I suspected that was the case or it would have been mentioned
 before. We have played around with different queuing parameters and
 queue depths, but I'm trying to find some other potential solutions.

 Would a shaping service policy work for this? I'm wondering what the
 impact would be on microbursts if we enabled shaping. Would that give us
 any additional short-term buffer space?


 Can you be more specific here? Where would you shape?

I was wondering if an outbound shaping policy on the 1g links would smooth
out the peaks of those bursts prior to them hitting the small hardware
queue. I'm just kind of thinking out loud.

Our approach at the moment is to map everything to the same queue and give
it all the queue space, except for the 15 percent that the priority queue
gets. We can't disable mls qos because other features depend on it.
___
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] Increasing hold-queue to alleviate microbursts with small hardware queues

[John Neiberger]

On Fri, Aug 17, 2012 at 8:36 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
 On 17/08/12 15:29, John Neiberger wrote:

   Can you be more specific here? Where would you shape?

 I was wondering if an outbound shaping policy on the 1g links would
 smooth out the peaks of those bursts prior to them hitting the small
 hardware queue. I'm just kind of thinking out loud.


 Not really. Shaping happens at the output of the queue, so it can't help you
 with the queue overflowing.

 On the 6500, packets are

  1. received
  2. put into an ingress queue
  3. forwarding lookup takes place
  4. packets are moved across the fabric into an egress queue
  5. egress queueing takes place

 Steps 1-3 don't really block because the fabric is non-blocking. So the
 ingress queueing is largely useless on this platform. So, your only room for
 dealing with output speed/load mismatches is in the egress queue.

 You'd need to ingress shape (which is not possible) or egress shape on the
 upstream box. And shaping is not widely available.

 TBH, you either need a box with much bigger buffers, or move to a 10g port.

Thanks. That's really what I figured, but I was hoping to find some
creative way to alleviate the issue since in many cases we can't
upgrade the link speed or hardware, at least in the short term. That's
definitely going to be my recommendation in the long term.

Thanks again!
John
___
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/