suiCCIEde

Ciscoman's notes (Записки цыщика c дипломом)

I'm Cisco Champion Community member for 2017!

I'm Cisco Champion Community member for 2017!
"Cisco Champions are passionate about Cisco and happy to share our knowledge, experience, and feedback."

среда, 7 июня 2017 г.

DMVPN and how to exclude particular spoke from redirect process


I haven't posted anything on this blog for quite a while, but I got good occasion to write something simple but useful finally because today I was contacted by my former colleague with question. He was searching for advice with DMVPN phase 3 cloud. His issue was with particular spoke that had unreliable ISP and that led to unstable communication with another spokes via dynamic spoke-to-spoke tunnels. Pretty common situation for remote offices located somewhere far far away with lack of good Internet access service.
Actually there are two solutions for this problem. First one is obvious: you can create separate point-to-point tunnel on the hub and affected spoke, but as always that's only one solution and sometimes this is not acceptable for some reasons (e.g. you want to preserve spoke-to-spoke dynamic tunnels only between particular spokes, but not all traffic from affected spoke).
So here is my lab setup to deal with this problem that I did for my friend. Please note there is no common frond-door VRF configuration as should be in real-life scenario, IPSEC profiles or anything else, this is just for demonstration purpose, so there is no need to point me to any DMVPN configuration improvements ;) Router R1 is a hub, router R2, R3 and R4 are spokes and R3 for example is affected spoke with communication problems. From R3 we want it to communicate with another LAN segments only via hub router R1. R4 and R2 should communicate via dynamic tunnel as normal. G0/0 interfaces on this routers are underlay ISP-facing interfaces, G0/1 interfaces are LAN facing interfaces.

 R1 configuration:

 interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 ip ospf 1 area 0
!
interface Tunnel0
 ip address 172.16.0.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp redirect
 ip ospf network broadcast
 ip ospf priority 255
 ip ospf database-filter all out
 ip ospf 1 area 0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
!
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.0
!
router ospf 1
 passive-interface GigabitEthernet0/1

R2 configuration:

 interface GigabitEthernet0/1
 ip address 192.168.2.2 255.255.255.0
 ip ospf 1 area 0
!
interface Tunnel0
 ip address 172.16.0.2 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip nhrp interest 100
 ip nhrp nhs 172.16.0.1 nbma 192.0.2.1 multicast
 ip nhrp shortcut
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf 1 area 0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
!
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.0
!
router ospf 1
 passive-interface GigabitEthernet0/1
!
access-list 100 deny   ip any 192.168.3.0 0.0.0.255
access-list 100 permit ip any any

!
ip route 0.0.0.0 0.0.0.0 172.16.0.1 254

R3 configuration:

 interface GigabitEthernet0/1
 ip address 192.168.3.3 255.255.255.0
 ip ospf 1 area 0
!
interface Tunnel0
 ip address 172.16.0.3 255.255.255.0
 no ip redirects
 ip nhrp network-id 1
 ip nhrp interest none
 ip nhrp nhs 172.16.0.1 nbma 192.0.2.1 multicast
 ip nhrp shortcut
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf 1 area 0
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
!
interface GigabitEthernet0/0
 ip address 192.0.2.3 255.255.255.0
!
router ospf 1
 passive-interface GigabitEthernet0/1
!
ip route 0.0.0.0 0.0.0.0 172.16.0.1 254

Also there is R4 router with exactly the same configuration as on R2. It has G0/1 interface configured with address 192.168.4.4 and Tunnel0 interface with 172.16.0.4 address, so configuration of R4 excluded for sake of brevity

Now let's check the behaviour:

R2#traceroute 192.168.3.3 source g0/1 numeric
Type escape sequence to abort.
Tracing the route to 192.168.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.1 1 msec 1 msec 1 msec
  2 172.16.0.3 1 msec 1 msec 1 msec

R2#traceroute 192.168.4.4 source g0/1 numeric
Type escape sequence to abort.
Tracing the route to 192.168.4.4
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.4 1 msec 1 msec 1 msec

R3#traceroute 192.168.2.2 numeric source g0/1
Type escape sequence to abort.
Tracing the route to 192.168.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.1 1 msec 1 msec 1 msec
  2 172.16.0.2 1 msec 1 msec 1 msec

R4#traceroute 192.168.2.2 source g0/1 numeric
Type escape sequence to abort.
Tracing the route to 192.168.2.2
VRF info: (vrf in name/id, vrf out name/id)
  1 172.16.0.2 1 msec 1 msec 1 msec

As you can see, everything works as expected, R2 and R3 communicate via hub while R2 and R4 communicate directly via dynamic tunnel.

So the most valuable but quiet simple parts here are commands "ip nhrp interest none" and  "ip nhrp interest 100". First one is used on affected spoke to actually disable NHRP redirection for any traffic, and the second one is use on any other spoke router to disable redirection for traffic going to LAN subnet of affected spoke. You can follow the link to Cisco Systems IOS documentation for mentioned command: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr/command/ipaddr-cr-book/ipaddr-i4.html#wp3767054477 for more detailed description. If your IOS version doesn't support "ip nhrp interest none", you can use "ip nhrp interest ACL_NAME" with "deny any" ACL to achieve the same behavior. Actually you can use similar approach for DMVPN phase 2 certainly.


Hope that helps somebody.

вторник, 25 октября 2016 г.

Zscaler cloud proxy and obvious logical flaw in default PAC file template

 Here is the default PAC file template from Zscaler cloud security solution:

function FindProxyForURL(url, host) {
    var privateIP = /^(0|10|127|192\.168|172\.1[6789]|172\.2[0-9]|172\.3[01]|169\.254|192\.88\.99)\.[0-9.]+$/;
    var resolved_ip = dnsResolve(host);

    /* Don't send non-FQDN or private IP auths to us */
    if (isPlainHostName(host) || isInNet(resolved_ip, "192.0.2.0","255.255.255.0") || privateIP.test(host)) {
        return "DIRECT";
    }

    /* FTP goes directly */
    if (url.substring(0,4) == "ftp:") {
        return "DIRECT";
    }

    /* Updates are directly accessible */
    if (((localHostOrDomainIs(host, "trust.zscaler.com")) ||
        (localHostOrDomainIs(host, "trust.zscaler.net")) ||
        (localHostOrDomainIs(host, "trust.zscalerone.net")) ||
        (localHostOrDomainIs(host, "trust.zscalertwo.net")) ||
        (localHostOrDomainIs(host, "trust.zscloud.net")) ) &&
        (url.substring(0,5) == "http:" || url.substring(0,6) == "https:")){
        return "DIRECT";
    }

    /* Default Traffic Forwarding. Forwarding to Zen on port 80, but you can use port 9400 also */
    return "PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80; DIRECT";
}
 I don't know how, but quiet obvious error crept here, highlighted with bold:


    var resolved_ip = dnsResolve(host);

    /* Don't send non-FQDN or private IP auths to us */
    if (isPlainHostName(host) || isInNet(resolved_ip, "192.0.2.0","255.255.255.0") || privateIP.test(host)) {
And here is the screenshot for sake of proof:




The point being here is that privateIP.test should check resolved_ip variable against regexp instead of host. That's it. So the correct variant is here:

    var resolved_ip = dnsResolve(host);

    /* Don't send non-FQDN or private IP auths to us */
    if (isPlainHostName(host) || isInNet(resolved_ip, "192.0.2.0","255.255.255.0") || privateIP.test(resolved_ip)) {

Strictly speaking, this is not only Zscaler's default PAC template error, but somehow this code snippet was spread widely across the Internet.

For example, the same error migrated here:

http://itzecurity.blogspot.ru/2016/05/pac-file-recommendation-warnings-and.html

and here:

http://findproxyforurl.com/pac-code-snippets-examples/

 and even here:

https://support.google.com/chrome/a/answer/3504945?hl=en

Certainly, at the time you will check it, error may be fixed. But this is good sign that means my blog post was notified.

Hope this helps somebody.

среда, 7 сентября 2016 г.

Quick note: How to check http server reachability if you can't resolve DNS name

Note: How to check http server reachability if you can't resolve DNS name:

Variant number one:

$ telnet 127.0.0.1 80
GET / HTTP/1.1
host: www.example.com
 
Variant number two with curl:
 
$ curl --resolve www.example.com:80:127.0.0.1 http://www.example.com/ 
 
Better varian for older curl:
 
curl -k --verbose --header 'Host: www.example.com' 'https://127.0.0.1:443/' 
 
Even shorter:
 
curl -kvH 'Host: www.example.com' 'https://127.0.0.1:443/'  

пятница, 8 апреля 2016 г.

Tricks: Maximum Recursive Route Lookups IOS vs IOS XR

Just small note, primarily for myself because long time ago I was absolutely sure that maximum recursive route lookup was limited to 3rd level depth (Maybe it was changed?), actually, for IOS 15.4(2)T1 tested that 9th lookup is too many:

Check it your own if you want ;)

192.168.0.0/24 - connected network in my example:

ip route 1.1.1.1 255.255.255.255 1.1.1.2
ip route 1.1.1.2 255.255.255.255 1.1.1.3
ip route 1.1.1.3 255.255.255.255 1.1.1.4
ip route 1.1.1.4 255.255.255.255 1.1.1.5
ip route 1.1.1.5 255.255.255.255 1.1.1.6
ip route 1.1.1.6 255.255.255.255 1.1.1.7
ip route 1.1.1.7 255.255.255.255 192.168.0.2



1.1.1.1/32, epoch 0
  recursive via 1.1.1.2
    recursive via 1.1.1.3
      recursive via 1.1.1.4
        recursive via 1.1.1.5
          recursive via 1.1.1.6
            recursive via 1.1.1.7
              recursive via 192.168.0.2
                recursive via 192.168.0.0/24
                  Too many (9) levels of IP recursion truncating
1.1.1.2/32, epoch 0
  1 RR source [no flags]
  recursive via 1.1.1.3
    recursive via 1.1.1.4
      recursive via 1.1.1.5
        recursive via 1.1.1.6
          recursive via 1.1.1.7
            recursive via 192.168.0.2
              recursive via 192.168.0.0/24
                attached to GigabitEthernet0/0

  
And for IOS XR according to the documentation it limited to 128 and can be configured with recursion-depth-max command in the range of 5 to 16.

вторник, 22 декабря 2015 г.

Radius configuration trick to allow "CLID-like" filtering on ACS for l2tp/pptp

Here is "trcik" to allow l2tp/pptp client access filtering based on their IP-address for ACS 5.X
1) configure NAS with "vpdn aaa attribute nas-ip-address vpdn-tunnel-client"
This command will allow IOS to send client ip address in attribute 4 like this output from debug:
RADIUS:  NAS-IP-Address      [4]   6  1.2.3.4
2) Use "compound condition"  in ACS Access Policies - Authorization rules to match based on this attribute.
Tested on 15.1(4)M6 IOS for 7200 series router.


воскресенье, 20 декабря 2015 г.

CCIE R&S

Finally I nailed it. I passed on the first try after so much time spent since 2013... Just since June 2015 I was at both Cisco360 workshops and spent more than 400 hours labbing (workshops time is not counted) and more than 300 hours VoD from different training vendors...
Now I feel completely drained and squeezed like a lemon, time to make a pause.

воскресенье, 4 октября 2015 г.

Cisco IOS tcl simple script to use instead of interface level configuration

Example:

tclsh
set area 0
ios_config "router os 1" "router-id [ lindex [exec "sh ip int b lo0 | exclude face"] 1 ] "
foreach i {
Lo0
Et0/0
Et0/1
} { ios_config "router os 1" "net [ lindex [exec "sh ip int b $i | exclude face"] 1 ] 0.0.0.0 area $area"
}



Постоянные читатели

Поиск по этому блогу