Re: [c-nsp] ASR-9010-AC vs ASR-9010-AC-V2
On Thu, 20 Jun 2013, Mikael Abrahamsson wrote: On Thu, 20 Jun 2013, Mattias Gyllenvarg wrote: Dear List What is the difference between the chassie versions? Is the V2 just a hardware revision? V2 is probably the uprated FAN array, which means you can have DWDM optics in all slots in a 24x10GE card. I think this relates to the power supplies. I noticed 'Version 1' and 'Version 2' power options in the specs a few weeks ago. When I asked our SE he told me V1 has 3 power modules, V2 has 4. The difference is essentially to provide more headroom in the event of one of the modules failing. Apparently V1 can just about do a fully loaded chassis with 2 modules. -Ronan ___ 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] Backup edge port
On Mon, 10 Jan 2011, Peter Rathlev wrote: On Mon, 2011-01-10 at 19:44 +0100, Gert Doering wrote: On Mon, Jan 10, 2011 at 07:56:51PM +0200, Ibrahim Abo Zaid wrote: I have a server connected to 2 switches and need to implement +1 For Linux servers, just use bonding with the modprobe.conf options mode=active-backup primary=eth0. I can give a full example if somebody would want that. Another +1 - I've done bonding on Linux servers across different switches many times. The last time the switches involved were stacked 3750Gs allowing me to do etherchannel on the switch side. The bonding module has a few parameters that can be tweaked to suit your situation, but the setup is straightforward. I've done something similar on a Windows server, but it was handled by the NIC driver rather than being part of the OS. -Ronan ___ 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] PPPoE Dialer in VRF disables IP address negotiation?
I've got a 2811 running 12.4(24)T3. I'm trying to set it up as PPPoE client. Everything works fine when I do this in the global routing table: interface Dialer1 ip address negotiated ip mtu 1492 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname ... ppp chap password ... IPCP: I CONFREQ [REQsent] id 1 len 10 IPCP:Address . IPCP: O CONFACK [REQsent] id 1 len 10 IPCP:Address . IPCP: I CONFNAK [ACKsent] id 1 len 10 IPCP:Address . IPCP: O CONFREQ [ACKsent] id 2 len 10 IPCP:Address . And I end up with two connected host routes in the routing table. When I try and put the Dialer interface into a VRF the Dialer config changes to: interface Dialer1 ip vrf forwarding VRF_A no ip address ip mtu 1492 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname ppp chap password PPP no longer negotiates an IP address: IPCP: I CONFREQ [Not negotiated] id 1 len 10 IPCP:Address ... LCP: O PROTREJ [Open] id 2 len 16 protocol IPCP 'ip address negotiated' is accepted on the CLI, but isn't applied, the dialer interface stubbornly retains no ip address. I've tried 'ppp ipcp accept-address' but it makes no difference. I've googled and found 'Dialer Watch' but it looks like that requires the IP address to be configured in the Dialer rather than negotiated upon connection. I hope I'm missing something obvious. Any ideas? If it's not possible, are there any other alternatives for getting traffic into VRF_A? -Ronan ___ 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] PPPoE Dialer in VRF disables IP address negotiation?
Hi Ed, On Fri, 15 Oct 2010, Ed Ronayne wrote: You need to re apply ip address neg to the dialler interface after putting the interface into a vrf. I've tried that. 'ip address negotiated' is accepted on the CLI, but isn't applied, the dialer interface stubbornly retains no ip address. I've tried 'ppp ipcp accept-address' but it makes no difference. -Ronan On 15 Oct 2010, at 17:55, Ronan Mullally ro...@iol.ie wrote: I've got a 2811 running 12.4(24)T3. I'm trying to set it up as PPPoE client. Everything works fine when I do this in the global routing table: interface Dialer1 ip address negotiated ip mtu 1492 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname ... ppp chap password ... IPCP: I CONFREQ [REQsent] id 1 len 10 IPCP:Address . IPCP: O CONFACK [REQsent] id 1 len 10 IPCP:Address . IPCP: I CONFNAK [ACKsent] id 1 len 10 IPCP:Address . IPCP: O CONFREQ [ACKsent] id 2 len 10 IPCP:Address . And I end up with two connected host routes in the routing table. When I try and put the Dialer interface into a VRF the Dialer config changes to: interface Dialer1 ip vrf forwarding VRF_A no ip address ip mtu 1492 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname ppp chap password PPP no longer negotiates an IP address: IPCP: I CONFREQ [Not negotiated] id 1 len 10 IPCP:Address ... LCP: O PROTREJ [Open] id 2 len 16 protocol IPCP 'ip address negotiated' is accepted on the CLI, but isn't applied, the dialer interface stubbornly retains no ip address. I've tried 'ppp ipcp accept-address' but it makes no difference. I've googled and found 'Dialer Watch' but it looks like that requires the IP address to be configured in the Dialer rather than negotiated upon connection. I hope I'm missing something obvious. Any ideas? If it's not possible, are there any other alternatives for getting traffic into VRF_A? -Ronan ___ 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] PPPoE Dialer in VRF disables IP address negotiation? [Fixed]
The time-honoured Windows solution has provided a fix. After a reload of the router I am now able to apply 'ip address negotiated' to the dialer interface and everything is working as expected. -Ronan On Fri, 15 Oct 2010, Ed Ronayne wrote: You need to re apply ip address neg to the dialler interface after putting the interface into a vrf. For safety ios executes a no ip address in the interface after a vrf change Regards Ed Sent from the batphone. On 15 Oct 2010, at 17:55, Ronan Mullally ro...@iol.ie wrote: I've got a 2811 running 12.4(24)T3. I'm trying to set it up as PPPoE client. Everything works fine when I do this in the global routing table: interface Dialer1 ip address negotiated ip mtu 1492 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname ... ppp chap password ... IPCP: I CONFREQ [REQsent] id 1 len 10 IPCP:Address . IPCP: O CONFACK [REQsent] id 1 len 10 IPCP:Address . IPCP: I CONFNAK [ACKsent] id 1 len 10 IPCP:Address . IPCP: O CONFREQ [ACKsent] id 2 len 10 IPCP:Address . And I end up with two connected host routes in the routing table. When I try and put the Dialer interface into a VRF the Dialer config changes to: interface Dialer1 ip vrf forwarding VRF_A no ip address ip mtu 1492 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname ppp chap password PPP no longer negotiates an IP address: IPCP: I CONFREQ [Not negotiated] id 1 len 10 IPCP:Address ... LCP: O PROTREJ [Open] id 2 len 16 protocol IPCP 'ip address negotiated' is accepted on the CLI, but isn't applied, the dialer interface stubbornly retains no ip address. I've tried 'ppp ipcp accept-address' but it makes no difference. I've googled and found 'Dialer Watch' but it looks like that requires the IP address to be configured in the Dialer rather than negotiated upon connection. I hope I'm missing something obvious. Any ideas? If it's not possible, are there any other alternatives for getting traffic into VRF_A? -Ronan ___ 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] NAT gaps - packets not getting translated
I've been struggling to get my head around this for the past few days (trying to figure it out on a live box doesn't help). I suspect I'm missing something subtle (hopefully not obvious!). I've got a setup like this: VRF 1 enduser - router --- router ---+ | A B +-+ 2811 +-- Internet +-+ | A enduser - router --- router ---+ VRF n Packets at points A are typically 10.x.y.z, and can (but don't yet) overlap in different VRFs. These packets are NATed by the 2811 and have addresses of the form A.B.C.x at point B. Each VRF has a single IP address dedicated to it (so VRF 1 would be A.B.C.1, VRF 2 A.B.C.2, etc). I have the following config on interfaces at A and B: (A) interface Port-channel1.1107 description VRF 2 mtu 1600 encapsulation dot1Q 1107 ip vrf forwarding VRF 2 ip address 10.35.255.195 255.255.255.240 ip mtu 1500 ip nat inside ip virtual-reassembly standby 2 ip 10.35.255.193 standby 2 follow vpn-vip standby 2 name vrf2-default crypto map CPE-vrf2 redundancy vrf2-default end (B) interface Port-channel1.1011 description Onwards Internet access via Sonicwall mtu 1600 encapsulation dot1Q 1011 ip address x.x.x.83 255.255.255.248 ip mtu 1500 ip nat outside ip virtual-reassembly standby delay minimum 30 reload 60 standby 1 ip x.x.x.81 standby 1 follow vpn-vip standby 1 authentication md5 x standby 1 name public-nat The loopback interface on the 2811 for each VRF looks like: interface Loopback1107 description VRF 2 PWAN ip vrf forwarding VRF2 ip address 10.35.255.252 255.255.255.255 ip nat inside ip virtual-reassembly I'm running BGP within each VRF to distribute routes. I have the NAT mapping configured with: ip nat pool vrf1 A.B.C.1 A.B.C.1 netmask 255.255.255.128 ip nat pool vrf2 A.B.C.2 A.B.C.2 netmask 255.255.255.128 ip nat inside source list vrf1 pool vrf1 mapping-id 10 vrf VRF1 overload ip nat inside source list vrf2 pool vrf2 mapping-id 10 vrf VRF2 overload (I've tried route-maps instead of source lists but it's made no difference) Most traffic works fine, however I'm seeing a steady stream of leaked packets with internal source addresses, often ICMP traffic from loopback interfaces on routers downstream within the various VRFs: 10.0.0.49.1822 x.x.x.x.21: S 1651477420:1651477420(0) win 65535 mss 1360,nop,nop,sackOK 10.0.0.4 x.x.x.x.49: ICMP time exceeded in-transit, length 36 10.0.0.49.1822 x.x.x.x.21: . ack 3704911765 win 65535 (I can reproduce this at will using FTP connections) 16:05:00.338256 IP 10.35.255.0.49154 x.x.x.130.53: 55382+ A? hostname. (35) 16:05:01.273139 IP 10.35.255.10.49154 x.x.x.130.53: 19873+ A? hostname. (37) 16:05:02.415973 IP 10.35.255.201 x.x.x.130: ICMP time exceeded in-transit, length 36 16:05:02.946458 IP 10.35.255.201 x.x.x.130: ICMP time exceeded in-transit, length 36 16:05:16.299198 IP 10.35.255.12.49154 x.x.x.53: 19709+ A? hostname. (40) 16:05:17.038419 IP 10.35.255.10.49154 x.x.x.53: 35638+ A? hostname. (37) 16:05:17.295820 IP 10.35.255.12.49154 x.x.x.53: 19709+ A? hostname. (40) (it also happens regularly, but not always for DNS lookups) After several days of head scratching I'm at a loss. Does anybody have any ideas? -Ronan ___ 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] VPN/VRF/NAT problem
I've got a VPN setup something like: Remote site --- Third Party Network --- Cisco 2811 --- Internet | | | |--- VPN ---| VRF X | ^ 10.x.y.zNAT to a.b.c.d The remote site is accessing a private network on the 2811 in VRF X. It's doing so using an IPSEC tunnel across the Internet via an untrusted third party network. All IP traffic leaving the remote site is pushed through the IPSEC tunnel and emerges in VRF X. Everything works as expected, except... Traffic egressing VRF X onto the Internet is not getting NATed. It's emerging with a 10.x.y.z address. We have other links in this VRF delivered via VPDN which do not have this problem. Their traffic is NATed correctly. The external interface on the 2811 is configured with 'ip nat outside'. The VPDN interfaces have 'ip nat inside'. I suspect the issue is arising as the traffic emerging from the VPN tunnel is not being considered for NAT. I'm NATing with: ip nat pool cust-X a.b.c.d a.b.c.d netmask 255.255.255.128 ip nat inside source list cust-X pool cust-X mapping-id 10 vrf X overload Am I missing something? Is there some way for me to tell the 2811 that traffic coming out of the tunnel is on the inside? (might match-in-vrf help?) Thanks in advance, -Ronan ___ 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] Which IP's belong to AS1234?
Hi Andy, On Fri, 25 Sep 2009, Andy Saykao wrote: This is why I needed to know what IP blocks belong to AS1234, so I could find out how much traffic was actually coming from AS1234 on our Internet link. Some (possibly all?) Whois servers can provide you with this information with: whois -h whois.ripe.net -i origin AS1234 % Information related to '194.110.40.0/23AS1234' route:194.110.40.0/23 descr:Imatran Voima Corporation descr:EUnet-FI aggregate origin: AS1234 mnt-by: AS790-MNT source: RIPE # Filtered % Information related to '194.110.44.0/23AS1234' route:194.110.44.0/23 descr:Carelcomp Power descr:EUnet-FI aggregate origin: AS1234 mnt-by: AS790-MNT source: RIPE # Filtered % Information related to '193.110.32.0/21AS1234' route:193.110.32.0/21 descr:Fortum origin: AS1234 mnt-by: TE-ENERGY-NOC source: RIPE # Filtered (an inverse query looking for objects with an origin of AS1234). I don't know how definitive it is - I've queried several large AS and got nothing back. It may be this functionality is only available in the RIPE whois server. There's also no guarantee the results are going to be current or accurate. -Ronan ___ 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] 2801 as console server
Hi Wim, On Wed, 16 Sep 2009, Holemans Wim wrote: -Is there a way to access the async line from within the router itself ? So just a telnet/ssh to the router and then something like 'connect line XXX' ? The connect command on the router seems an equivalent of telnet for outgoing tcp sessions and I don't see another command that could do this. I've done this in the past by connecting to an IP address on the router - the one assigned to the ethernet interface for example. We use a 2511 as a console server for last resort access to devices. In the worst case scenario if the ethernet interface is down we access it via the console port. If that's the case then the ethernet IP address won't be reachable. I've assigned a loopback IP address (192.168.0.0/32 I think) and use that instead (router telnet 192.168.0.0 2001) Hope this helps. -Ronan ___ 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] VPN Reverse Route Injection gateway in VRF
(First post on the list, so please be gentle!) I'm working on a VPN solution which creates multiple VRFs and assigns VPN traffic into a particular VRF based on it's ISAKMP profile and a dynamic crypto-map. The application in hand is a CPE management network - each CPE device builds a VPN tunnel back to a cisco router which constructs a CPE VRF. It all works works fine, up to a point. I use Reverse Route Injection to add routes into each VRF. I've static routes configured in the VRF directing outbound traffic via the correct front-door VRF: router show crypto route Routes created in table CPE 172.31.0.65/255.255.255.255 [1/0] via 1.2.3.4 tag 100 on Port-channel1.99 RRI router sh ip route vrf CPE S 172.31.0.65/32 [1/0] via 1.2.3.4 1.0.0.0/23 is subnetted, 1 subnets S 1.2.2.0 [1/0] via 1.2.2.1, Port-channel1.99 1.2.3.4 represents public IP addresses. I foresee a problem when I try to terminate VPN tunnels from CPE devices that are not on public IP addresses, but instead are part of another VRF using private IP ranges: router show crypto route Routes created in table CPE 172.31.1.0/255.255.255.255 [1/0] via 10.0.0.102 tag 100 on Port-channel1.1100 RRI router sh ip route vrf CPE S 172.31.1.0/32 [1/0] via 10.0.0.102 I can use reverse-route remote-peer A.B.C.D gateway I get the route to the remote host sent via the correct interface: router sh ip route vrf CPE S 172.31.1.0/32 [1/0] via 10.0.0.102 10.0.0.0/32 is subnetted, 1 subnets S 10.0.0.102 [1/0] via 10.0.0.4, Port-channel1.1100 My problem arises when we end up with overlapping address ranges in two different (front door) VRFs, so I would expect to see something like: router sh ip route vrf CPE S 172.31.1.0/32 [1/0] via 10.0.0.102 S 172.31.1.1/32 [1/0] via 10.0.0.102 10.0.0.0/32 is subnetted, 1 subnets S 10.0.0.102 [1/0] via 10.0.0.4, Port-channel1.1100 S 10.0.0.102 [1/0] via 10.0.0.5, Port-channel1.1101 The first being in VRF A, the second in VRF B. My questions are: - I expect this will be a problem, am I right? (ie there's no magic that will ensure packets for go via the right VRF and not get load balanced across two different VRFs, is there?) - Is there a way around the problem? Careful address assignment to avoid collisions is all I can think of. What I really need is to be able to specify an interface/VRF in the first route, for example: router sh ip route vrf CPE S 172.31.1.0/32 [1/0] via 10.0.0.102, Port-channel1.1100 (or vrf A) S 172.31.1.1/32 [1/0] via 10.0.0.102, Port-channel1.1101 (or vrf B) Any advice would be very welcome. -Ronan ___ 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/
