RSVP issue on Huawei - Juniper - Huawei devices

Created Dec 06, 2018 18:42:11Latest reply Dec 11, 2018 15:13:02 261 7 0 0
  E coins as reward: 0 (problem unresolve)
This post was last edited by Bart_Oxy at 2018-12-6 18:52.    Hello, I have a issue about LSP transit for RSVP protocol on Juniper and Huawei devices.

I`d like to start a RSVP tunnel through Huawei1 --> Huawei2 --> Juniper --> Huawei3. Tunnel is not estabishing, beacuse Juniper blocks create LSP to directly connected Huawei.
Everything works when I create tunnel through Huawei1 --> Huawei2 or Huawei1 --> Juniper. Juniper MX104 works correctly as Ingress or Ergress, but not works as a transit device.
Juniper does not have any entries in the mpls.0 table (which serves as a transit table) for RSVP (LSP paths, of course, work flawlessly)

What could be wrong?
What was done:

1. family mpls enabled on interfaces directly connected to others Huawei switches
2. Interfaces above added to protocol RSVP
3. Interfaces above added to protocol mpls. I create some test tunnels (as ingress works correctly - LSP works)
4. traffic-engineering is enabled, in future I`d like to use fast-reroute.


Configuration and info about my verification:
HUAWEI:
mpls 
mpls te 
mpls te auto-frr 
mpls rsvp-te 
mpls rsvp-te hello
mpls rsvp-te srefresh 
mpls te cspf


interface Vlanif580 
ip address IP1 
pim sm 
ospf cost 30 
mpls 
mpls mtu 9000 
mpls te 
mpls rsvp-te 
mpls rsvp-te hello 
mpls ldp

ospf 1 
opaque-capability enable   
area 0.0.0.0                               
network IP1 MASK1  
netowrk IP2 MASK2  
mpls-te enable



JUNIPER:
user-admin@rt01-jn-01# show protocols rsvp 
traceoptions {     file rsvp-log; }
interface xe-0/2/0.580;
interface xe-1/1/0.500;
interface ae1.530;
interface lo0.0;  


user-admin@rt01-jn-01# show protocols mpls 
ipv6-tunneling;
label-switched-path to-rt02-hw-01
{     from IP1;    
       to IP2;    
       no-cspf; }
label-switched-path to-rt02-hw-02
{     from IP3;   
       to IP4; }
interface xe-0/2/0.580;
interface xe-1/1/0.500;
interface ae1.530;
interface lo0.0;




 Verified:

1. RSVP sessions are UP - when Juniper works as Ingress
2. Neighborship with Huawei is established - my question: neighborship was established only on ip addresses of connected interfaces (on loopback interfaces there is an IDLE status) - I think it`s correct state, because on ip address of connected  interfaces routers "speak" together, am I right?



RSVP neighbor: 6 learned
Address                       Idle    Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
Loopback-Neighbor1 1:07:38  0/0  5d 8:33:26        9 51423/0    0
Loopback-Neighbor2 1:07:38  0/0  5d 8:33:26        9 51423/0    0
Loopback-Neighbor3 1:07:38  0/0  5d 8:33:26        9 51423/0    0
IntAddr-Neighbor1     0  1/0  4d 20:03:10        9 144151/139146 21182
IntAddr-Neighbor2     0  1/0  4d 19:56:25        9 144083/139033 20998
IntAddr-Neighbor3     0  1/0  4d 19:59:07        9 144140/139108 10631

 
Maybe someone know, where I make a mistake?
  • x
  • convention:

lizhi94     Created 4 days ago Helpful(0) Helpful(0)

please provide the version of huawei switch by(display version)command
  • x
  • convention:

lizhi94     Created 4 days ago Helpful(0) Helpful(0)

  • x
  • convention:

cWX611640  Admin   Created 4 days ago Helpful(0) Helpful(0)

@Bart_Oxy hello sir, can you speciy the version of the firmware? or you can try the solution of @lizhi94 in 3#
  • x
  • convention:

Bart_Oxy     Created 4 days ago Helpful(0) Helpful(0)

Hello,
firmware  version:
Huawei Versatile Routing Platform Software
VRP (R) software, Version 5.160 (S6720 V200R008C00SPC500)
Copyright (C) 2000-2015 HUAWEI TECH CO., LTD
HUAWEI S6720-30C-EI-24S-AC

Of course I use commands from post #3:
mpls
mpls te
mpls te auto-frr
mpls rsvp-te
mpls rsvp-te hello
mpls rsvp-te srefresh
mpls te cspf


interface Vlanif580
ip address IP1
pim sm
ospf cost 30
mpls
mpls mtu 9000
mpls te
mpls rsvp-te
mpls rsvp-te hello
mpls ldp

ospf 1
opaque-capability enable
area 0.0.0.0
network IP1 MASK1
netowrk IP2 MASK2
mpls-te enable


  • x
  • convention:

lizhi94     Created 3 days ago Helpful(0) Helpful(0)

The same key must be configured on the two nodes involved in authentication. When sending a packet, a node calculates a digest using the HMAC-MD5 algorithm based on the configured key. The digest is carried in the packet as an integrity object to the peer node. The peer node calculates the digest using the same algorithm based on the configured key, and compares the two digests. If the two digests are the same, it accepts the packet; otherwise, it discards the packet. RSVP authentication, however, cannot prevent the anti-replay attack and solve the problem of neighbor relationship termination resulted from disordered RSVP messages. To solve these problems, RSVP authentication extensions are introduced. The RSVP authentication extensions include the authentication lifetime, authentication handshake mechanism, and sliding window mechanism based on the original authentication mechanism. They can improve the RSVP security and enhance the user authentication in an adverse network environment such as network congestion.
RSVP supports two authentication modes:

◾Neighbor-oriented authentication

In this mode, you can configure authentication information such as authentication keys based on different neighbor addresses. RSVP then authenticates each neighbor separately.

Neighbor-oriented authentication can be configured in two ways:

1. Configured based on an interface IP address of the neighbor.

2. Configured based on the LSR ID of the neighbor.


◾Interface-oriented authentication

◾If interface-oriented authentication is configured, RSVP authenticates packets based on their inbound interfaces.
◾Neighbor-oriented authentication takes precedence over interface-oriented authentication. Packets that fail authentication are discarded. If neighbor-oriented authentication is not enabled, interface-oriented authentication takes effect.
<http://support.huawei.com/hedex/ ... ocid=EDOC1000081667>

  • x
  • convention:

lizhi94     Created 3 days ago Helpful(0) Helpful(0)

mpls te auto-frr (MPLS view)



Function


The mpls te auto-frr command globally enables the TE Auto FRR function.

The undo mpls te auto-frr command globally disables the TE Auto FRR function.

TE Auto FRR is disabled by default.


Format


mpls te auto-frr

undo mpls te auto-frr


Parameters


None


Views


MPLS view


Default Level


2: Configuration level


Usage Guidelines


Usage Scenario

You can run the mpls te auto-frr command to globally enable the TE Auto FRR function.

Precautions

After the TE Auto FRR function is enabled globally, all MPLS TE-enabled interfaces use node protection by default.

If TE Auto FRR is enabled globally, all interfaces that are enabled with MPLS TE on the device are automatically configured with the mpls te auto-frr default command by default. To disable TE Auto FRR on certain interfaces, run the mpls te auto-frr block command on these interfaces.


Example


# Enable the TE Auto FRR function.
<HUAWEI> system-view
[HUAWEI] mpls
[HUAWEI-mpls] mpls te auto-frr

# Disable the TE Auto FRR function.
<HUAWEI> system-view
[HUAWEI] mpls
[HUAWEI-mpls] undo mpls te auto-frr



Parent topic: MPLS TE Configuration Commands

Related Topics

mpls te auto-frr (interface view)
  • x
  • convention:

lizhi94     Created 3 days ago Helpful(0) Helpful(0)

mpls rsvp-te authentication handshake
<http://support.huawei.com/hedex/ ... ocid=EDOC1000081667>
  • x
  • convention:

Responses

Reply
You need to log in to reply to the post Login | Register

Notice:To ensure the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but not limited to politically sensitive content, content concerning pornography, gambling, drug abuse and trafficking, content that may disclose or infringe upon others' intellectual properties, including commercial secrets, trade marks, copyrights, and patents, and personal privacy. Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see“ Privacy Policy.”
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Fast reply Scroll to top