Active/Standby Data Centre Network Design using GNS3/Virtualbox/JUNOS and Cisco – Part-3

In this tutorial, I am going to explain the Cloud firewall configuration and connectivity in more detail.

Final Topology

 

  • Interface e1/0 (Gi0/0) on both Firewalls is configured as trunk interface to carry multiple VLAN by creating sub-interfaces in trusted zone towards core switch karais3 fa1/0 and lahoris3 fa1/0.
  • Interface e2/0 (Gi0/1) on both Firewalls is configured as sub-interface and placed in un-trusted zone similarly towards core switch karais3 fa1/2 and lahorcf3 fa1/2. This link will carry traffic to the internet.
  • Both Firewalls are connected to the Core switch (karais3 and lahoris3) on trunk ports fa1/2 and fa1/0 to carry multiple VLAN.
  • To test connectivity between LAN interfaces behind Firewall, I have placed VPCS server named Service-vlan102 IP address 10.141.33.98/28 under VLAN 102 on Access port Fa1/14 on karais3 switch at dc-karachi. Similarly Service-vlan103 10.141.212.147/28 is connected to lahoris3 switch port F1/14 at dc-lahore under VLAN 103. These two Service machines are in LAN subnets behind cloud firewalls for which we have created static routes in our VPN configuration as well (vpn12729 and vpn12730). So Ideally these two host should be able to ping each other.

Configuration of both Firewalls (karacf3 and lahorcf3) is below:

karacf3#
!
interface GigabitEthernet0/0.100
 vlan 100
 nameif s2s
 security-level 100
 ip address 10.144.213.92 255.255.255.248 
!
interface GigabitEthernet0/0.102
 vlan 102
 nameif service
 security-level 100
 ip address 10.141.33.97 255.255.255.240 
!
route s2s 10.141.212.144 255.255.255.240 10.144.213.90 1
route s2s 10.144.253.120 255.255.255.248 10.144.213.90 1
!

lahorcf3
========

!
!
interface GigabitEthernet0/0.101
 vlan 101
 nameif s2s
 security-level 100
 ip address 10.144.253.124 255.255.255.248 
!
interface GigabitEthernet0/0.103
 vlan 103
 nameif service
 security-level 100
 ip address 10.141.212.145 255.255.255.248 
!
route s2s 10.141.33.96 255.255.255.240 10.144.253.122 1
route s2s 10.144.213.88 255.255.255.248 10.144.253.122 1
!

To test connectivity between both Service-vlan102 & Service-vlan103  test machines in dc-karahi and dc-lahore, I performed following tests:

  1. PING from karair3 VRF vpn12729 to the Firewall karacf3 interface 10.144.213.92/29 – testing okay.
  2. PING from karair3 VRF vpn12729 to the Firewall lahorcf3 interface 10.144.253.124/29 -testing okay.
  3. PING from karair3 VRF vpn12729 to Service-vlan102 test machine in Service VLAN 102 – IP address 10.141.33.98/28 – testing okay in dc-karachi.
  4. PING from Service-vlan102 test machine in Service VLAN 102 at dc-karachi to Service-vlan103 test machine in VLAN 103 at dc-lahore – testing okay.

NOTE:

If you are failing to ping between the test machines then check, If PE are receiving the next-hop information in the routing table. Also Router-Reflector has next-hop information in bgp3.l3pn.0 table as well. If you cannot PING, then  this means though PE have received the routes from the RR but did not populate their vpn12730.inet.0 and vpn12729.inet.0 table with next-hop information. Hence, no transport MPLS label assigned. This means PING was being dropped at Router Reflector due to that fact that PE doesn’t know what is the next hop.

To fix, you can try few things:

  1. Add the next-hop resolution to inet.0 or inet.3. Please check Juniper documentation for Route Reflector next-hop resolution. You may only need to use if your Route Reflector is not within the Core. Please see documentation from Juniper or search on internet for various resources.
  2. Make sure the MP-BGP peering between PE (karair3 and lahorir3) to RR (pakcore) is sourced from loopback interfaces.
  3. Reboot the P and PE routers one by one and see if this makes difference:

For our configuration, I am seeing routing table at Route-Reflector as following which is showing we have learned the routes from both PE routers for vpn12739 and vpn12730:

root@pakcore> show route table bgp.l3vpn.0 
bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
65000:12729:10.141.33.96/28                
                   *[BGP/170] 00:03:09, localpref 100, from 1.1.1.1
                      AS path: I
                    > to 40.50.60.1 via em0.0, Push 16
65000:12729:10.144.213.88/29                
                   *[BGP/170] 00:03:09, localpref 100, from 1.1.1.1
                      AS path: I
                    > to 40.50.60.1 via em0.0, Push 16
65000:12730:10.141.212.144/28                
                   *[BGP/170] 00:03:05, localpref 100, from 3.3.3.3
                      AS path: I
                    > to 10.20.30.1 via em1.0, Push 16
65000:12730:10.144.253.120/29                
                   *[BGP/170] 00:03:05, localpref 100, from 3.3.3.3
                      AS path: I
                    > to 10.20.30.1 via em1.0, Push 16
root@pakcore>

If I look at the vpn12729 routing table on PE karair3, I have now two MPLS label allocated to the routes we have learned from the remote dc. One label is to identify the VPN in MPLS core. And Top level label is the MPLS transport label ( that is LDP) in our case.

root@karair3> show route table vpn12729.inet.0    
vpn12729.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.141.33.96/28    *[Static/5] 00:57:06
                    > to 10.144.213.92 via em3.100
10.141.212.144/28  *[BGP/170] 00:56:32, localpref 100, from 2.2.2.2
                      AS path: I
                    > to 40.50.60.2 via em0.0, Push 16, Push 299792(top)
10.144.213.88/29   *[Direct/0] 00:57:06
                    > via em3.100
10.144.213.90/32   *[Local/0] 00:57:07
                      Local via em3.100
10.144.253.120/29  *[BGP/170] 00:56:32, localpref 100, from 2.2.2.2
                      AS path: I
                    > to 40.50.60.2 via em0.0, Push 16, Push 299792(top)

Since all looks good at the routing table. I am getting PING response from PE karair3 to local LAN and also to the remote LAN.

root@lahorir3> ping routing-instance vpn12730 10.141.33.98 
PING 10.141.33.98 (10.141.33.98): 56 data bytes
64 bytes from 10.141.33.98: icmp_seq=0 ttl=64 time=12.530 ms
64 bytes from 10.141.33.98: icmp_seq=1 ttl=64 time=1.741 ms
64 bytes from 10.141.33.98: icmp_seq=2 ttl=64 time=11.981 ms
64 bytes from 10.141.33.98: icmp_seq=3 ttl=64 time=2.722 ms
64 bytes from 10.141.33.98: icmp_seq=4 ttl=64 time=2.423 ms
64 bytes from 10.141.33.98: icmp_seq=5 ttl=64 time=2.371 ms
^C
--- 10.141.33.98 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.741/5.628/12.530/4.698 ms
root@lahorir3>
root@lahorir3> ping routing-instance vpn12730 10.141.212.147  
PING 10.141.212.147 (10.141.212.147): 56 data bytes
64 bytes from 10.141.212.147: icmp_seq=0 ttl=64 time=1.855 ms
64 bytes from 10.141.212.147: icmp_seq=1 ttl=64 time=1.768 ms
64 bytes from 10.141.212.147: icmp_seq=2 ttl=64 time=1.350 ms
64 bytes from 10.141.212.147: icmp_seq=3 ttl=64 time=1.346 ms
^C
--- 10.141.212.147 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.346/1.580/1.855/0.234 ms
root@lahorir3>

We have Service LAN communication in place between two VDC. Both host in Service LAN can PING each other.

Advertisements

One thought on “Active/Standby Data Centre Network Design using GNS3/Virtualbox/JUNOS and Cisco – Part-3

  1. Pingback: Active/Active Data Centre Network Design using GNS3/Virtualbox/JUNOS and Cisco – Part-4 | Markhorr Networks

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s