<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font face="DejaVu Sans">Hello Shuvro,</font></p>
<p><font face="DejaVu Sans"><font face="DejaVu Sans">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 nomi<font face="DejaVu Sans">nal and one for the
backup. In fact, one of the Adj SID could be protected not
the other one. Please, refer to <a moz-do-not-send="true"
href="https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-27#section-6">https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-27#section-6</a>
for the detail of the Adj-SID flag.</font></font></font><br>
</p>
Regards<br>
<br>
Olivier<br>
<br>
<div class="moz-cite-prefix">Le 10/04/2019 à 07:43, Shuvro a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAObOyW1Ez=TfXH8SfiKfJVjjHNrY7RsZBhX7Fg-vGjgi348c7A@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi Oliver,
<div><br>
</div>
<div>Thanks a lot for your candid reply.It helped me
immensely.One more point I wish to clarify regarding SR
config:</div>
<div><br>
</div>
<div>When I configure OSPF-SR ,I can see that the connected
interfaces are getting adj SID labels though it has not
been configured explicitly.</div>
<div><br>
</div>
<div>You can see the below snippet:</div>
<div>config Snippet:</div>
<div>-----------------</div>
<div>
<div>router ospf</div>
<div> ospf router-id 1.1.1.1</div>
<div> network <a href="http://1.1.1.1/32"
moz-do-not-send="true">1.1.1.1/32</a> area 0</div>
<div> network <a href="http://20.1.1.0/24"
moz-do-not-send="true">20.1.1.0/24</a> area 0</div>
<div> capability opaque</div>
<div> mpls-te on</div>
<div> mpls-te router-address 1.1.1.1</div>
<div> segment-routing on</div>
<div> segment-routing global-block 10000 19999</div>
<div> segment-routing node-msd 8</div>
<div> segment-routing prefix <a href="http://1.1.1.1/32"
moz-do-not-send="true">1.1.1.1/32</a> index 1100</div>
<div> router-info area</div>
</div>
<div><br>
</div>
<div>Show CLI Snippet:</div>
<div>-------------------------------</div>
<div>
<div>sh ip ospf database segment-routing </div>
<div><br>
</div>
<div><span style="white-space:pre"> </span>OSPF Segment
Routing database for ID 1.1.1.1</div>
<div><br>
</div>
<div>SR-Node: 2.2.2.2<span style="white-space:pre"> </span>SRGB
(Size/Label): 10000/10000<span style="white-space:pre"> </span>Algorithm(s):
SPF<span style="white-space:pre"> </span>MSD: 8</div>
<div><br>
</div>
<div> Prefix or Link Label In Label Out Node or
Adj. SID Interface Nexthop</div>
<div>------------------ -------- ---------
--------------------- --------- ---------------</div>
<div> <a href="http://2.2.2.2/32"
moz-do-not-send="true">2.2.2.2/32</a> 11200
11200 SR Pfx (idx 1200) eth3 20.1.1.2</div>
<div><br>
</div>
<div>SR-Node: 1.1.1.1<span style="white-space:pre"> </span>SRGB
(Size/Label): 10000/10000<span style="white-space:pre"> </span>Algorithm(s):
SPF<span style="white-space:pre"> </span>MSD: 8</div>
<div><br>
</div>
<div> Prefix or Link Label In Label Out Node or
Adj. SID Interface Nexthop</div>
<div>------------------ -------- ---------
--------------------- --------- ---------------</div>
<div> <a href="http://1.1.1.1/32"
moz-do-not-send="true">1.1.1.1/32</a> 0
0 SR Pfx (idx 1100) lo 1.1.1.1</div>
<div> <a href="http://20.1.1.1/32"
moz-do-not-send="true">20.1.1.1/32</a> 50001
pop SR Adj. (lbl 50001) eth3 20.1.1.2</div>
<div> <a href="http://20.1.1.1/32"
moz-do-not-send="true">20.1.1.1/32</a> 50000
pop SR Adj. (lbl 50000) eth3 20.1.1.2</div>
</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Why adj-SID is getting configured without explicit
configuration and why same interface is getting two
labels?</div>
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Shuvro</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Apr 9, 2019 at 5:09 PM
<<a href="mailto:olivier.dugeon@orange.com"
moz-do-not-send="true">olivier.dugeon@orange.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><font face="DejaVu Sans">Hi Shuvro,</font></p>
<br>
<div class="gmail-m_-6979947513778747861moz-cite-prefix">Le
09/04/2019 à 08:51, Shuvro a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Team,
<div><br>
</div>
<div>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:</div>
<div>(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:</div>
<div>not a loopback interface</div>
</div>
</blockquote>
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.<br>
But, I think it is safer to configure it within FRR<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>(2)To provision the tunnel effectively,how can I
use prefix SID for the connected interfaces.</div>
<div>I was using:</div>
<div>ip route x.x.x.x/mask <gateway> label as the
node SID </div>
<div>Here,how can I configure prefix SID for the
prefixes other than the node prefix.</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>(3)How can I verify the tunnel in the data plane
(e.g. ping works fine).</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Any sample config in this regard will be helpful.</div>
</div>
</blockquote>
<br>
OSPF Segment Routing documentation is here:
<a class="gmail-m_-6979947513778747861moz-txt-link-freetext"
href="http://docs.frrouting.org/projects/dev-guide/en/latest/ospf-sr.html#ospf-segment-routing"
target="_blank" moz-do-not-send="true">http://docs.frrouting.org/projects/dev-guide/en/latest/ospf-sr.html#ospf-segment-routing</a>
and you could find some examples in OSPF SR topotest here:
<a class="gmail-m_-6979947513778747861moz-txt-link-freetext"
href="http://docs.frrouting.org/projects/dev-guide/en/latest/ospf-sr.html#ospf-segment-routing"
target="_blank" moz-do-not-send="true">http://docs.frrouting.org/projects/dev-guide/en/latest/ospf-sr.html#ospf-segment-routing</a>
(the configurations are under r1 - r4 directory)<br>
<br>
Let me know if you have any trouble<br>
<br>
Regards<br>
<br>
Olivier<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Thanks,</div>
<div>Shuvro</div>
</div>
<br>
<fieldset
class="gmail-m_-6979947513778747861mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
dev mailing list
<a class="gmail-m_-6979947513778747861moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org" target="_blank" moz-do-not-send="true">dev@lists.frrouting.org</a>
<a class="gmail-m_-6979947513778747861moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev" target="_blank" moz-do-not-send="true">https://lists.frrouting.org/listinfo/dev</a>
</pre>
</blockquote>
<br>
<pre>_________________________________________________________________________________________________________________________
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.
</pre>
</div>
</blockquote>
</div>
</blockquote>
<br>
<PRE>_________________________________________________________________________________________________________________________
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.
</PRE></body>
</html>