In this tutorial, I am going to explain the Cloud firewall configuration and connectivity in more detail.
- 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:
- PING from karair3 VRF vpn12729 to the Firewall karacf3 interface 10.144.213.92/29 – testing okay.
- PING from karair3 VRF vpn12729 to the Firewall lahorcf3 interface 10.144.253.124/29 -testing okay.
- 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.
- 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.
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:
- 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.
- Make sure the MP-BGP peering between PE (karair3 and lahorir3) to RR (pakcore) is sourced from loopback interfaces.
- 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 220.127.116.11 AS path: I > to 18.104.22.168 via em0.0, Push 16 65000:12729:10.144.213.88/29 *[BGP/170] 00:03:09, localpref 100, from 22.214.171.124 AS path: I > to 126.96.36.199 via em0.0, Push 16 65000:12730:10.141.212.144/28 *[BGP/170] 00:03:05, localpref 100, from 188.8.131.52 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 184.108.40.206 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 220.127.116.11 AS path: I > to 18.104.22.168 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 22.214.171.124 AS path: I > to 126.96.36.199 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.