DNS Proxy with Juniper SRX

It is often when you come across deployments where branch users need reach an internal resource that is also mapped for external users via DNS however the problem start when user inside the corp is resolving that address over the public DNS he will get response of the public address of that resource and in order for him to reach that address packet will need to go out form the internal trust zone to outside and back in , this is what is called a DNS Split Horizon problem!

to fix that you can either use some static host configuration that is very unscaleable or use a DNS proxy and Internal forwarders, for that there are 2 main methods (with Juniper SRX):

Method 1 

Split DNS configuration where all DNS traffic is default to 8.8.8.8 with the exception of sguez.net that is using 198.168.1.200 (Internal DNS)

root@SRXv01# show system services dns | display set 
set system services dns dns-proxy interface ge-0/0/1.0
set system services dns dns-proxy default-domain * forwarders 8.8.8.8
set system services dns dns-proxy default-domain sguez.net forwarders 198.168.1.200


[edit]
root@SRXv01#

Important part when configuring dns-proxy over SRX is to enable the dns system service  

root@SRXv01# show security zones security-zone trust host-inbound-traffic | display set
set security zones security-zone trust host-inbound-traffic system-services dns

[edit]
root@SRXv01#

Method 2

Split DNS configuration where all DNS traffic is default to 8.8.8.8 with the exception of sguez.net that is using 198.168.1.200 (Internal DNS) and for external resolve via (external DNS) based on request source (clients IP's):

root@SRXv01# show system services dns dns-proxy | display set 
set system services dns dns-proxy interface ge-0/0/1.0
set system services dns dns-proxy view internal match-clients 192.168.0.0/16
set system services dns dns-proxy view internal domain sguez.net forwarders 192.168.1.200
set system services dns dns-proxy view external match-clients 172.24.190.114/28
set system services dns dns-proxy view external domain sguez.net forwarders 192.168.1.201

[edit]
root@SRXv01#

Also with that configuration do not forget the enable for dns system services

root@SRXv01# show security zones security-zone trust host-inbound-traffic | display set
set security zones security-zone trust host-inbound-traffic system-services dns

[edit]
root@SRXv01#

Verification for both:

Clear Cache:

root@SRXv01# run clear system services dns-proxy cache

Show Cache:

root@SRXv01# run show system services dns-proxy cache 

Clear Statistics:

root@SRXv01# run clear system services dns-proxy statistics 

Show Statistics: 

root@SRXv01# run show system services dns-proxy statistics  

Further Reference:

Configuring the Device as a DNS Proxy - Technical Documentation - Support - Juniper Networks 

CCDE Written

 

Just recently I had to re-certify my CCIE, so I have decided to go for the CCDE written this time. I have cleared that Exam so I would like to share some of the material I have used, the written encompass high level design focusing on VPN’s from all sort and types (MPLS , DMVPN , GETVPN , IPSEC , L2 , VPLS, MLD) and adding with that Security QoS and Management even storage. so you do not need to know how to configure everything (or anything for that meter) you must need to know where and what technology to use in different given situations.

To study for that exam I had done some reading (not cover to cover)

BGP Design and Implementation

MPLS and VPN Architectures (CCIP Edition)

In Addition I have used the excellent resource called ciscolive365 video lectures:

BRKMPL-2102 Deploy MPLS Based IP VPN

BRKRST-3310 Troubleshoot OSPF

BRKRST-2042 HA WAN Design

BRKRST-2310 OSPF Large Scale

BRKSEC-4054 DMVPN

BRKIPM-2444 EIGRP

Written check list:

https://learningnetwork.cisco.com/docs/DOC-13054

ISIS Database Reading

 

ISIS is simple to operate normally while everything is working, most common deployments are flat network based on L2, however when there is a problem and we need to start troubleshooting then people start to get lost.

So I would like to provide some tools on how to read ISIS database.

 

• notice to the “*” sign, that mean LSP was generated on the router you did the show command, you can see that host name from the show command match also host name on the LSPID,
• LSPID identified by hostname.xx-yy,  xx is normally 00 unless that LSP is pseudo node LSP generated by DIS , yy is representing the number of fragments for that LSP 00 – FF (max 255 fragments, plenty), most cases all the important information will be in 00 unless there are many fragments.
• LSP Holdtime is the amount of time an LSP will stay in database without any refresh.
• ATT/P/OL - 0/0/0, ATT bit or attached bit is used on L1/L2 connected to L1 node, if set to 1 L1 node will generate default route to the best L1/L2 node (best metric)
• ATT/P/OL - 0/0/0, OL bit or overload bit, in the past it was used when router was over loaded to set all links on the router as unusable, preventing others from transiting, that node, today it is used mostly to wait for bgp convergence.

 

P_london_someisp.net#show isis database 
IS-IS Level-2 Link State Database:
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
P_london_somei.00-00* 0x00000005   0x65C5        1177              0/0/0
P_dublin_somei.00-00  0x00000004   0x8346        1176              0/0/0
P_cyprus_somei.00-00  0x00000005   0x5634        1183              0/0/0
P_LA_someisp.n.00-00  0x00000005   0xDE33        1175              0/0/0
PE_newyork_som.00-00  0x00000003   0x2EF0        1179              0/0/0
PE_telaviv_som.00-00  0x00000004   0x2877        1181              0/0/0
PE_Jerusalem_s.00-00  0x00000002   0x2994        1172              0/0/0
PE_Jerusalem_s.02-00  0x00000001   0x2ED2        1171              0/0/0

From the database each router build a topology using SPF (dijkstra algorithm), if I would like to understand how to get from one router to another I can look into the ISIS database detail and understand that:

For the example, I would like to see only with the database, how to get from my self
to PE_telaviv without looking into the topology or routing table (just for fun): 
Notice that according to my LSP I can see the neighbors I am connected to, and the net address
for each link along with metric.
P_london_someisp.net#$atabase  level-2 det P_london_someisp.net.00-00   
IS-IS Level-2 LSP P_london_somei.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
P_london_somei.00-00* 0x00000006   0x63C6        409               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 
  Hostname: P_london_someisp.net
  IP Address:   1.1.1.1
  Metric: 10         IS-Extended P_dublin_somei.00
  Metric: 10         IS-Extended P_cyprus_somei.00
  Metric: 10         IS-Extended P_LA_someisp.n.00
  Metric: 10         IS-Extended PE_newyork_som.00
  Metric: 10         IP 1.1.1.1/32
  Metric: 10         IP 10.100.1.4/30
  Metric: 10         IP 10.100.1.16/30
  Metric: 10         IP 10.100.1.20/30
  Metric: 10         IP 10.100.1.24/30
P_london_someisp.net#
 
 
now if I take the first neighbor from my LSP P_dublin and look into his LSP:
notice that one of his neighbors is PE_telaviv.
So 10 to reach dublin + 10 to reach telaviv = 20 total cost from london to telaviv 
I have taken the next neighbor cyprus and it looks like we have also 20 metric path using 
cyprus, so we will have load sharing between them.
notice that P_LA and PE_newyork does not have direct link to PE_telaviv, that mean we do not
need to explorer more in that direction as any route using them will have higher cost.
 
 
P_london_someisp.net#$atabase  level-2 det P_dublin_someisp.net.00-00
IS-IS Level-2 LSP P_dublin_somei.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
P_dublin_somei.00-00  0x00000006   0x7F48        1077              0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 
  Hostname: P_dublin_someisp.net
  IP Address:   2.2.2.2
  Metric: 10         IS-Extended P_london_somei.00
  Metric: 10         IS-Extended P_cyprus_somei.00
  Metric: 10         IS-Extended P_LA_someisp.n.00
  Metric: 10         IS-Extended PE_telaviv_som.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.100.1.0/30
  Metric: 10         IP 10.100.1.12/30
  Metric: 10         IP 10.100.1.16/30
  Metric: 10         IP 10.100.1.36/30
P_london_someisp.net#$atabase  level-2 det P_cyprus_someisp.net.00-00
IS-IS Level-2 LSP P_cyprus_somei.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
P_cyprus_somei.00-00  0x00000007   0x5236        854               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 
  Hostname: P_cyprus_someisp.net
  IP Address:   3.3.3.3
  Metric: 10         IS-Extended P_london_somei.00
  Metric: 10         IS-Extended P_dublin_somei.00
  Metric: 10         IS-Extended P_LA_someisp.n.00
  Metric: 10         IS-Extended PE_telaviv_som.00
  Metric: 10         IS-Extended PE_Jerusalem_s.02
  Metric: 10         IP 3.3.3.3/32
  Metric: 10         IP 10.100.1.0/30
  Metric: 10         IP 10.100.1.4/30
  Metric: 10         IP 10.100.1.8/30
  Metric: 10         IP 10.100.1.32/30
  Metric: 10         IP 20.0.0.0/24
P_london_someisp.net#$atabase  level-2 det P_LA_someisp.net.00-00    
IS-IS Level-2 LSP P_LA_someisp.n.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
P_LA_someisp.n.00-00  0x00000007   0xDA35        690               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 
  Hostname: P_LA_someisp.net
  IP Address:   4.4.4.4
  Metric: 10         IS-Extended P_london_somei.00
  Metric: 10         IS-Extended P_dublin_somei.00
  Metric: 10         IS-Extended P_cyprus_somei.00
  Metric: 10         IS-Extended PE_newyork_som.00
  Metric: 10         IP 4.4.4.4/32
  Metric: 10         IP 10.100.1.8/30
  Metric: 10         IP 10.100.1.12/30
  Metric: 10         IP 10.100.1.20/30
  Metric: 10         IP 10.100.1.28/30
P_london_someisp.net#show isis database  level-2 det PE_newyork_someisp.net.00$
IS-IS Level-2 LSP PE_newyork_som.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
PE_newyork_som.00-00  0x00000005   0x2AF2        499               0/0/0
  Area Address: 49.0001
  NLPID:        0xCC 
  Hostname: PE_newyork_someisp.net
  IP Address:   5.5.5.5
  Metric: 10         IS P_london_somei.00
  Metric: 10         IS P_LA_someisp.n.00
  Metric: 10         IS-Extended P_london_somei.00
  Metric: 10         IS-Extended P_LA_someisp.n.00
  Metric: 10         IP 5.5.5.5/32
  Metric: 10         IP 10.100.1.24/30
  Metric: 10         IP 10.100.1.28/30
  Metric: 10         IP 5.5.5.5 255.255.255.255
  Metric: 10         IP 10.100.1.24 255.255.255.252
  Metric: 10         IP 10.100.1.28 255.255.255.252
 
 
To see the topology now and see if we are on the right track, notice that we are correct 20 metric
one with dublin and the other trough cyprus with 20 metric doing load sharing.
 
 
P_london_someisp.net#show isis topology 
IS-IS paths to level-2 routers
System Id            Metric     Next-Hop             Interface   SNPA
P_london_someisp.net --
P_dublin_someisp.net 10         P_dublin_someisp.net Se1/2       *HDLC*         
P_cyprus_someisp.net 10         P_cyprus_someisp.net Se1/1       *HDLC*         
P_LA_someisp.net     10         P_LA_someisp.net     Se1/0       *HDLC*         
PE_newyork_someisp.ne10         PE_newyork_someisp.neMu1         *PPP*          
PE_telaviv_someisp.ne20         P_dublin_someisp.net Se1/2       *HDLC*         
                                P_cyprus_someisp.net Se1/1       *HDLC*         
PE_Jerusalem_someisp.20         P_cyprus_someisp.net Se1/1       *HDLC*         

MPLS Deployment reasons

1) Faster convergence, in the old days that was a valid reason due to the relatively complex forwarding task that required more resources then Label forwarding. Today non relevant

2) RFC 1483 the newer 2684 AAL5 ATM Adaptation Layer 5 the implementation of IP over ATM

3) BGP Core Free on the SP network, as with MPLS lookup is done based on Labels and not destination address there is no need to have the BGP table in the Core for external prefixes lookup's. this is a massive change from the requirement that Every router in the core must have BGP enabled (cpu and memory intensive load) to only the edge router have BGP enabled mean higher performance and capability.

Note: edge routers still need to have the BGP routing tables, edge routers are translating between ip routing decision to label based decisions.

4) Deployment scalability, when we face with large scale client to deploy (client that connect with 50 - 300 sites and more) we need to have under the consideration the deployment scalability and management, with that in mind 2 models of deployment are optional:

a) VPN Overlay - creating a point to point connection over the SP network, can be achieved in layer 1, 2 or 3.

Layer 1 TDM E1 T1... Layer 2 ATM FR... Layer 3 GRE, IPIP...

b) Peer to Peer - creating a connection between sites trough the ISP and with him, what I mean is that the SP need to join the client network and to achieve client privacy the SP need to manage acl's and routing updates, not very scalable and a lot of overhead. notice that in addition to the disadvantage for the SP on the additional management overhead and complexity there is the client control (doesn't have any) of his layer 3 network trough the SP.

With MPLS the VPN allow the Peer to Peer bad model to have advantage over the Overlay model where in the MPLS we use VRF Virtual Routing Forwarding separators between each network and the configuration is done only on each new site. meaning that if I am an SP and I have 3 client (Cisco, Microsoft, Verizon) each vrf will have a unique color vrf Cisco, vrf Microsoft and vrf Verizon, and to join a new branch is only to color this branch traffic accordingly, so the main work is done in the initial design and implementation and any new addition is actually very simple to add.

5) TE - traffic engineering is a small phrase for a very big spectrum of options, normally traffic routing is decided at each point separately and usually the best route is chosen according to the shortest path to destination, using TE we can make the routing decision based on multiple criteria options. allowing the traffic to fully utilize network capability.

FRR - Fast ReRouting is a very good feature that allow you to detect and reroute based on router availability in less than 50ms Very important in high sensitive traffic like VoIP.