[dev] Need Information About SR Tunnel Creation Using OSPF in FRR

Wed Apr 10 03:58:28 EDT 2019

Hello Shuvro,

Concerning the Adj SID, it is normal. First, Adj SID are automatically and dynamically allocated for all interface that belongs to the OSPF area for which SR is enable. Then, there is 2 Adj-SID: one for the nominal and one for the backup. In fact, one of the Adj SID could be protected not the other one. Please, refer to https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-27#section-6 for the detail of the Adj-SID flag.

Regards

Olivier

Le 10/04/2019 à 07:43, Shuvro a écrit :
> Hi Oliver,
>
> Thanks a lot for your candid reply.It helped me immensely.One more point I wish to clarify regarding SR config:
>
> When I configure OSPF-SR ,I can see that the connected interfaces are getting adj SID labels though it has not been configured explicitly.
>
> You can see the below snippet:
> config Snippet:
> -----------------
> router ospf
>  ospf router-id 1.1.1.1
>  network 1.1.1.1/32 <http://1.1.1.1/32> area 0
>  network 20.1.1.0/24 <http://20.1.1.0/24> area 0
>  capability opaque
>  mpls-te on
>  mpls-te router-address 1.1.1.1
>  segment-routing on
>  segment-routing global-block 10000 19999
>  segment-routing node-msd 8
>  segment-routing prefix 1.1.1.1/32 <http://1.1.1.1/32> index 1100
>  router-info area
>
> Show CLI Snippet:
> -------------------------------
> sh ip ospf database segment-routing 
>
> OSPF Segment Routing database for ID 1.1.1.1
>
> SR-Node: 2.2.2.2SRGB (Size/Label): 10000/10000Algorithm(s): SPFMSD: 8
>
>     Prefix or Link  Label In  Label Out       Node or Adj. SID  Interface          Nexthop
> ------------------  --------  ---------  ---------------------  ---------  ---------------
>         2.2.2.2/32 <http://2.2.2.2/32>     11200      11200      SR Pfx (idx 1200)       eth3         20.1.1.2
>
> SR-Node: 1.1.1.1SRGB (Size/Label): 10000/10000Algorithm(s): SPFMSD: 8
>
>     Prefix or Link  Label In  Label Out       Node or Adj. SID  Interface          Nexthop
> ------------------  --------  ---------  ---------------------  ---------  ---------------
>         1.1.1.1/32 <http://1.1.1.1/32>         0          0      SR Pfx (idx 1100)         lo          1.1.1.1
>        20.1.1.1/32 <http://20.1.1.1/32>     50001        pop    SR Adj. (lbl 50001)       eth3         20.1.1.2
>        20.1.1.1/32 <http://20.1.1.1/32>     50000        pop    SR Adj. (lbl 50000)       eth3         20.1.1.2
>
> Here,20.1.1.2 is the connected interface which has appeared twice with two adj labels being mapped to it.Any pointer why is it so?
>
> Why adj-SID is getting configured without explicit configuration and why same interface is getting two labels?
>
>
> Thanks,
> Shuvro
>
> On Tue, Apr 9, 2019 at 5:09 PM <olivier.dugeon at orange.com <mailto:olivier.dugeon at orange.com>> wrote:
>
>     Hi Shuvro,
>
>
>     Le 09/04/2019 à 08:51, Shuvro a écrit :
>>     Hi Team,
>>
>>     I want to create one SR tunnel between 4 FRR nodes where one node will be used as head-end node which will be used to push the label stack.SRGB in all these nodes will be same(10000-19999).I am going to use the loopback interface for node SID. I have few questions in this regard:
>>     (1) How can I use one dummy interface as loopback in case of SR,I have tried using a dummy interface previously for vanilla OSPF and BGP,it works fine but in case of SR config,it complains:
>>     not a loopback interface
>     For that purpose, just add `ip address 10.0.0.1` (change 10.0.0.1 by the IP address is suitable for your testbed) for the lo interface in the zebra.conf file. This will add IP address to the loopback interface. You could also do that at the Linux layer with the `ip addr add ...` command.
>     But, I think it is safer to configure it within FRR
>
>>     (2)To provision the tunnel effectively,how can I use prefix SID for the connected interfaces.
>>     I was using:
>>     ip route x.x.x.x/mask <gateway> label as the node SID 
>>     Here,how can I configure prefix SID for the prefixes other than the node prefix.
>     UP to now, prefix SID are not supported. What you could perform is to add a static route to a given prefix and specify the label stack. Be careful for the label value. It is the real label value not the node SID. In your case, if the first router has a node SID equal to 100, the label will 10100 regarding your SRGB.
>
>>     (3)How can I verify the tunnel in the data plane (e.g. ping works fine).
>     Of course ping will work without SR due to OSPF routing. If you would check that the configuration is in place, you could perform a 'show ip route', 'show mpls table', show mpls fec' and at the Linux kernel 'ip route'. Now, if you run ping command, just launch a whiresharl/tshark/tcpdump tool to check that the ICMP packets are correctly encapsulated with MPLS.
>
>>
>>     Any sample config in this regard will be helpful.
>
>     OSPF Segment Routing documentation is here: http://docs.frrouting.org/projects/dev-guide/en/latest/ospf-sr.html#ospf-segment-routing and you could find some examples in OSPF SR topotest here: http://docs.frrouting.org/projects/dev-guide/en/latest/ospf-sr.html#ospf-segment-routing (the configurations are under r1 - r4 directory)
>
>     Let me know if you have any trouble
>
>     Regards
>
>     Olivier
>>
>>     Thanks,
>>     Shuvro
>>
>>
>>     _______________________________________________
>>     dev mailing list
>>     dev at lists.frrouting.org <mailto:dev at lists.frrouting.org>
>>     https://lists.frrouting.org/listinfo/dev
>
>     _________________________________________________________________________________________________________________________
>
>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>     they should not be distributed, used or copied without authorisation.
>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>     Thank you.
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20190410/f25a9e70/attachment-0001.html>