GNS3 + Docker: Internet modem container


Goal: Deploy internet modem for GNS3 topology using Docker container. The container uses iptables to perform NAT (masquerading) and dnsmasq as DHCP server for LAN interfaces.

Used Docker images:

GNS3 host preparation : This is performed on GNS3 linux host

From GNS3 host console, create a tap interface (tap0) and put it along with the physical interface (eth0) in a bridge (ex: ovsbr0):

ip tuntap add dev tap0 mode tap user <username>

sudo ovs-vsctl add-br ovsbr0

sudo ovs-vsctl add-port ovsbr0 tap0

You can use either linux bridge (brctl command) or OpenVswitch bridge (ovs-vsctl command)

sudo ovs-vsctl show

579f91e6-efc3-480b-96f3-b9f21bfbafb4

Bridge “ovsbr0”

Port “tap0”

Interface “tap0”

Port “ovsbr0”

Interface “ovsbr0”

type: internal

Port “eth0”

Interface “eth0”

ovs_version: “2.3.0”

Remove ip address from eth0 (or release dhcp parameters) then reconfigure IP address and default gateway (or request dhcp) for the ovs bridge ovsbr0

Import containers

1- Create a new docker template in GNS3. Create new docker template: Edit > Preferences > Docker > Docker containers and then “New”.

Choose “New image” option and the name ajnouri/internet

Screenshot - 170716 - 18:49:03

Accept all default parameters.

2- Create a new docker template in GNS3. Create new docker template: Edit > Preferences > Docker > Docker containers and then “New”.

Choose “New image” option and the name gns3/openvswitch

Screenshot - 170716 - 18:49:12

Set the number of interfaces to eight and accept default parameters with “next” until “finish”.

3- Same for end host container. From GNS3, create new docker template Edit > Preferences > Docker > Docker containers and then “New”.

Choose “New image” option and the name gns3/endhost.

Screenshot - 170716 - 18:49:21

Next you can choose a template name for the container, in this case I renamed it as “dvpc”.

Accept default parameters with “next” until “finish”.

GNS3 Topology

Insert a cloud to the topology and map it to tap0

Screenshot - 170716 - 18:49:31

Build the below topology

Screenshot - 170716 - 18:49:40

Configure containers network interfaces:

Internet container ajnouri/Internet-1

Screenshot - 170716 - 18:50:33

End host container dvpc-1

Screenshot - 170716 - 18:50:49

The WAN interface of the Internet container should have been assigned an IP and gateway from your physical network (connected to internet).

Start the nat.sh script from /data directory

You will be asked to set the LAN and WAN interfaces as well as the IP range for dhcp clients connected to LAN interface, then the script will start dnsmasq and set iptables for NAT (masquerade)

ajnouri/internet-1 console

Screenshot - 170716 - 18:51:15

ajnouri/dvpc-1 console

Screenshot - 170716 - 18:51:37

Other dhcp parameters assigned to the client are taken from Internet device WAN interface DHCP parameters.

Connectivity check

Selection_110

Let’s have fun! Now that we have internet connectivity, install a text-based browser package on the end host container

Selection_111

Start elinks and browse Internet

Selection_112

For more comfortable browsing experience, you can use the image gns3/webterm.

Create a new Docker template

Selection_113

Choose vnc as the console type to allow GUI browsing of Firefox

Selection_114

And keep the remaining default parameters.

Insert the image and connect it to the topology as follow:

Selection_115

Set the container interface for dhcp client

Selection_116

Start the stopped containers and console (vnc) to Webterm container.

(gns3/openvswitch doesn’t need any configuration)

Selection_117

You should get this

Selection_118

 

 

 

 

 

Advertisements

IPv4 and IPv6 dual-stack PPPoE


The lab covers a scenario of adding basic IPv6 access to an existing PPPoE (PPP for IPv4).

PPPoE is established between CPE (Client Premise Equipment) the PPPoE client and the PPPoE server also known as BNG (Broadband Network Gateway).

ipv4 and IPv6 dual-stack PPPoe

Figure1: ipv4 and IPv6 dual-stack PPPoe

PPPoE server plays the role of the authenticator (local AAA) as well as the authentication and address pool server (figure1). Obviously, a higher centralized prefix assignment and authentication architecture (using AAA RADIUS) is more scalable for broadband access scenarios (figure2).

For more information about RADIUS attributes for IPv6 access networks, start from rfc6911 (http://www.rfc-editor.org/rfc/rfc6911.txt).

Figure2: PPPoE with RADIUS

Figure2: PPPoE with RADIUS

PPPoE for IPv6 is based on the same PPP model as for PPPoE over IPv4. The main difference in deployment is related to the nature of the routed protocol assignment to CPEs (PPPoE clients).

  • IPv4 in routed mode, each CPE gets its WAN interface IP centrally from the PPPoE server and it’s up to the customer to deploy an rfc1918 prefix to the local LAN through DHCP.
  • PPPoE client gets its WAN interface IPv6 address through SLAAC and a delegated prefix to be used for the LAN segment though DHCPv6.

Animation: PPP encapsulation model

Let’s begin with a quick reminder of a basic configuration of PPPoE for IPv4.

PPPoE for IPv4

pppoe-client WAN address assignment

The main steps of a basic PPPoE configuration are:

  • Create a BBAG (BroadBand Access Group).
  • Tie the BBAG to virtual template interface
  • Assign a loopback interface IP (always UP/UP) to the virtual template.
  • Create and assign the address pool (from which client will get their IPs) to the virtual template interface.
  • Create local user credentials.
  • Set the authentication type (chap)
  • Bind the virtual template interface to a physical interface (incoming interface for dial-in).
  • The virtual template interface will be used as a model to generate instances (virtual access interfaces) for each dial-in session.
Figure3: PPPoE server

Figure3: PPPoE server model

pppoe-server

ip local pool PPPOE_POOL 172.31.156.1 172.31.156.100
!
bba-group pppoe BBAG
virtual-template 1
!
interface Virtual-Template1
ip unnumbered Loopback0
ip mtu 1492
peer default ip address pool PPPOE_POOL
ppp authentication chap callin

!

interface FastEthernet0/0

pppoe enable group BBAG

pppoe-client

interface FastEthernet0/1
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface FastEthernet1/0
ip address 192.168.0.201 255.255.255.0
!
interface Dialer1
mtu 1492
ip address negotiated

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication chap callin

ppp chap hostname pppoe-client

ppp chap password 0 cisco

Figure4: PPPoE client model

Figure4: PPPoE client model


As mentioned in the beginning, DHCPv4 is deployed at the CPE device to assign rfc1819 addresses to LAN clients and then translated, generally using PAT (Port Address Translation) with the assigned IPv4 to the WAN interface.

You should have the possibility to configure static NAT or static port-mapping to give public access to internal services.

Address translation

interface Dialer1
ip address negotiated
ip nat outside
!
interface FastEthernet0/0
ip address 192.168.4.1 255.255.255.224
ip nat inside
!
ip nat inside source list NAT_ACL interface Dialer1 overload
!

ip access-list standard NAT_ACL

permit any

pppoe-client LAN IPv4 address assignment

pppoe-client

ip dhcp excluded-address 192.168.4.1
!
ip dhcp pool LAN_POOL
network 192.168.4.0 255.255.255.224
domain-name cciethebeginning.wordpress.com
default-router 192.168.4.1
!
interface FastEthernet0/0
ip address 192.168.4.1 255.255.255.224

PPPoE for IPv6

pppoe-client WAN address assignment

All IPv6 prefixes are planned from the 2001:db8::

Pppoe-server

ipv6 local pool PPPOE_POOL6 2001:DB8:5AB:10::/60 64
!
bba-group pppoe BBAG
virtual-template 1
!
interface Virtual-Template1
ipv6 address FE80::22 link-local
ipv6 enable
ipv6 nd ra lifetime 21600
ipv6 nd ra interval 4 3


peer default ipv6 pool PPPOE_POOL6

ppp authentication chap callin

!

interface FastEthernet0/0

pppoe enable group BBAG

IPCP (IPv4) negotiates the IPv4 address to be assigned to the client, where IPC6CP negotiates only the interface identifier, the prefix information is performed through SLAAC.

pppoe-client

interface FastEthernet0/1
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer1
mtu 1492
dialer pool 1
dialer-group 1
ipv6 address FE80::10 link-local

ipv6 address autoconfig default

ipv6 enable

ppp authentication chap callin

ppp chap hostname pppoe-client

ppp chap password 0 cisco

The CPE (PPPoE client) is assigned an IPv6 address through SLAAC along with a static default route: ipv6 address autoconfig default

pppoe-client#sh ipv6 interface dialer 1
Dialer1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::10
No Virtual link-local address(es):

Stateless address autoconfig enabled
Global unicast address(es):

2001:DB8:5AB:10::10, subnet is 2001:DB8:5AB:10::/64 [EUI/CAL/PRE]
valid lifetime 2587443 preferred lifetime 600243

Note from the below traffic capture (figure5) that both IPv6 and IPv4 use the same PPP session (layer2 model) (same session ID=0x0006) because the Link Control Protocol is independent of the network layer.

Figure5: Wireshark capture of common PPP layer2 model

Figure5: Wireshark capture of common PPP layer2 model


pppoe-client LAN IPv6 assignment

The advantage of using DHCPv6 PD (Prefix Delegation is that the PPPoE will automatically add a static route to the assigned prefix, very handy!

pppoe-server

ipv6 dhcp pool CPE_LAN_DP
prefix-delegation 2001:DB8:5AB:2000::/56
00030001CA00075C0008 lifetime infinite infinite
!
interface Virtual-Template1

ipv6 dhcp server CPE_LAN_DP

Now the PPPoE client can use the delegated prefix to assign an IPv6 address (::1) to its own interface (fa0/0) and the remaining for SLAAC advertisement.

No NAT needed for the delegated prefixes to be used publically, so no translation states on the PPPoE server. The prefix is directly accessible from outside.

For more information about the client ID used for DHCPv6 assignment, please refer to the prior post about DHCPv6. https://cciethebeginning.wordpress.com/2012/01/18/ios-dhcpv6-deployment-schemes/

pppoe-client

pppoe-client#sh ipv6 dhcp
This device’s DHCPv6 unique identifier(DUID): 00030001CA00075C0008
pppoe-client#
interface Dialer1

ipv6 dhcp client pd PREFIX_FROM_ISP
!
interface FastEthernet0/0
ipv6 address FE80::2000:1 link-local

ipv6 address PREFIX_FROM_ISP ::1/64
ipv6 enable
pppoe-client#sh ipv6 dhcp interface
Dialer1 is in client mode
Prefix State is OPEN
Renew will be sent in 3d11h
Address State is IDLE
List of known servers:
Reachable via address: FE80::22
DUID: 00030001CA011F780008
Preference: 0
Configuration parameters:

IA PD: IA ID 0x00090001, T1 302400, T2 483840

Prefix: 2001:DB8:5AB:2000::/56

preferred lifetime INFINITY, valid lifetime INFINITY

Information refresh time: 0

Prefix name: PREFIX_FROM_ISP

Prefix Rapid-Commit: disabled

Address Rapid-Commit: disabled

client-LAN

Now the customer LAN is assigned globally available IPv6 from the CPE (PPPoE client).

client-LAN#sh ipv6 interface fa0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::2000:F
No Virtual link-local address(es):

Stateless address autoconfig enabled
Global unicast address(es):

2001:DB8:5AB:2000::2000:F, subnet is 2001:DB8:5AB:2000::/64 [EUI/CAL/PRE]
client-LAN#sh ipv6 route

S ::/0 [2/0]

via FE80::2000:1, FastEthernet0/0

C 2001:DB8:5AB:2000::/64 [0/0]

via FastEthernet0/0, directly connected

L 2001:DB8:5AB:2000::2000:F/128 [0/0]

via FastEthernet0/0, receive

L FF00::/8 [0/0]

via Null0, receive

client-LAN#

End-to-end dual-stack connectivity check

client-LAN#ping 2001:DB8:5AB:3::100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:5AB:3::100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/45/88 ms
client-LAN#trace 2001:DB8:5AB:3::100
Type escape sequence to abort.
Tracing the route to 2001:DB8:5AB:3::100

1 2001:DB8:5AB:2000::1 28 msec 20 msec 12 msec

2 2001:DB8:5AB:2::FF 44 msec 20 msec 32 msec

3 2001:DB8:5AB:3::100 48 msec 20 msec 24 msec

client-LAN#

client-LAN#ping 192.168.3.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/63/96 ms
client-LAN#trace 192.168.3.100
Type escape sequence to abort.
Tracing the route to 192.168.3.100

1 192.168.4.1 32 msec 44 msec 20 msec

2 192.168.2.1 56 msec 68 msec 80 msec

3 192.168.3.100 72 msec 56 msec 116 msec

client-LAN#

I assigned PREFIX_FROM_ISP as locally significant name for the delegated prefix, no need to match the name on the DHCPv6 server side.

Finally, the offline lab with all the commands needed for more detailed inspection:

 

References

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/bbdsl/configuration/15-mt/bba-15-mt-book/bba-ppoe-client.html

http://www.cisco.com/en/US/docs/ios-xml/ios/bbdsl/configuration/15-mt/ip6-adsl_external_docbase_0900e4b182dbdf4f_4container_external_docbase_0900e4b182dc25f3.html

http://www.broadband-forum.org/technical/download/TR-187.pdf

https://tools.ietf.org/html/rfc5072

https://tools.ietf.org/html/rfc5072

http://www.bortzmeyer.org/6911.html (french)

http://packetsize.net/cisco-pppoe-ipv4-ipv6-mppe.htm

     

Order of operations : NAT + Routing + ACL


This is the 1st post in the series “router order of operations” and the purpose is to provide a comprehensive but clear enough overview of how operations are performed in the router and implications on what IP addresses to consider particularly when filtering with ACL.

Part1: NAT + Routing

“Routing” & “NAT” represent keystone to understand more complex situations:

Figure1: order of NAT+Routing


Rules:

– Traffic entering inside NAT interface is routed 1st then NATted

– Traffic entering outside NAT interface is NATted 1st then routed

IMPORTANT ===> For outside NAT : Make sure to have a route for the “outside local” to the outside NAT interface, or add the keyword “add-route” at the end of the “ip nat outside source static” command, otherwise, because of the “alias” feature inherited to NAT, the outside interface will respond on behalf of the outside local (if the prefix belongs to the outside interface segment) or will not be routed (if the prefix doesn’t belong to an attached subnet) (1)

Part2: NAT + Routing+ ACL

Figure2: order of NAT+Routing+ACL

Rules:

– Traffic entering inside NAT interface is always routed 1st then NATted.

– Traffic entering outside NAT interface is always NATted 1st then routed.

– Inbound ACL are performed before routing & NAT, alleviate processing overhead by filtering unnecessary traffic.

– Outbound ACL is performed after routing & NAT.

Next follows the practice lab in which, the previously stated rules are demonstrated:

Figure3: Lab topology

Note:

vhost1 and vhost2 routers are simulated inside one single router using VRF-Lite (Figure4), for more information about this technique, refer to the post VRF-Lite as an alternative to VPC

Figure4: end-host deployment


Let’s suppose that the policy is to block ICMP traffic between the inside host 10.0.0.17 and the outside host 192.168.20.146, we will see that the involved IP address in the ACL changes according to the type of translation, the direction of the traffic and the NAT interface on which ACL is applied.

Each time only a single ACL is applied to a single interface, one single icmp packet is generated from inside to outside.

Here is the battery of tests to be done, observe debug results and refer to the associated rules and figures.

Tests :

Inside source Inside NAT interface Outside NAT interface
ACL direction inbound outbound inbound Outbound
Prefix to filter Src=Inside local Dst=Inside local Dst=Outside local Src=Outside local
outside source Inside NAT interface Outside NAT interface
ACL direction inbound outbound inbound outbound
Prefix to filter Dst=Outside local Src=Outside local Src=Outside global Dst=Outside global

A) – inside source NAT

NAT operation:

(inside local = 10.0.0.17) is seen from outside as (inside global = 192.168.20.131)

NAT(config)#ip nat inside source static 10.0.0.17 192.168.20.131

NAT#sh ip nat translations

Pro Inside global Inside local Outside local Outside global

— 192.168.20.131 10.0.0.17 — —

NAT#

For each case ICMP traffic is generated as follow:

Vhost#ping vrf vhost1 192.168.20.146 repeat 1

A1-ACL applied on outside nat interface

A1-a) inbound direction filter prefix dst=outside local

ip access-list ext outsideblock-in

10 deny ip any host 192.168.20.131

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-in in

NAT(config-if)#

*Mar 1 23:26:57.562: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), routed via FIB

*Mar 1 23:26:57.566: NAT: s=10.0.0.17->192.168.20.131, d=192.168.20.146 [139]

*Mar 1 23:26:57.570: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.130, len 100, forward

*Mar 1 23:26:57.706: IP: s=192.168.20.146 (FastEthernet0/1), d=192.168.20.131, len 100, access denied

Note order of operation: routing->NAT for ICMP echo and the returning traffic is blocked before entering the router.

*** Last outbound interface operation is traffic forwarding to next-hop

A1-b) outbound direction filter prefix src=outside local

ip access-list ext outsideblock-out

10 deny ip host 192.168.20.131 any

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-out out

NAT(config-if)#

*Mar 1 23:34:36.162: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), routed via FIB

*Mar 1 23:34:36.166: NAT: s=10.0.0.17->192.168.20.131, d=192.168.20.146 [140]

*Mar 1 23:34:36.170: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), len 100, access denied

NAT(config-if)#

Note the order of operations: routing->NAT, and then ACL blocked it outbound at the outside NAT interface.

A2-acl applied on inside nat interface

A2-a) inbound direction filter prefix src=inside local

ip access-list ext insideblock-in

10 deny ip host 10.0.0.17 any

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-in in

Vhost#p vrf vhost1 192.168.20.146 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 192.168.20.146, timeout is 2 seconds:

U

Success rate is 0 percent (0/1)

Vhost#

NAT#

*Mar 1 22:53:08.410: IP: s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146, len 100, access denied

NAT#

The debug confirm that inbound ACL at the inside NAT interface is performed 1st before any other operations and filter the inside local as source of the traffic

A2-b) outbound direction filter prefix dst=inside local

ip access-list ext insideblock-out

10 deny ip any host 10.0.0.17

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-out out

Vhost#

Vhost#p vrf vhost1 192.168.20.146 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 192.168.20.146, timeout is 2 seconds:

.

Success rate is 0 percent (0/1)

Vhost#

NAT(config-if)#

*Mar 1 23:14:36.762: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), routed via FIB

*Mar 1 23:14:36.766: NAT: s=10.0.0.17->192.168.20.131, d=192.168.20.146 [137]

*Mar 1 23:14:36.770: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.130, len 100, forward

*Mar 1 23:14:36.918: NAT*: s=192.168.20.146, d=192.168.20.131->10.0.0.17 [137]

*Mar 1 23:14:36.922: IP: tableid=0, s=192.168.20.146 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), routed via FIB

*Mar 1 23:14:36.926: IP: s=192.168.20.146 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), len 100, access denied

Note the order of operations: Routing=>NAT for ICMP echo, but NAT=>Routing for ICMP reply and outbound ACL at the inside NAT interface

B) – outside source NAT

NAT operation:

(inside local = 10.0.0.17) is seen from outside as (inside global = 192.168.20.131)

(outside global = 192.168.20.146) is seen from inside as (outside local = 10.0.0.35)

As stated in (1) make sure to have a route for the outside local to the outside interface, or add the keywork “add-route” at the end of the “ip nat outside source static” command otherwise because of the “alias” feature inherited to NAT, the outside interface will respond on behalve of 10.0.0.35 (10.0.0.35 belongs to the outside inteface segment)

ip nat outside source static 192.168.20.146 10.0.0.35 add-route

or

ip nat outside source static 192.168.20.146 10.0.0.35

ip route 10.0.0.35 255.255.255.255 fa0/1

NAT(config)#do sh ip nat tra

Pro Inside global Inside local Outside local Outside global

— — — 10.0.0.35 192.168.20.146

— 192.168.20.131 10.0.0.17 — —

NAT(config)#

For each case ICMP traffic is generated from vhost1 (10.0.0.17) toward vhost2 (192.168.20.146) as follow :

Vhost#ping vrf vhost1 10.0.0.35 repeat 1

Here are normal operations without filtering:

NAT(config)#

*Mar 2 02:07:20.597: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:07:20.605: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [204]

*Mar 2 02:07:20.605: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [204]

*Mar 2 02:07:20.609: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.146, len 100, forward

*Mar 2 02:07:20.721: NAT*: s=192.168.20.146->10.0.0.35, d=192.168.20.131 [204]

*Mar 2 02:07:20.725: NAT*: s=10.0.0.35, d=192.168.20.131->10.0.0.17 [204]

*Mar 2 02:07:20.733: IP: tableid=0, s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), routed via FIB

*Mar 2 02:07:20.737: IP: s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), g=10.0.0.34, len 100, forward

NAT(config)#

Note the order of operations: routing=>NAT then NAT=>Routing for the returning traffic

B1-acl applied on outside nat interface

B1-a) inbound filter prefix src=outside global

ip access-list ext outsideblock-in

10 deny ip host 192.168.20.146 any

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-in in

NAT(config-if)#

*Mar 2 02:16:45.621: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:16:45.625: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [207]

*Mar 2 02:16:45.629: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [207]

*Mar 2 02:16:45.633: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.146, len 100, forward

*Mar 2 02:16:45.745: IP: s=192.168.20.146 (FastEthernet0/1), d=192.168.20.131, len 100, access denied

B1-b) outbound filter prefix dst=outside global

ip access-list ext outsideblock-out

10 deny ip any host 192.168.20.146

20 permit ip any any

interface FastEthernet0/1

ip access-group outsideblock-out out

NAT(config-if)#

*Mar 2 02:19:31.969: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:19:31.973: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [208]

*Mar 2 02:19:31.977: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [208]

*Mar 2 02:19:31.981: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), len 100, access denied

B2- acl applied on inside nat interface

B2-a) inbound filter prefix dst=outside local

ip access-list ext insideblock-in

10 deny ip any host 10.0.0.35

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-in in

NAT(config-if)#

*Mar 2 02:10:45.613: IP: s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35, len 100, access denied

B2-b) outbound filter prefix src=outside local

ip access-list ext insideblock-out

10 deny ip host 10.0.0.35 any

20 permit ip any any

interface FastEthernet0/0

ip access-group insideblock-out out

NAT(config-if)#

*Mar 2 02:12:11.393: IP: tableid=0, s=10.0.0.17 (FastEthernet0/0), d=10.0.0.35 (FastEthernet0/1), routed via RIB

*Mar 2 02:12:11.397: NAT: s=10.0.0.17->192.168.20.131, d=10.0.0.35 [206]

*Mar 2 02:12:11.401: NAT: s=192.168.20.131, d=10.0.0.35->192.168.20.146 [206]

*Mar 2 02:12:11.405: IP: s=192.168.20.131 (FastEthernet0/0), d=192.168.20.146 (FastEthernet0/1), g=192.168.20.146, len 100, forward

*Mar 2 02:12:11.517: NAT*: s=192.168.20.146->10.0.0.35, d=192.168.20.131 [206]

*Mar 2 02:12:11.517: NAT*: s=10.0.0.35, d=192.168.20.131->10.0.0.17 [206]

*Mar 2 02:12:11.525: IP: tableid=0, s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), routed via FIB

*Mar 2 02:12:11.529: IP: s=10.0.0.35 (FastEthernet0/1), d=10.0.0.17 (FastEthernet0/0), len 100, access denied

Conclusion

– Write down your expectations in term of address translation, routing and filtering.

– Make sure to choose your IP addresses to filter, the ACL direction and the interface to which ACL is applied with the order of operations in mind.

Inter-VRF-Lite routing


The main purpose of this post is to put forth the global approach of routing with VRF-lite throughout different deployment schemes, combining:

Network translation & address scheme

– Overlapping / non-overlapping customer prefixes

– Traditional NAT / NAT NVI

Deployment models:

– Customer VRFs and common site global routing instance

– Customer VRFs and a common site VRF

Access policy:

– Customers communicate ONLY with common site

– Customer-to-customer communications

Syllabus:

I) Non-overlapping Customer prefixes

                    2a) Customer-to-common service ONLY communication

               2a) Customer-to-Customer communication through HUB site

               2b) direct any-to-any communication

II) Overlapping Customer prefixes

All individual labs are mainly based on the below topology:

Picture0: General topology

– Routers “vhost5” & R5 belong to CustomerA

– Routers “vhost4” & R4 belong to CustomerB

– Access router R1 deploying VRFs for each customer (locally significant)

– Router “vhost7” gateway to common services in a site accessible by both customers

Note:

End-hosts “vhost4”, “vhost5” and “vhost7” are deployed virtually inside a single physical router with VRF-Lite locally significant (independent from VRF-Lite deployed on R1)

For more detailed information about this technique refer to the post “VRF-Lite as an alternative to VPC

Inter-VRF-Lite routing (1/7)


Customer VRFs & Global routing instance

– R1 separates Customer traffic with different routing instances “vhost4”, “vhost5” and a global routing instance for common site traffic.

– Customers (40.0.0.0/24 and 50.0.0.0/24) communicate ONLY with the common site.

Picture 1-1: topology

Inter-VRF communications depends on static routing from one VRF to other VRF outbound interfaces

ip vrf vhost4

rd 400:400

route-target export 400:400

route-target import 400:400

!

ip vrf vhost5

rd 500:500

route-target export 500:500

route-target import 500:500

R1 configuration

interface Serial1/0.104 point-to-point


ip vrf forwarding vhost4

description VRF vhost4 sub-interface

ip address 155.1.0.14 255.255.255.0

frame-relay interface-dlci 104

!

interface Serial1/0.105 point-to-point

description VRF vhost5 sub-interface


ip vrf forwarding vhost5

ip address 155.1.0.15 255.255.255.0

frame-relay interface-dlci 105

!

interface FastEthernet2/0

description Interface belonging to global routing instance

ip address 172.1.1.1 255.255.255.0

Static inter-vrf (route leaking of VRF prefixes to Global RIB)

ip route 40.0.0.0 255.255.255.0 Serial1/0.104

ip route 50.0.0.0 255.255.255.0 Serial1/0.105

VRF vhost5

ip route vrf vhost5 50.0.0.0 255.255.255.0 Serial1/0.105 155.1.0.5

static inter-vrf (route leaking of Global RIB prefixes to VRF RIB)

ip route vrf vhost5 172.1.1.7 255.255.255.255 FastEthernet2/0 172.1.1.7 global

VRF vhost4

ip route vrf vhost4 40.0.0.0 255.255.255.0 Serial1/0.104 155.1.0.4

Static inter-vrf (route leaking of Global RIB prefixes to VRF RIB)

ip route vrf vhost4 172.1.1.7 255.255.255.255 FastEthernet2/0 172.1.1.7 global

Global routing table

R1#sh ip route

Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets

C 1.1.1.1 is directly connected, Loopback1

50.0.0.0/24 is subnetted, 1 subnets

S 50.0.0.0 is directly connected, Serial1/0.105

172.1.0.0/24 is subnetted, 1 subnets

C 172.1.1.0 is directly connected, FastEthernet2/0

40.0.0.0/24 is subnetted, 1 subnets

S 40.0.0.0 is directly connected, Serial1/0.104

R1#

VRF vhost4 RIB

R1#sh ip route vrf vhost4

Routing Table: vhost4

Gateway of last resort is not set

155.1.0.0/24 is subnetted, 1 subnets

C 155.1.0.0 is directly connected, Serial1/0.104

172.1.0.0/32 is subnetted, 1 subnets

S 172.1.1.7 [1/0] via 172.1.1.7, FastEthernet2/0

40.0.0.0/24 is subnetted, 1 subnets

S 40.0.0.0 [1/0] via 155.1.0.4, Serial1/0.104

R1#

VRF vhost5 RIB

R1#sh ip route vrf vhost4

Routing Table: vhost5

Gateway of last resort is not set

50.0.0.0/24 is subnetted, 1 subnets

S 50.0.0.0 [1/0] via 155.1.0.5, Serial1/0.105

155.1.0.0/24 is subnetted, 1 subnets

C 155.1.0.0 is directly connected, Serial1/0.105

172.1.0.0/32 is subnetted, 1 subnets

S 172.1.1.7 [1/0] via 172.1.1.7, FastEthernet2/0

R1#

Testing From Customer A

vhost#trace vrf vhost5 172.1.1.7

Type escape sequence to abort.

Tracing the route to 172.1.1.7

1 50.0.0.5 88 msec 16 msec 4 msec

2 155.1.0.15 56 msec 52 msec 20 msec

3 172.1.1.7 68 msec * 124 msec

vhost#

Testing From Customer B

vhost#trace vrf vhost4 172.1.1.7

Type escape sequence to abort.

Tracing the route to 172.1.1.7

1 40.0.0.4 68 msec 20 msec 48 msec

2 155.1.0.14 52 msec 28 msec 16 msec

3 172.1.1.7 60 msec * 132 msec

vhost#

Testing from Common site

vhost#trace vrf vhost7 50.0.0.1

Type escape sequence to abort.

Tracing the route to 50.0.0.1

1 172.1.1.1 80 msec 44 msec 4 msec

2 155.1.0.5 96 msec 36 msec 16 msec

3 50.0.0.1 40 msec * 108 msec

vhost#trace vrf vhost7 40.0.0.1

Type escape sequence to abort.

Tracing the route to 40.0.0.1

1 172.1.1.1 92 msec 64 msec 4 msec

2 155.1.0.4 96 msec 48 msec 12 msec

3 40.0.0.1 64 msec * 96 msec

vhost#

Back to main article

Inter-VRF-Lite routing (2/7)


Customer-to-Customer communication through HUB site

– R1 separates Customer traffic using different routing instances “vhost4”, “vhost5”

– VRF “57” reserved for traffic from CustomerA toward the common site R7.

– VRF “47” reserved for traffic from CustomerB toward the common site R7.

– VRF “45” reserved for traffic from common site toward both Customers.

– Customers communicate with each other ONLY through the common site R7.

To avoid confusion, router R7 is deployed using a separate physical router (as against virtual deployment for “Vhost5” and Vhost4 routers)

Picture: 1-2


R1 Configuration

interface Serial1/0.104 point-to-point

ip vrf forwarding vhost4

ip address 155.1.0.14 255.255.255.0

frame-relay interface-dlci 104

!

interface Serial1/0.105 point-to-point

ip vrf forwarding vhost5

ip address 155.1.0.15 255.255.255.0

frame-relay interface-dlci 105

R1-R7 communication is performed through dot1q sub-interface

interface FastEthernet2/0.45

encapsulation dot1Q 45

ip vrf forwarding 45

ip address 172.1.45.1 255.255.255.0

!

interface FastEthernet2/0.47

encapsulation dot1Q 47

ip vrf forwarding 47

ip address 172.1.47.1 255.255.255.0

!

interface FastEthernet2/0.57

encapsulation dot1Q 57

ip vrf forwarding 57

ip address 172.1.57.1 255.255.255.0

Inter-VRF communications depends on static routing from one VRF to other VRF outbound interfaces

VRF “vhost4”

ip route vrf vhost4 0.0.0.0 0.0.0.0 FastEthernet2/0.47 172.1.47.7

ip route vrf vhost4 40.0.0.0 255.255.255.0 155.1.0.4

VRF “vhost5”

ip route vrf vhost5 0.0.0.0 0.0.0.0 FastEthernet2/0.57 172.1.57.7

ip route vrf vhost5 50.0.0.0 255.255.255.0 155.1.0.5

VRF “47” receive traffic from VRF “vhost4” and forward to the HUB site

ip route vrf 47 0.0.0.0 0.0.0.0 172.1.47.7

VRF “57” receive traffic from VRF “vhost5” and forward to the HUB site

ip route vrf 57 0.0.0.0 0.0.0.0 172.1.57.7

For any traffic coming from the HUB site, customer prefixes 40.0.0.0/24 and 50.0.0.0/24 are reachable respectively through VRF “vhost4” and VRF “vhost5” outbound interfaces.

ip route vrf 45 40.0.0.0 255.255.255.0 Serial1/0.104 155.1.0.4

ip route vrf 45 50.0.0.0 255.255.255.0 Serial1/0.105 155.1.0.5

VRF routing tables on R1

R1#sh ip route vrf vhost4

Routing Table: vhost4

Gateway of last resort is 172.1.47.7 to network 0.0.0.0

155.1.0.0/24 is subnetted, 1 subnets

C 155.1.0.0 is directly connected, Serial1/0.104

40.0.0.0/24 is subnetted, 1 subnets

S 40.0.0.0 [1/0] via 155.1.0.4

S* 0.0.0.0/0 [1/0] via 172.1.47.7, FastEthernet2/0.47

R1#

R1#sh ip route vrf 47

Routing Table: 47

Gateway of last resort is not set

172.1.0.0/24 is subnetted, 1 subnets

C 172.1.47.0 is directly connected, FastEthernet2/0.47

S 0.0.0.0/0 [1/0] via 172.1.47.7

R1#

Traffic coming from customerB is forwarded to a VRF “47” outbound interface, which in turn forward traffic to R7

R1#sh ip route vrf vhost5

Routing Table: vhost5

Gateway of last resort is 172.1.57.7 to network 0.0.0.0

50.0.0.0/24 is subnetted, 1 subnets

S 50.0.0.0 [1/0] via 155.1.0.5

155.1.0.0/24 is subnetted, 1 subnets

C 155.1.0.0 is directly connected, Serial1/0.105

S* 0.0.0.0/0 [1/0] via 172.1.57.7, FastEthernet2/0.57

R1#

R1#sh ip route vrf 57

Routing Table: 57

Gateway of last resort is not set

172.1.0.0/24 is subnetted, 1 subnets

C 172.1.57.0 is directly connected, FastEthernet2/0.57

S 0.0.0.0/0 [1/0] via 172.1.57.7

R1#

Traffic coming from customerA is forwarded to a VRF “57” outbound interface, which in turn forward traffic to R7

R1#sh ip route vrf 45

Routing Table: 45

Gateway of last resort is not set

50.0.0.0/24 is subnetted, 1 subnets

S 50.0.0.0 [1/0] via 155.1.0.5, Serial1/0.105

172.1.0.0/24 is subnetted, 1 subnets

C 172.1.45.0 is directly connected, FastEthernet2/0.45

40.0.0.0/24 is subnetted, 1 subnets

S 40.0.0.0 [1/0] via 155.1.0.4, Serial1/0.104

R1#

Traffic coming from HUB site R7 is forwarded to the appropriate VRF according to the destination

R7 (HUB site) Configuration

interface FastEthernet1/0.45


encapsulation dot1Q 45

ip address 172.1.45.7 255.255.255.0

!

interface FastEthernet1/0.47


encapsulation dot1Q 47

ip address 172.1.47.7 255.255.255.0

!

interface FastEthernet1/0.57


encapsulation dot1Q 57

ip address 172.1.57.7 255.255.255.0

Traffic from VRF “vhost4” & “vhost5” on R1 converge and sent back to R1 VRF “45”

ip route 40.0.0.0 255.255.255.0 172.1.45.1

ip route 50.0.0.0 255.255.255.0 172.1.45.1

R7#sh ip route

Gateway of last resort is not set

50.0.0.0/24 is subnetted, 1 subnets

S 50.0.0.0 [1/0] via 172.1.45.1

172.1.0.0/24 is subnetted, 3 subnets

C 172.1.45.0 is directly connected, FastEthernet1/0.45

C 172.1.47.0 is directly connected, FastEthernet1/0.47

C 172.1.57.0 is directly connected, FastEthernet1/0.57

40.0.0.0/24 is subnetted, 1 subnets

S 40.0.0.0 [1/0] via 172.1.45.1

R7#


CustomerB to CustomerA

vhost#trace vrf vhost4 50.0.0.1

Type escape sequence to abort.

Tracing the route to 50.0.0.1

1 40.0.0.4 56 msec 44 msec 4 msec

2 155.1.0.14 52 msec 24 msec 12 msec

3 172.1.47.7 48 msec 20 msec 24 msec

4 172.1.45.1 28 msec 92 msec 36 msec

5 155.1.0.5 76 msec 40 msec 40 msec

6 50.0.0.1 56 msec * 208 msec

vhost#

vhost#trace vrf vhost5 40.0.0.1

Type escape sequence to abort.

Tracing the route to 40.0.0.1

1 50.0.0.5 84 msec 60 msec 8 msec

2 155.1.0.15 52 msec 12 msec 20 msec

3 172.1.57.7 76 msec 32 msec 28 msec

4 172.1.45.1 20 msec 24 msec 28 msec

5 155.1.0.4 88 msec 80 msec 52 msec

6 40.0.0.1 72 msec * 140 msec

vhost#

Picture: 1-2a illustrates how customer traffic switch from one VRF to another through router R7

Picture 1-2a: traffic flow


Back to main article

Inter-VRF-Lite routing (3/7)


Customer-to-common service ONLY communication

– R1 separates Customers and common site traffic using different routing instances “vhost4”, “vhost5” and “vhost7”.

– Customers communicate ONLY with the common site.

Picture: 1-3


R1 configuration:

ip vrf vhost4

rd 400:400

route-target export 400:400

route-target import 400:400

ip vrf vhost5

rd 500:500

route-target export 500:500

route-target import 500:500

ip vrf vhost7

rd 700:700

route-target export 700:700

route-target import 700:700

Routing between VRFs

Inter-VRF communications depends on static routing from one VRF to other VRF outbound interfaces

R1(config)#ip route vrf vhost4 172.1.1.0 255.255.255.0 fa2/0 172.1.1.7

R1(config)#ip route vrf vhost5 172.1.1.0 255.255.255.0 fa2/0 172.1.1.7

R1(config)#ip route vrf vhost7 50.0.0.0 255.255.255.0 s1/0.105 155.1.0.5

R1(config)#ip route vrf vhost7 40.0.0.0 255.255.255.0 s1/0.104 155.1.0.4

VRF vhost4 RIB

R1(config)#do sh ip route vrf vhost4

Gateway of last resort is not set

155.1.0.0/24 is subnetted, 1 subnets

C 155.1.0.0 is directly connected, Serial1/0.104

172.1.0.0/24 is subnetted, 1 subnets

S 172.1.1.0 [1/0] via 172.1.1.7, FastEthernet2/0

40.0.0.0/24 is subnetted, 1 subnets

S 40.0.0.0 [1/0] via 155.1.0.4

R1(config)#

VRF vhost5 RIB

R1(config)#do sh ip route vrf vhost5

Gateway of last resort is not set

50.0.0.0/24 is subnetted, 1 subnets

S 50.0.0.0 [1/0] via 155.1.0.5

155.1.0.0/24 is subnetted, 1 subnets

C 155.1.0.0 is directly connected, Serial1/0.105

172.1.0.0/24 is subnetted, 1 subnets

S 172.1.1.0 [1/0] via 172.1.1.7, FastEthernet2/0

R1(config)#

VRF vhost7 RIB

R1(config)#do sh ip route vrf vhost7

Gateway of last resort is not set

50.0.0.0/24 is subnetted, 1 subnets

S 50.0.0.0 [1/0] via 155.1.0.5, Serial1/0.105

172.1.0.0/24 is subnetted, 1 subnets

C 172.1.1.0 is directly connected, FastEthernet2/0

40.0.0.0/24 is subnetted, 1 subnets

S 40.0.0.0 [1/0] via 155.1.0.4, Serial1/0.104

R1(config)#

Traceroute testing

As illustrated by picture 1-3a, Customers can communicate ONLY with the common site.

Picture 1-3a: Customer-to-HUB only communication


CustomerB to Common site

vhost#trace vrf vhost4 172.1.1.7

Type escape sequence to abort.

Tracing the route to 172.1.1.7

1 40.0.0.4 52 msec 52 msec 0 msec

2 155.1.0.14 52 msec 40 msec 12 msec

3 172.1.1.7 32 msec * 100 msec

vhost#

CustomerA to Common site

vhost#trace vrf vhost5 172.1.1.7

Type escape sequence to abort.

Tracing the route to 172.1.1.7

1 50.0.0.5 72 msec 48 msec 4 msec

2 155.1.0.15 60 msec 20 msec 16 msec

3 172.1.1.7 32 msec * 116 msec

vhost#

CustomerA to CustomerB

vhost#p vrf vhost5 40.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 40.0.0.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

vhost#

vhost#trace vrf vhost5 40.0.0.1

Type escape sequence to abort.

Tracing the route to 40.0.0.1

1 50.0.0.5 80 msec 60 msec 4 msec

2 155.1.0.15 44 msec 24 msec 16 msec

3 155.1.0.15 !H * !H

vhost# CustomerB to CustomerA

vhost#p vrf vhost4 50.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 50.0.0.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

vhost#trace vrf vhost4 50.0.0.1

Type escape sequence to abort.

Tracing the route to 50.0.0.1

1 40.0.0.4 76 msec 12 msec 4 msec

2 155.1.0.14 56 msec 48 msec 52 msec

3 155.1.0.14 !H * !H

vhost#

Back to main article

%d bloggers like this: