Re: [c-nsp] MPLS VPN over mGRE
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] Difference between ISIS NSR and ISIS NSF Cisco-Style
I have a one more query with HA mode . can we configure both NSR and NSF together , and if so during switchover which one is triggered first NSR or NSF . you can either configure nsf cisco or nsf ietf in ISIS, so one or the other. The only common thing is that a router configured with nsf cisco will still able to help a restarting nsf ietf router to perform its graceful restart, so the nsf cisco box will also advertise IETF-GR capability in the IIH.. I have two reasons for going into this deployement approch. 1 If someof my neighbour is not NSF capable or by mistake NSF gracefull config is not enabled or removed from any neighbour.NSR will take care for those neighbours. 2 During testing on CRS with scalability figures ,after switchover it was taking 4 mins of time to fully sync all the routing information with standby and if there is one more switchover during that time span , NSF can take care. What do you suggest as best practice deployements for NSR/NSF considering above two points. As said, you can't enable both, one or the other. So you can't address both concerns, and need to evaluate which one you care more about. I would argue that the 2nd one is more of a corner case, and would advocate nsf cisco to be independent from any neighbour NSF capability support.. 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/
[c-nsp] WPA SSIDs advertised as ad-hoc after WiSM2 redundancy switchover
We have two WiSM2 modules in redundant setup where one module has all the licences and the other one is in hot standby state. Both modules run the software 7.4.100. We have seen the following annoying behaviour when we have tested the redundancy. I have no reason to believe that the same wouldn't happen if one of the modules failed for real. When the hot standby module becomes the active one and all the access points are connected to it suddenly all the WPA protected SSIDs become unusable for most of the clients. The reason is that networks are advertised as ad-hoc ones and not as infrastructure ones. When the networks are disabled and enabled from the WiSM2 they continue operating normally. Has anyone else seen this problem? Does anyone know any solution or is it a new or even a known bug yet to be fixed? Cheers, Matti ___ 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
Last I checked ISIS didn#39;t work over mgre interfaces and you#39;d need to use OSPF. This might be code-dependent. David Barak ___ 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] nexus 7k force FTP source interface ?
I am trying to FTP xfer config file to server, which we have configured to only allow the nexus loopback0 as SRC IP, but xfer fails because SRC is one of the L3 VLAN IPs NOT loopback0. How can I force FTP to use a certain IP interface, specifically from management loopback? So far I see no way to force FTP source. If I use TFTP I can set the source but I do not want to use TFTP. Thanks for any help. Jeff Fitzwater OIT Network Systems Princeton University ___ 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] nexus 7k force FTP source interface ?
Hi, maybe you can use the management VRF. There you should have only one IP. copy run ftp://x.x.x.x vrf management Am 30.01.2013 um 15:44 schrieb Jeffrey G. Fitzwater jf...@princeton.edu: I am trying to FTP xfer config file to server, which we have configured to only allow the nexus loopback0 as SRC IP, but xfer fails because SRC is one of the L3 VLAN IPs NOT loopback0. How can I force FTP to use a certain IP interface, specifically from management loopback? So far I see no way to force FTP source. If I use TFTP I can set the source but I do not want to use TFTP. Thanks for any help. Jeff Fitzwater OIT Network Systems Princeton University ___ 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] nexus 7k force FTP source interface ?
Yes, but that's our plan B. Thanks Jeff F. On Jan 30, 2013, at 09:44 , Jeffrey G. Fitzwater wrote: I am trying to FTP xfer config file to server, which we have configured to only allow the nexus loopback0 as SRC IP, but xfer fails because SRC is one of the L3 VLAN IPs NOT loopback0. How can I force FTP to use a certain IP interface, specifically from management loopback? So far I see no way to force FTP source. If I use TFTP I can set the source but I do not want to use TFTP. Thanks for any help. Jeff Fitzwater OIT Network Systems Princeton University ___ 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] unknown interface for ipv6 route in 4.2.3
Any idea what Unknown interface is? CSCtq62370 probably doesn't apply in 4.2.3. RP/0/RP0/CPU0:CRS#sh route ipv6 2001:648::/32 Routing entry for 2001:648::/32 Known via bgp 1241, distance 200, metric 0 Tag 5408, type external Installed Jun 6 15:58:53.474 for 00:00:05 Routing Descriptor Blocks fe80::222:83ff:fe42:923d, from 2001:648:2100::1, via Unknown Route metric is 0 No advertising protos. RP/0/RP0/CPU0:CRS#sh route ipv6 2001:648:2100::1 Routing entry for 2001:648:2100::/48 Known via connected, distance 0, metric 0 (connected) Installed Jan 9 10:07:57.360 for 3w0d Routing Descriptor Blocks directly connected, via TenGigE0/2/0/3.290851 Route metric is 0 No advertising protos. RP/0/RP0/CPU0:CRS#sh cef ipv6 2001:648::/32 det 2001:648::/32, version 2081, internal 0x1401 (ptr 0x9d9403fc) [1], 0x0 (0x9d1fd548), 0x0 (0x0) Updated Jan 9 10:07:57.376 remote adjacency to UNKNOWN intf 0x012801c0 Prefix Len 32, traffic index 0, precedence routine (0), priority 4 gateway array (0x9cfc0e5c) reference count 5, flags 0x0, source rib (5), 0 backups [6 type 3 flags 0x10101 (0x9d1028c0) ext 0x0 (0x0)] LW-LDI[type=3, refc=1, ptr=0x9d1fd548, sh-ldi=0x9d1028c0] via fe80::222:83ff:fe42:923d, UNKNOWN intf 0x012801c0, 2 dependencies, weight 0, class 0, bgp-ext [flags 0x6020] path-idx 0 [0x9e01619c 0x0] next hop fe80::222:83ff:fe42:923d remote adjacency Load distribution: 0 (refcount 6) Hash OK Interface Address 0 Y UNKNOWN intf 0x012801c0 remote RP/0/RP0/CPU0:CRS#sh cef ipv6 2001:648:2100::1 det 2001:648:2100::/48, version 2080, attached, connected, internal 0x4c1 (ptr 0x9d9405dc) [1], 0x0 (0x9d1fd5f8), 0x0 (0x0) Updated Jan 9 10:07:57.370 remote adjacency to TenGigE0/2/0/3.290851 Prefix Len 48, traffic index 0, precedence routine (0), priority 0 gateway array (0x9cfc12e4) reference count 1, flags 0x0, source rib (5), 0 backups [2 type 3 flags 0x10101 (0x9d102bd8) ext 0x0 (0x0)] LW-LDI[type=3, refc=1, ptr=0x9d1fd5f8, sh-ldi=0x9d102bd8] via TenGigE0/2/0/3.290851, 4 dependencies, weight 0, class 0 [flags 0x8] path-idx 0 [0x9e0162e0 0x0] remote adjacency Load distribution: 0 (refcount 2) Hash OK Interface Address 0 Y TenGigE0/2/0/3.290851 remote RP/0/RP0/CPU0:CRS#sh route ipv6 2001:648:2ffc:1200::2 Routing entry for 2001:648::/32 Known via bgp 1241, distance 200, metric 0 Tag 5408, type external Installed Dec 5 11:28:48.223 for 8w0d Routing Descriptor Blocks fe80::222:83ff:fe42:923d, from 2001:648:2100::1, via Unknown Route metric is 0 No advertising protos. RP/0/RP0/CPU0:CRS#tr 2001:648:2ffc:1200::2 Type escape sequence to abort. Tracing the route to 2001:648:2ffc:1200::2 1 * * * 2 * * * Traffic for above network isn't forwarded at all... shut/no shut of bgp neighbor usually solves the problem. -- Tassos ___ 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
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
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] Problem on LNS VRF
Dears, I have an ASR1001 functioning as a LNS. User will use a 3G Modem to establish PPPoE to Provider's LAC and then terminate at the LNS via L2TP tunnel. I have assigned certain users to their proper VRF through AAA server so that it can be applied their peer ip, vrf and loopback interface on the virtual-access interface. 3G Modem can establish the connection to LNS and assign the VAI to specific VRF according to the return av-pair attribute. LNS also has another sub-interface to the PE router and assigned to the same VRF with the VAI for each user. However, I found that I can't ping from the 3G Modem to PE, on the contrary, PE can ping to the 3G Modem. The traceroute result from 3G Modem is stuck at the LNS and I can ping from the 3G Modem to LNS. I have checked that the vrf routing table on LNS has the route to PE. It's so strange that the 3G Modem can reach the LNS but not PE. Any idea?? ___ 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
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] Processing load OID for Cisco IPS SSM 40
We have a couple of these that I want to monitor with our management systems but the standard CPU load is always pegged at 100%. I gather the metric to monitor is Processing Load but I haven't been able to find an OID for this. Anyone here know what it might be? Thanks -Rob- This email is intended only for the addressee. It may contain confidential or proprietary information that cannot be disclosed without BCLC's permission. If you have received this email in error, please notify the sender immediately and delete the email. ___ 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] unknown interface for ipv6 route in 4.2.3
On Wed, 30 Jan 2013, Tassos Chatzithomaoglou wrote: RP/0/RP0/CPU0:CRS#sh route ipv6 2001:648:2100::1 Routing entry for 2001:648:2100::/48 Known via connected, distance 0, metric 0 (connected) Installed Jan 9 10:07:57.360 for 3w0d Routing Descriptor Blocks directly connected, via TenGigE0/2/0/3.290851 Route metric is 0 No advertising protos. What is the config of TenGigE0/2/0/3.290851 ? Is it really a /48 configured there directly on the interface? -- 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/
Re: [c-nsp] Cat6500 odd arp behavior
Saw 7600 dropping arp from certain addresses. Can't recall defect. ___ 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] Cat6500 odd arp behavior
Thanks Christian. Can you elaborate on what side effects from uRPF I need to be aware of when using the glean HWRL? -Vinny -Original Message- From: Christian Meutes [mailto:christ...@errxtx.net] Sent: Friday, January 25, 2013 10:50 PM To: Abello, Vinny Cc: p.may...@imperial.ac.uk; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cat6500 odd arp behavior On Jan 25, 2013, at 10:16 PM, vinny_abe...@dell.com wrote: Am I understanding the issue correctly? I ran into those issues back in 2008 when the CoPP docs haven't been that clear about the relationship between CoPP, ARP and the glean HWRL. You should mostly be safe when you enable the glean HWRL and, obviously, don't factor those packets needing ARP in your CoPP policy as it wouldn't make much sense in terms of security. What you should be aware of are also side effects when you use uRPF on these boxes. With the whole family in place, so uRPF, the glean HWRL and CoPP, you will most likely not be able to fix all falsely dropped packets due to the platforms restrictions and cornercases. ___ 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] unknown interface for ipv6 route in 4.2.3
Yes, that's the LAN of the local IX. interface TenGigE0/2/0/3.290851 description ** GRIX ** ipv4 address x.x.x.x/24 ipv6 address 2001:648:2100::x/48 flow ipv4 monitor fmm-PEER sampler sm ingress dot1q vlan 2908 51 Two hours ago the BGP session was reseted by the peer, so it's working again (unknown interface has been replaced by the real interface) RP/0/RP0/CPU0:CRS#sh route ipv6 2001:648::/32 Routing entry for 2001:648::/32 Known via bgp 1241, distance 200, metric 0 Tag 5408, type external Installed Jan 30 18:47:22.076 for 02:06:48 Routing Descriptor Blocks fe80::222:83ff:fe42:923d, from 2001:648:2100::1, via TenGigE0/2/0/3.290851 Route metric is 0 No advertising protos. RP/0/RP0/CPU0:CRS#sh cef ipv6 2001:648::/32 2001:648::/32, version 2391, internal 0x1401 (ptr 0x9d94099c) [1], 0x0 (0x9d1fd758), 0x0 (0x0) Updated Jan 30 18:47:22.081 remote adjacency to TenGigE0/2/0/3.290851 Prefix Len 32, traffic index 0, precedence routine (0), priority 4 via fe80::222:83ff:fe42:923d, TenGigE0/2/0/3.290851, 6 dependencies, weight 0, class 0, bgp-ext [flags 0x6020] path-idx 0 [0x9e0162e0 0x0] next hop fe80::222:83ff:fe42:923d remote adjacency -- Tassos Mikael Abrahamsson wrote on 30/1/2013 20:35: On Wed, 30 Jan 2013, Tassos Chatzithomaoglou wrote: RP/0/RP0/CPU0:CRS#sh route ipv6 2001:648:2100::1 Routing entry for 2001:648:2100::/48 Known via connected, distance 0, metric 0 (connected) Installed Jan 9 10:07:57.360 for 3w0d Routing Descriptor Blocks directly connected, via TenGigE0/2/0/3.290851 Route metric is 0 No advertising protos. What is the config of TenGigE0/2/0/3.290851 ? Is it really a /48 configured there directly on 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/
Re: [c-nsp] unknown interface for ipv6 route in 4.2.3
Hi, This... is amazing. And then people complain that a /64 is too big for a single LAN. I'd expect more bugs and unexpected behaviour - implementations get tested with LAN = /64, and sometimes with /112 or /124, but I'd expect most interesting results for connected networks with shorter masks. i've seen some /48's - but /56 is more common in terms of larger-than-i-expect-to-see networks 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] unknown interface for ipv6 route in 4.2.3
Hi, On Wed, Jan 30, 2013 at 07:27:18PM +, a.l.m.bu...@lboro.ac.uk wrote: I'd expect more bugs and unexpected behaviour - implementations get tested with LAN = /64, and sometimes with /112 or /124, but I'd expect most interesting results for connected networks with shorter masks. i've seen some /48's - but /56 is more common in terms of larger-than-i-expect-to-see networks On a single LAN? (Of course we assign /48 and /56 to our customers, but I'd expect them to be spread out, to be used on multiple LAN segments with a /64 each...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpdRAaMvN4pc.pgp Description: PGP signature ___ 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] unknown interface for ipv6 route in 4.2.3
tbh, this is something i didn't even think about...and i don't know why they chose to go with /48. https://www.peeringdb.com/private/exchange_view.php?id=347 PS: sorry for the previous pgp email. -- Tassos Gert Doering wrote on 30/1/2013 21:09: Hi, On Wed, Jan 30, 2013 at 08:57:25PM +0200, Tassos Chatzithomaoglou wrote: Yes, that's the LAN of the local IX. interface TenGigE0/2/0/3.290851 description ** GRIX ** ipv4 address x.x.x.x/24 ipv6 address 2001:648:2100::x/48 This... is amazing. And then people complain that a /64 is too big for a single LAN. I'd expect more bugs and unexpected behaviour - implementations get tested with LAN = /64, and sometimes with /112 or /124, but I'd expect most interesting results for connected networks with shorter masks. gert ___ 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] unknown interface for ipv6 route in 4.2.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tbh, this is something i didn't even think about...and i don't know why they chose to go with /48. https://www.peeringdb.com/private/exchange_view.php?id=347 - -- Tassos Gert Doering wrote on 30/1/2013 21:09: Hi, On Wed, Jan 30, 2013 at 08:57:25PM +0200, Tassos Chatzithomaoglou wrote: Yes, that's the LAN of the local IX. interface TenGigE0/2/0/3.290851 description ** GRIX ** ipv4 address x.x.x.x/24 ipv6 address 2001:648:2100::x/48 This... is amazing. And then people complain that a /64 is too big for a single LAN. I'd expect more bugs and unexpected behaviour - implementations get tested with LAN = /64, and sometimes with /112 or /124, but I'd expect most interesting results for connected networks with shorter masks. gert -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iQEcBAEBAgAGBQJRCXlZAAoJEEtKGLURDUV3fsYIAI7e0XMM6Hm3AeC5fSLuqojp CEtb/QkVEVyQlLRBaP6A7KOdBhiIjopTkn0VxWAAnw/GArGhA8V2OEnNYEPyjObv mt/glMCIErP0DcTWKEyt7MUFHv5nQpAs0CcZVFpJENMlquTSb4+bbPcCyQd9bK4e YcR0xzltPmLFjI7rENiWbcKPxucSfYanyWr/WyQIls2q+cQdRruBJYRR2bWFueNC irHSiRjBzI63DPwmdc47+i+oNggbnc8lTU9IqpEk4dlv4Ai6UiGQ/7/yMAsZgjf4 vSHbb5IdzsMoKAWwriXFcNMzjGgzmAF2bD8xXo9ts+QTfIWYx/kb6t/6eFc7SFc= =R7R3 -END PGP SIGNATURE- ___ 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 s0/1/0 T-1 is up but not showing up in route table
The T-1 seems to be up from a Layer-2 perspective. Something is wrong with my routing though. The interface does NOT show up in the “sh ip route? Output. I would expect to see it as a directly connected interface but it isn't there. The card is in “slot 1” so I’m thinking that may have something to do with but that’s just a hunch. We also have a 9-port switch in the router as well. “Sh diag” looks clean too. Any ideas? router#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is x.x.92.1 to network 0.0.0.0 x.0.0.0/24 is subnetted, 1 subnets C x.x.92.0 is directly connected, FastEthernet0/0 S192.168.10.0/24 [1/0] via 192.168.2.3 172.16.0.0/30 is subnetted, 1 subnets C 172.16.31.48 is directly connected, Tunnel21 172.18.0.0/24 is subnetted, 2 subnets S 172.18.3.0 [1/0] via 192.168.2.254 S 172.18.1.0 [1/0] via 192.168.2.254 S192.168.1.0/24 [1/0] via 192.168.2.254 C192.168.2.0/24 is directly connected, Vlan10 S192.168.3.0/24 [1/0] via 192.168.2.254 S* 0.0.0.0/0 [1/0] via x.x.92.1 router# T-1 looks good here, plus no Alarms router#sh service-module serial 0/1/0 Interface Serial0/1/0 Module type is T1/fractional Hardware revision is 1.0, Software revision is 001, Image checksum is 0x0, Protocol revision is 0.1 Receiver has no alarms. Framing is ESF, Line Code is B8ZS, Current clock source is line, Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec. Last module self-test (done at startup): Passed Last clearing of alarm counters 00:17:16 loss of signal:0, loss of frame :0, AIS alarm :0, Remote alarm :0, Module access errors :0, Total Data (last 0 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Data in current interval (0 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs router# sh ver System image file is flash:c2801-adventerprisek9-mz.124-24.T.bin Cisco 2801 (revision 7.0) with 240640K/21504K bytes of memory. Processor board ID FTX1046Z0J0 11 FastEthernet interfaces 1 Serial interface 1 terminal line 1 Virtual Private Network (VPN) Module 2 DSPs, 16 Voice resources 1 cisco service engine(s) DRAM configuration is 64 bits wide with parity disabled. 191K bytes of NVRAM. 62720K bytes of ATA CompactFlash (Read/Write) interface Serial0/1/0 ip address x.x.x.x 255.255.255.252 encapsulation ppp service-module t1 timeslots 1-24 end ___ 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 s0/1/0 T-1 is up but not showing up in route table
And what about Show inter ser 0/1/0 ? Its probably down Ppp issues? Sent from a mobile device On 31/01/2013, at 9:52, false jct...@yahoo.com wrote: The T-1 seems to be up from a Layer-2 perspective. Something is wrong with my routing though. The interface does NOT show up in the “sh ip route? Output. I would expect to see it as a directly connected interface but it isn't there. The card is in “slot 1” so I’m thinking that may have something to do with but that’s just a hunch. We also have a 9-port switch in the router as well. “Sh diag” looks clean too. Any ideas? router#sh ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is x.x.92.1 to network 0.0.0.0 x.0.0.0/24 is subnetted, 1 subnets C x.x.92.0 is directly connected, FastEthernet0/0 S192.168.10.0/24 [1/0] via 192.168.2.3 172.16.0.0/30 is subnetted, 1 subnets C 172.16.31.48 is directly connected, Tunnel21 172.18.0.0/24 is subnetted, 2 subnets S 172.18.3.0 [1/0] via 192.168.2.254 S 172.18.1.0 [1/0] via 192.168.2.254 S192.168.1.0/24 [1/0] via 192.168.2.254 C192.168.2.0/24 is directly connected, Vlan10 S192.168.3.0/24 [1/0] via 192.168.2.254 S* 0.0.0.0/0 [1/0] via x.x.92.1 router# T-1 looks good here, plus no Alarms router#sh service-module serial 0/1/0 Interface Serial0/1/0 Module type is T1/fractional Hardware revision is 1.0, Software revision is 001, Image checksum is 0x0, Protocol revision is 0.1 Receiver has no alarms. Framing is ESF, Line Code is B8ZS, Current clock source is line, Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec. Last module self-test (done at startup): Passed Last clearing of alarm counters 00:17:16 loss of signal:0, loss of frame :0, AIS alarm :0, Remote alarm :0, Module access errors :0, Total Data (last 0 15 minute intervals): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Data in current interval (0 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs router# sh ver System image file is flash:c2801-adventerprisek9-mz.124-24.T.bin Cisco 2801 (revision 7.0) with 240640K/21504K bytes of memory. Processor board ID FTX1046Z0J0 11 FastEthernet interfaces 1 Serial interface 1 terminal line 1 Virtual Private Network (VPN) Module 2 DSPs, 16 Voice resources 1 cisco service engine(s) DRAM configuration is 64 bits wide with parity disabled. 191K bytes of NVRAM. 62720K bytes of ATA CompactFlash (Read/Write) interface Serial0/1/0 ip address x.x.x.x 255.255.255.252 encapsulation ppp service-module t1 timeslots 1-24 end ___ 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 3850 switches
The buffer size is double that of the 3750X series... 12Mb/48 port vs. 6Mb/48 port On Sun, Jan 20, 2013 at 10:47 AM, Joshua Morgan joshua.mor...@gmail.comwrote: Ah, couldn't tell with your e-mail address. I will get in touch with my CAM, thanks. Sent from my iPhone On 20/01/2013, at 0:54, Lukasz Bromirski luk...@bromirski.net wrote: On Jan 19, 2013, at 2:27 PM, Joshua Morgan joshua.mor...@gmail.com wrote: I'm a partner but have no details. Did you get them from CCO or your CAM? I'm with Cisco :) Yes, you should have some messaging from CAMs and Partner SEs. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net ___ 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 SIP600/601 with etherbundles
Hello, I was wondering if there are any known issues with XR 4.0.1 running a SIP600 or SIP601 with ether bundles. We have a couple chassis that still need to upgrade to newer versions of the OS, but I can't do that right away and need to expand link capacity before I will be able to deploy newer OS. I understand that IPv6 does not work for bundles until version 4.1.0. Does anyone have experience with these blades and the version of XR we are running? These would be either SIP-600 or SIP-601 blades with SPA-8X1GE-V2 or SPA-10X1GE-V2 port adapters. I'd prefer the SIP-600 for this site as I have more on hand then the 601's in case of failure. Thanks, -Lee ___ 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 s0/1/0 T-1 is up but not showing up in route table
On 1/30/13 2:52 PM, false wrote: The T-1 seems to be up from a Layer-2 perspective. Something is wrong with my routing though. The interface does NOT show up in the “sh ip route? Output. I would expect to see it as a directly connected interface but it isn't there. The card is in “slot 1” so I’m thinking that may have something to do with but that’s just a hunch. We also have a 9-port switch in the router as well. “Sh diag” looks clean too. Any ideas? What does show interface display for line protocol? Try: interface Serial0/1/0 encapsulation ppp service-module t1 timeslots 1-24 speed 64 service-module t1 framing esf service-module t1 linecode b8zs -- Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] VPDN multihop/forwarding not working
Hi Guys, Have a 7200 (LNS) that terminates DSL tails from multiple carriers (Using our radius for auth) - Attempting to forward connection requests for a specific realm to an alternate LNS (So create an L2TP tunnel) Have the following vpdn setup, but the tunnel is not getting created to the initiate-to IPand if the new realm DSL accounts are created on our radius server, they auth? vpdn enable vpdn multihop vpdn aaa attribute nas-port vpdn-nas vpdn logging vpdn history failure table-size 50 vpdn search-order domain vpdn domain-delimiter @ suffix vpdn domain-delimiter / prefix vpdn-group TEST description Test for VPDN forward request-dialin protocol l2tp domain testrealm.com.au initiate-to ip xxx.xxx.xxx.xx1 source-ip xxx.xxx.xxx.xx2 local name TEST7200 l2tp tunnel password xxx l2tp tunnel timeout no-session never Cheers for any suggestions ___ 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/
