A short piece on IP-VPN basics. I’ll walk through the basic configuration of an IP-VPN and show three different takes on configuring the routing-instance. I will do so on the following topology;
The focus will be on the IP-VPN. The ISP network is already in place and the customer routers (the red and blue ones) have a default route towards the PE configured. The goal is to establish IP connectivity between the loopback interfaces of the customer routers.
Configuring PE R25:
The configuration here is the following;
The first configuration command calls into life a routing-instance that is used in layer 3 VPN implementations. The statement thereafter is to move interface xe-0/3/1.3025 from the master routing-instance to the newly created routing-instance.
The route-distinguisher statement identifies the route-distinguisher used for routes belonging to this vpn.
The vrf-target statement will generate a ‘hidden’ import and export policy for this vpn. The import policy will make sure the routes with the specified route-target are imported and placed into the vpn. The export policy will make sure the routes from the vpn will have the specified route-target attached to them when they are exported via BGP.
Upon using this basic configuration, you have to bear in mind that Junos will not advertise directly connected multiaccess segments. When you are using PPPoE or when you are running a dynamic routing-protocol with the CPE, you will not have this issue.
Since we are not running PPPoE and since we are using static routes, we will see a label allocation failure for directly connected routes when we examine the advertised routes;
When you run into this situation, and you do not want to use ‘vrf-table-label’, you can do either of these things to have the directly connected segment advertised;
1. Create a static /32 route to route the IP address of the interface to itself.
2. Create a static route using the IP address of the CPE as the next-hop.
To demonstrate this, I’ll delete the previous route and insert a static route that uses 10.0.0.1 as the next-hop;
Configuring PE R17:
The configuration of the routing-instance on R17 is as follows;
This configuration uses ‘vrf-table-label’. This ‘vrf-table-label’ command will create an LSI interface that maps to the created routing-instance. Certain scenarios will not be supported with this, 'carrier of carriers' for instance. In my opinion, this is one of the more exotic scenario’s.
Anyway, the vrf-table-label configuration command will also have directly connected multiaccess advertised.
Let’s add the static route and verify we are advertising everything to the route-reflector;
Configuring PE R22:
On the last PE, the configuration will not make use of the automatically created route-target. I will instead create an extended community, and use manually created import and export policies in the routing-instance configuration.
The configuration of the routing-instance is as follows;
Notice the absence of the ‘vrf-target’ statement. Instead, I used the ‘vrf-import’ and ‘vrf-export’ statement to refer to policies I created myself.
These policies, and the community they refer to, have been configured as follows;
Also note that, even though I did not explicitly say it, the ‘vrf-table-label’ option has nothing to do with the ‘vrf-target’ versus manually configured policies choice.
In order to verify if all PE’s are advertising their routes, we can go over to the route-reflector and issue the following command;
In order to verify the IP connectivity, let’s move to S1. On tis router, I will verify the connectivity between the different locations using 192.168.3.1 as source IP address;
That’s it for the IP-VPN basics.