Showing posts with label BGP. Show all posts
Showing posts with label BGP. Show all posts

Thursday, March 12, 2026

Flex-Algo Configuring on Nokia 7750 SR and steering VPRN traffic via Flex-algo 129 : A Step-by-Step Implementation Guide

Flex Algo provides the mechanism for IGP to use constraint-based paths like RSVP or SR TE using ISIS or OSPF extensions. By default, ISIS uses default algorithm 0. Along with it, there are 128 to 255 algorithms supported in Nokia. 

As of writing, Nokia does not support flex-algo 1. but it does supported by juniper because we have identified during a project to swap Juniper MX with Nokia 7750 SR

All the routers participating in the Flex Algorithm should have the same definition of how it should work.

Consider the SRGB block of 2000-3000. To reach prefix F1, index-1, algorithm 0, label is 2001, then we have prefix F2, index-101, algorithm 128 and to reach F2 label is 2101

Nokia supports Flex algo 128, 129 and 130.

 



By default the IGP cost-based tunnel travels through PE5 to PE3 via PE5-PE1-ASBR1-ASBR3-PE5. 

Let's configure Flex Algo 129 based on delay and push the traffic towards PE5-PE5-PE2-ASBR2-ASBR4-PE4-PE3.

*A:PE5>config>router>fad>flex-algo$ metric-type

{igp|te-metric|delay}

We can map the flex algo to SR-MPLS as well or steer traffic to SR-TE.

Delay metric:

We can configure the delay metric statically or dynamically and advertise it in ISIS or OSPF. 

Configuring the delay metric on the interface directly.

        interface "PE1"

            if-attribute

                delay

                    static 100000

                exit

            exit

            no shutdown

        exit

        interface "PE6"

            if-attribute

                delay

                    static 10000

                exit

            exit

            no shutdown

        exit

As per our topology, shortest path to reach the PE5 to PE3 is via PE1 through IGP metric calculation. 

Propogating the delay in IGP

*A:PE5>config>router>isis# info

----------------------------------------------

            level-capability level-2

            area-id 49.0001

            traffic-engineering-options

                advertise-delay

                application-link-attributes

                exit

            exit

We can configure both static and dynamic delay together and have the option to configure which one we prefer. I am using a static delay. In a later blog, we will use the dynamic delay calculation using twamp.








Configuring the flex algo and metric-type










ISIS advertising flex algo 129 and delay as metric type



A:PE3>conf>router>segment-routing# info

            sr-mpls

                prefix-sids "system"

                    ipv4-sid index 13

                    flex-algo 129

                        ipv4-sid index 53

                    exit

                exit

            exit

            sr-policies

                shutdown

                reserved-label-block "sr-policy"

            exit

A:PE3>conf>router>segment-routing# sr-mpls prefix-sids "system"

A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# flex-algo 129 no ipv

ipv4-sid  ipv6-sid

A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# flex-algo 129 no ipv4-sid

*A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# info

----------------------------------------------

                    ipv4-sid index 13

                    flex-algo 129

                    exit

----------------------------------------------

*A:PE3>config>router>segment-routing>sr-mpls>prefix-sids# no flex-algo 129

*A:PE3>config>router>isis# interface "system" flex-algo

<[128..255]>

 

*A:PE3>config>router>isis# interface "system" flex-algo 129

ipv4-node-sid   ipv6-node-sid

*A:PE3>config>router>isis# interface "system" flex-algo 129 ipv4-node-sid

index <[0..4294967295]>

label <[0..4294967295]>


*A:PE3>config>router>isis# interface "system" flex-algo 129 ipv4-node-sid index 53

A:PE3>config>router>isis# info

            interface "system"

                level-capability level-2

                passive

                flex-algo 129

                    ipv4-node-sid index 53

                exit

                no shutdown

            exit

*A:PE2>conf>router>segment-routing# sr-mpls prefix-sids "system" no flex-algo 129

*A:PE2>conf>router>segment-routing#

*A:PE2>conf>router>segment-routing#

*A:PE2>conf>router>segment-routing# /co

configure  compare

*A:PE2>conf>router>segment-routing# /conrouter is

                                   ^

Error: Bad command.

*A:PE2>conf>router>segment-routing# /configure router isis 1

*A:PE2>config>router>isis# interface "system" flex-algo      

<[128..255]>

*A:PE2>config>router>isis# interface "system" flex-algo 129  

ipv4-node-sid   ipv6-node-sid

*A:PE2>config>router>isis# interface "system" flex-algo 129 ipv4-node-sid index 52

After swapping the flex-algo index from shared sid to system interface under isis. Route-table is populated with routes. Output below

A:PE5# show router tunnel-table

 

===============================================================================

IPv4 Tunnel Table (Router: Base)

===============================================================================

Destination           Owner     Encap TunnelId  Pref   Nexthop        Metric

   Color                                                             

-------------------------------------------------------------------------------

1.0.0.1/32 [L]        isis (1)  MPLS  524359    11     10.1.5.1       10

1.0.0.2/32 [L]        isis (1)  MPLS  524372    11     10.1.5.1       20

1.0.0.2/32            isis (1)  MPLS  524379    11     10.5.6.6       18000


















From below output we need to fix the PE4 to advertise the flex algo 129 route properly


















After remapping the flex-algo node index under the ISIS context, now we see tunnel table entries separately for algo 0 and algo 129.








Steering traffic using an auto-bind tunnel, or we can use the Flex algorithm label used for 129 under path in SR-TE.

Let's use an auto-bind tunnel via VPRN service and make it work end to end to use flex-algo for VPRN traffic









Now we can see that for the PE3 destination, we have SR-ISIS flex-algo 129 tunnel based on delay installed.






Tuesday, March 3, 2026

Implementing BGP-Signaled SR Policy on Nokia 7750 SR

In the previous post, we discussed the SR-Static policy on the local router. Do we have the option to create a policy and advertise to other routers in the network? Then yes, it is possible to send the SR policy from the centralized controller or from the SR-OS routers within the network.

Let’s configure and advertise the SR policy from ASBR1 using BGP for PE3 to PE5.

It’s like the previous configuration, but the only difference is we mention the headend router ip address of PE3.

PE3 to PE5 SR policy

Enabling the sr-policy ipv4 in bgp family and importing the sr-policy, the sr-policy-import command in bgp allows the static policy to be advertised in BGP except for the local policy.

Enabling the sr-policy-ipv4 family under BGP neighbors

SR-policy advertisement from ASBR1

BGP advertisement of SR policy

PE3 to PE6 sr-policy verification


LSP trace confirms the traffic via the sr-policy path


SR-Policy Route installed in the tunnel table


PE5: Adding color to the route advertisement from PE5 to PE3



Add the policy in VPRN import/export policy

We can see the PE5 adding the color while advertising the routes to PE3


SR-policy applied for the route towards PE5 

Ping between PE3 and PE5 via SR policy









Monday, April 3, 2023

BGP Prefix Limit Configuration in Cisco, Juniper and Nokia - Interop

BGP Prefix Limit

Maximum Prefix-limit is used to control the BGP peer not to overload your BGP routing table and it helps to avoid the situation. let's explore how to configure in Cisco, Juniper, and Nokia router


Cisco Configuration

 !
router bgp 300
 neighbor 192.168.1.1
  address-family ipv4 unicast
   maximum-prefix <max-limit> <percentage> <Actions>
  !
 !

Juniper  Configuration

edit protocol
bgp {
        group nokia {
            neighbor 192.168.0.1 {
                family inet {
                    unicast {
                        prefix-limit {
                            maximum 1000;
                            teardown;
                        }
                    }


Nokia Configuration

/configure router bgp
            group "juniper"
                type external
                local-as 100
                neighbor 192.168.0.2
                    prefix-limit <family> <prefix-limit>
                    peer-as 200
                exit

   


TCP AO configuration on Cisco, Juniper and Nokia SR - Interop Configuration

TCP-AO is a new authentication method proposed through RFC5925, The TCP Authentication Option to enhance the security and authenticity of TCP segments exchanged during BGP.

 It supports both IPv4 and IPv6 traffic


Benefits of TCP-AO




Support multiple stronger algorithms, such as HMAC-SHA1 and AES-128 to create an internal traffic key and message digest.

Add a new user-configured key to re-generate internal traffic keys for an established connection and a mechanism to synchronize key change between BGP peers

Nokia Configuration

/configure system security 

keychain "aes-128-cmac-96-keychain"

                tcp-option-number

                    send tcp-ao

                    receive tcp-ao

                exit

                direction

                    uni

                        send

                            entry 20 key “key”algorithm aes-128-cmac-96

                                begin-time 2023/04/03 08:22:32 UTC

                            exit

                        exit

                        receive       

                            entry 10 key “key” algorithm aes-128-cmac-96

                                begin-time 2023/04/03 08:23:24 UTC

                            exit

                        exit

                    exit

                exit

                no shutdown

            exit

Apply the TCP AO authentication under BGP neighbor or Group

/configure router bgp group "juniper"

                type external

                local-as 100

                neighbor 192.168.0.2

                 auth-keychain "aes-128-cmac-96-keychain"

                exit

            exit


Juniper Configuration#

security {                              

    authentication-key-chains {

        key-chain nokia {

            tolerance 30;

            key 10 {

                secret "$9$vxA87Vg4ZiqfDi/t0OSy7-Vb2aZGiq.5"; ## SECRET-DATA

                start-time "2023-2-1.00:00:00 +0000";

                algorithm ao;

                ao-attribute {

                    send-id 10;

                    recv-id 20;

                    tcp-ao-option enabled;

                    cryptographic-algorithm aes-128-cmac-96;

                }

            }

Apply the TCP AO authentication under BGP neighbor or Group

set protocols bgp group nokia authentication-algorithm ao


Cisco XR Configuration#

key chain AS300

 key 0

  accept-lifetime 00:00:00 april 01 2023 infinite

  key-string password 0701245859060B0E1B1309

  send-lifetime 00:00:00 april 01 2023 infinite

  cryptographic-algorithm MD5

 !

!

key chain AS300

 key 1

  accept-lifetime 00:00:00 april 01 2023 infinite

  key-string password 0701245859060B0E1B1309

  send-lifetime 00:00:00 april 01 2023 infinite

  cryptographic-algorithm MD5

 !

!

router bgp 300

 neighbor 192.168.1.1

  keychain AS300

 !



BGP MD5 Configuration on Cisco - Juniper - Nokia Interop

 In this blog, I will explain the benefits of the MD5 concept and how to configure it on Cisco, Juniper, and Nokia Router

TCP-MD5

MD5 is used to protect the BGP session between the peers to form the secured session over the public Network. 

TCP MD5 option supports only one key for a connection. Further, it only supports the MD5 algorithm. The MD5 algorithm takes the “secret” from the key and the TCP segment for encryption and generates a message digest. This message digest is then copied to the MD5 digest field in the TCP segment and is sent to the receiving device.





Cisco XR

router bgp 300
 neighbor 192.168.1.1
  password encrypted 011D03104C0414042D4D4C


Juniper

edit protocols {                             
    bgp {
        group nokia {
            neighbor 192.168.0.1 {
                authentication-key "key"; ## SECRET-DATA
                }
      
Nokia

/configure router 
protocols {                             
    bgp {
     group "juniper"
                type external
                local-as 100
                neighbor 192.168.0.2
                    authentication-key "D8XsPtn4bCNLm" hash2
                    peer-as 200
                exit


BGP Protection - TTL Security Configuratoion Cisco, Juniper and Nokia

Hi Everyone,

In the blog, I am going to explain how TTL security is useful in BGP Session protection. Time to Live will be added to every packet and it will be reduced at each hop it transfers.

Consider someone who wants to hack your BGP session and will send the spoofed  BGP packets and try to negotiate with your BGP session. to avoid this kind of spoofing we use TTL Security


TTL security is a mechanism that evaluates the TTL value of incoming IP packets to ensure

that they have not been faked. The IP TTL value will be set to 255 by directly connected BGP

peers, making it impossible to relay spoof Internet protocol with TTL=255 through non

directly connected interfaces.



Cisco XR

router bgp 100
 neighbor-group ebgp
  ttl-security
 !
neighbor 192.168.1.1
  remote-as 100
  use neighbor-group ebgp
  address-family ipv4 unicast
  !
 !


Juniper 


protocols {                             
    bgp {
        group nokia {
            type external;
            neighbor 192.168.0.1 {
                ttl <1-255>;
                peer-as 100;
                local-as 200;
            }


Nokia vSR


router bgp 
 group "juniper"
                type external
                local-as 100
                ttl-security <1-255>
                neighbor 192.168.0.2
                    peer-as 200
                exit
            exit







Saturday, December 26, 2020

Nokia 7750 SR BGP Next-Hop-Self (NHS) configuration

In our previous blog, we configured iBGP between Nokia SR Routers. PE01 received routes from CE via eBGP and advertised them to PE02.

Nokia Router (Alcatel-Lucent) BGP configuration Basic

Let's explore the output of PE02 for the prefix 10.10.10.5/32 advertised from CE01.


Prefix 10.10.10.5/32  is available in the BGP table of PE02


as per the below output, the route is not installed in the routing table of PE02. lets us explore the reason for not installing in its routing table of PE02.


From the above Output says that Invalid IGP for the next-hop advertised by the PE01 for the 
prefix 10.10.10.5.

By default when the route is advertised from ebgp it will change the next-hop to its own IP.
but in the case of iBGP, let's apply the policy to change the next-hop.

/configure router bgp group ibgp-internal next-hop-self 

After configuring the next-hop-self command on PE01, Now PE01 advertising its IP as net-hop for the 
prefix 10.1.5.5 and installing it in routing table. 
 



Friday, December 25, 2020

Nokia Router 7750 SR BGP Basic configuration

Let's explore few concepts of BGP and how to configure it on the Nokia 7750 SR

Border gateway protocol is mainly used by Service Providers to carry the huge routing information between different Autonomous Systems.

It uses the well-known TCP port number 179. BGP uses TCP protocol for authenticating its peer router session.

There are two types of BGP as listed below

1. IBGP (Internal BGP used to share routing information within its own AS)

2. Ebgp (External BGP used to share routing information between 2 different AS)

Let's explore how to configure BGP types as per the below topology. IGP is pre-configured as per topology.


1. IBGP configuration between PE01 to PE02 

Forming IBGP between Router system IP/Loopback address is a best practice for family ipv4.

why are we configuring internal BGP on SYSTEM/LOOPBACK IP?

If we configure the adjacency using the physical interface for the ipv4 family it will lead to failure if that particular interface goes down.

Even if we have an alternate path to reach the router it will not be useful if we configure it in the physical interface once the interface goes down.

PE01:  10.10.10.1
PE02:  10.10.10.2

PE01:

/configure router bgp autonomous 

/configure router bgp group "ibgp-internal"

/configure router bgp group "ibgp-internal" neighbor 10.10.10.2

/configure router bgp group "ibgp-internal" neighbor 10.10.10.2 type internal

/configure router bgp group "ibgp-internal" neighbor 10.10.10.2 peer-as 65001


PE02:

/configure router bgp autonomous 

/configure router bgp group "ibgp-internal"

/configure router bgp group "ibgp-internal" neighbor 10.10.10.1

/configure router bgp group "ibgp-internal" neighbor 10.10.10.1 type internal

/configure router bgp group "ibgp-internal" neighbor 10.10.10.1 peer-as 65001

To bring up the BGP one more configuration is required. Need to configure the autonomous system to bring the session up.

/configure router autonomous-system 65001

Let's verify the BGP output:

PE01# show router BGP summary all 
===================================================================
BGP Summary
===================================================================
Neighbor
Description
ServiceId          AS PktRcvd InQ  Up/Down   State|Rcv/Act/Sent (Addr Family) PktSent OutQ
-------------------------------------------------------------------------------------------------------------------
10.10.10.2
Def. Instance   65001       9    0 00h03m22s 0/0/0 (IPv4)  9    0 
         
-------------------------------------------------------------------------------------------------------------------

By default in Nokia SR, it will form the family IPV4 neighborship if we don't configure any family under the BGP configuration hierarchy.


2. eBGP configuration between PE01 and CE01

External BGP configured between PE01 and CE01 router. CE01 advertise prefixes to PE01 and it propagates it's further to PE02 via pre-configured IBGP session.


PE01:

/configure router bgp group "ebgp-external"

/configure router bgp group "ebgp-external" neighbor 10.1.5.5

/configure router bgp group "ebgp-external" neighbor 10.1.5.5 type external

/configure router bgp group "ebgp-external" neighbor 10.1.5.5 peer-as 65002


CE01:

/configure router bgp group "ebgp-external"

/configure router bgp group "ebgp-external" neighbor 10.1.5.1

/configure router bgp group "ebgp-external" neighbor 10.1.5.1 type external

/configure router bgp group "ebgp-external" neighbor 10.1.5.1 peer-as 65001


CE advertising its system IP to PE01:

CE01# show router BGP summary all 
====================================================================
BGP Summary
====================================================================
Neighbor
Description
ServiceId          AS PktRcvd InQ  Up/Down   State|Rcv/Act/Sent (Addr Family)  PktSent OutQ
------------------------------------------------------------------------------------------------------------------
10.1.5.1
Def. Instance   65001      53    0 00h03m30s 0/0/1 (IPv4) 55    0 
         
------------------------------------------------------------------------------------------------------------------

Routes received on PE01 router from CE:

PE01# show router bgp routes 
=========================================================================
 BGP Router ID:10.10.10.1       AS:65001       Local AS:65001      
=========================================================================
 Legend -
 Status codes  : u - used, s - suppressed, h - history, d - decayed, * - valid
                 l - leaked, x - stale, > - best, b - backup, p - purge
 Origin codes  : i - IGP, e - EGP, ? - incomplete
=========================================================================
BGP IPv4 Routes
=========================================================================
Flag  Network                                            LocalPref   MED
      Nexthop (Router)                                   Path-Id     Label
      As-Path                                                        
-------------------------------------------------------------------------------
u*>i  10.10.10.5/32                                      None        None
      10.1.5.5                                                   None        -
      65002                                                           

-------------------------------------------------------------------------------
Routes : 1
=========================================================================

PE01 receiving the route from its external BGP and advertises it to PE02 via IBGP.

PE01# show router bgp summary all 
=========================================================================BGP Summary
=========================================================================Neighbor
Description
ServiceId          AS PktRcvd InQ  Up/Down   State|Rcv/Act/Sent (Addr Family) PktSent OutQ
------------------------------------------------------------------------------------------------------------------
10.1.5.5
Def. Instance   65002      35    0 00h03m52s 1/1/1 (IPv4) 60    0           
10.10.10.2
Def. Instance   65001      50    0 00h23m30s 0/0/1 (IPv4) 50    0           
-------------------------------------------------------------------------------------------------------------------

From the above output, we can see 10.1.5.5 is receiving a route via external BGP and advertising it back to its iBGP peer of 10.10.10.2 PE02.

In our, Next Post let's analyze the routes on the PE02 router and how it's installing it in the routing table.