Hi,All,
I met strange issue of link protection in JUNOS5.4 in following
scenario:
ce1-------PE2----------P1--------PE3--------ce4
| | |
ce2------- |-----------P2---------|---------CE3
|-----------P3---------|
We setup 2 LSP, one is for CE1-to-CE4, the other is for CE2-to-CE3.
Both of them have the link protection enabled.
When LSP is up, another backup LSP named "Bypass_xxxx"is also up for
each main LSP.
Also "show RSVP session" can find the backup LSP is up.
The 1st question is , according to the manual that link protection will
setup the N:1 backup LSP.So those 2 LSP will share 1 backup LSP , I
think.
But the backup LSP is different two. It seems it still is one-to-one
backup, not facility backup as new IETF draft defined.
The 2nd question is we define the designated path for each main LSP.When
we shut down the protected link and expect the protection action, but
the traffic is cut.
We found step by step that after the main LSP disappears, the
"Bypass_xxx"LSP also disappears in the routing table.
There's some time during both LSP disappearing,we expect head-end can
temperately transfer the traffic to the "Bypass_xxx" LSP before it
re-calculate the new LSP.
It is very different with the "Fast reroute" feature.
In "fast reroute", it setups the backup LSP with the same name as the
main LSP.During the cutting,traffic isnot interrupted.
All the traffic transfers to the backup LSP.
But in this new "link-protection", it can't transfer to the backup LSP
and finally shows CSPF failed since no route to the "cutting" point.
The 3nd question is what's the difference of the head-end recalculation
with link protection and fast reroute?
Even head-end can't re-calculate the new path, fast reroute still can
reroute to the pre-setup LSP which doesn't complie with the contrained
CSPF path.
But link protection seems it must find a new correct contrained CSPF
path, no tempately transfer.
Is there some special configuration in link portection which is not
mentioned in the manual or some different implementation in JUNOS?
Thanks a lot.
Best Regards,
Liu Jun
I met strange issue of link protection in JUNOS5.4 in following
scenario:
ce1-------PE2----------P1--------PE3--------ce4
| | |
ce2------- |-----------P2---------|---------CE3
|-----------P3---------|
We setup 2 LSP, one is for CE1-to-CE4, the other is for CE2-to-CE3.
Both of them have the link protection enabled.
When LSP is up, another backup LSP named "Bypass_xxxx"is also up for
each main LSP.
Also "show RSVP session" can find the backup LSP is up.
The 1st question is , according to the manual that link protection will
setup the N:1 backup LSP.So those 2 LSP will share 1 backup LSP , I
think.
But the backup LSP is different two. It seems it still is one-to-one
backup, not facility backup as new IETF draft defined.
The 2nd question is we define the designated path for each main LSP.When
we shut down the protected link and expect the protection action, but
the traffic is cut.
We found step by step that after the main LSP disappears, the
"Bypass_xxx"LSP also disappears in the routing table.
There's some time during both LSP disappearing,we expect head-end can
temperately transfer the traffic to the "Bypass_xxx" LSP before it
re-calculate the new LSP.
It is very different with the "Fast reroute" feature.
In "fast reroute", it setups the backup LSP with the same name as the
main LSP.During the cutting,traffic isnot interrupted.
All the traffic transfers to the backup LSP.
But in this new "link-protection", it can't transfer to the backup LSP
and finally shows CSPF failed since no route to the "cutting" point.
The 3nd question is what's the difference of the head-end recalculation
with link protection and fast reroute?
Even head-end can't re-calculate the new path, fast reroute still can
reroute to the pre-setup LSP which doesn't complie with the contrained
CSPF path.
But link protection seems it must find a new correct contrained CSPF
path, no tempately transfer.
Is there some special configuration in link portection which is not
mentioned in the manual or some different implementation in JUNOS?
Thanks a lot.
Best Regards,
Liu Jun