Nokia: Service Router – Default Originate Replica (Cisco BGP Command)

A simple overview on how to re-create the Cisco BGP ‘default-originate’ command for a default route advertisement from a Nokia Service Provider perspective (IPv4/IPv6.)

There are several ways to advertise a default route in the Cisco environment – here is a quick summary:

  1. The first option is what we will attempt to replicate from a Nokia Service Router perspective. Advertising a default route PER BGP Peer instance. This is a more controlled way of advertising.
    ‘neighbor X.Y.X.Y default-originate’ Again, this doesn’t require an active default route to be present or redistributed. This will generate and propagate to the specified neighbor only.
  2. Adding a “network” command under the address family for your BGP routing instance to advertise to ALL neighbors. Remember: This requires an present /0 route in the FIB.
  3. Redistribution – from a currently active default route in the routing table of an IGP. Hence, redistribute – (Almost the same as option 2)
  4. “Default-information originate” – This command will GENERATE a default route to ALL BGP neighbors under the family. An active default route is NOT required to be present under another routing instance in order to propagate the new default route to all BGP peers


The topology will be a Cisco edge device dual-homed to a Nokia PE devices from ISP XYZ. NOTE: There is currently no route map prepending the AS, but we are load balancing.


The topology will be a Cisco edge device dual-homed to a Nokia PE devices from ISP XYZ. NOTE: There is currently no route map prepending the AS, but we are load balancing.


Here is the configuration from the Cisco Edge Device (CustomerSiteB):


Not much in configuration. Standard BGP session to an ISP (without authentication)  – Note the BFD configuration for the peers for a fast failover. Will do a blog post about this in the upcoming weeks, which I will demonstrate the fast-external-fallover command as well.

Currently, we are not learning any BGP routes from our ISP.  Here is the configuration from the Nokia PE devices R5/R6.  (Only showing one side, as they are extremely similar, with only varying subnets)


Creating a Prefix-List:

Lets begin the process to simulate the default-route advertisement.

Note: add prefix ::/0 exact for IPv6 & family ipv6 under the policy statement.

We’ll start by configuring a prefix list on our PE devices (R5/R6):pflist.PNG

Next, we create a Policy Statement:


Make sure to COMMIT the changes!

Adding the policy statement under the BGP configuration inside the VRFs.

/configure service vprn 100 # Example VRF

  • #Create a Black Hole/ Null Route to discard any unwanted/un-routable traffic.
    static-route ::/0 black-hole
    static-route black-hole

Add the new “Default Originate” policy statement we created earlier to the the BGP Group of your customer as an export statement.


At this point we should be advertising ONLY a default route to our BGP neighbor.

From our PE device, a quick “show router 100 bgp neighbor advertised-route” will display the following:


I will go ahead and replicate this policy statement on both VPRN’s on R5/R6 – Our Nokia PE devices for the Dual-Homed BGP Customer and apply the export statement to the BGP peer.

A look at “show ip route bgp” on the CustomerSiteB Cisco edge device shows us the two paths (thanks to the the load balancing, ‘maximum-paths 2’ configuration):


Now we are learning a default route from both uplinks to our dual-homed ISP connection. Failover should be seamless at this point, although having two default routes is prob not what you want – this is a simple example of how to accomplish a default-originate command, which doesn’t exist on the Nokia environment.

Site-to-Site IPSec over MPLS VPN

I want to start by saying I’ve over complicated everything because, well, it’s my lab and it’s fun for me. Depending on customer needs, a simple MPLS L2 VRF and an IPSEC tunnel on top would be sufficient, unless the sites also require internet service by the Service Provider delivering the VRF. In a simple MPLS VPN where the service simply connects sites to sites, the IP addresses are not advertised and could be a lot more secure than over the internet. Another advantage of utilizing an MPLS VPN is the ease of troubleshooting for the customer – the service traverses only one provider – not through the internet.

Lets take a deep dive at what an IPSEC tunnel looks like from an Enterprise perspective over a service provider MPLS L2/L3 VPN, not only from the CustomerSites but what actually happens inside the ServiceProvider network? In this case, we’ll be going from a statically configured site, which is Site-A on the left (Topology A below). The configuration is a Static L3 MPLS VRF provisioned with a Nokia Routed-VPLS utilizing a VRRP for Router-Redundancy (R2/R3). This is a common configuration provided by Service Providers to customers.
The MPLS VRF goes across the MPLS Core Network and terminates on R6 and R5. Both of these sites are participating in the same VRF (VPRN 100) and have an eBGP session set up to the CustomerSiteB on the right side.

A few key notes:
I’ve set up an AS-Path prepend from the Customer Router at Site B facing the eBGP session on R5 at
The Customer Site B router is currently load balancing across both eBGP neighbors to take full advantage of the dual-homed configuation.


Topology A.

MPLS Security?

An MPLS VPN (L2 or L3) Is secure to a certain degree. MPLS VPNs do not encrypt packets across the network, which makes it susceptible to eavesdropping by intruders.

Here is a wireshark capture without IPSEC between CustomerSiteA and R1. The traffic shows icmp request from CustomerSiteB to the Lo0 of CustomerSiteA.  As you can see, there is no encryption by the Service Provider and the service being delivered could easily be sniffed. How much do you trust your Service Provider?

Continue reading “Site-to-Site IPSec over MPLS VPN”