Routing

last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  shamlink hidden in vpn.inet.0

    Posted 11-19-2014 21:06

     Hi,

    Please find the following show information.

    Could any expert help me understand, why the shamlink hidden in VPN.inet.0?

     

    Thanks.

    Ernest Lin

     

    RE0> show ospf route instance VPN 
    Topology default Route Table:

    Prefix                        Path     Route         NH     Metric    NextHop         Nexthop 
                                      Type     Type          Type                  Interface         Address/LSP
    172.20.232.0/25    Ext2     Network     IP          0         shamlink.0

    ..........

     

    RE0> show route table VPN.inet.0 protocol ospf 172.20.232.0/25 hidden 

    VPN.inet.0: 721 destinations, 1460 routes (721 active, 0 holddown, 16 hidden)
    + = Active Route, - = Last Active, * = Both

    172.20.232.0/25 [OSPF] 9w2d 09:44:14, metric 0, tag 0
    > via shamlink.0

    ..........

     

    RE0> show route table VPN.inet.0 protocol bgp 172.20.232.0/25 

    VPN.inet.0: 721 destinations, 1460 routes (721 active, 0 holddown, 16 hidden)
    + = Active Route, - = Last Active, * = Both

    172.20.232.0/25 [BGP/170] 15w6d 08:36:14, localpref 801, from 11.77.1.226
    AS path: I
     > to 10.79.129.109 via xe-9/3/0.0, label-switched-path FPE.JRT004-to-FPE.JRT003_02
     to 10.79.128.109 via xe-11/3/0.100, label-switched-path FPE.JRT004-to-FPE.JRT003_01

     



  • 2.  RE: shamlink hidden in vpn.inet.0
    Best Answer

    Posted 11-25-2014 03:36

    Hello,

    This is working as designed ,see RFC 4577 section 4.7.2.4 https://www.rfc-editor.org/rfc/rfc4577.txt 

     

    4.2.7.4.  Routing and Forwarding on Sham Links
    
       If a PE determines that the next hop interface for a particular route
       is a sham link, then the PE SHOULD NOT redistribute that route into
       BGP as a VPN-IPv4 route.
    
       Any other route advertised in an LSA that is transmitted over a sham
       link MUST also be redistributed (by the PE flooding the LSA over the
       sham link) into BGP.  This means that if the preferred (OSPF) route
       for a given address prefix has the sham link as its next hop
       interface, then there will also be a "corresponding BGP route", for
       that same address prefix, installed in the VRF.  Per Section 4.1.2,
       the OSPF route is preferred.  However, when forwarding a packet, if
       the preferred route for that packet has the sham link as its next hop
       interface, then the packet MUST be forwarded according to the
       corresponding BGP route.  That is, it will be forwarded as if the
       corresponding BGP route had been the preferred route.  The
       "corresponding BGP route" is always a VPN-IPv4 route; the procedure
       for forwarding a packet over a VPN-IPv4 route is described in [VPN].
    
       This same rule applies to any packet whose IP destination address is
       the remote endpoint address of a sham link.  Such packets MUST be
       forwarded according to the corresponding BGP route.
    

     

    Your packets destined to 172.20.232.0/25 have to be forwarded along the BGP route, there is no other choice.

    Sham link is only serving to avoid conversion of LSA1/2 to LSA3, it does not serve any purpose for LSA5 from which Your 172.20.232.0/25 OSPF route originates (OSPF Ext2).

    HTH

    Thanks

    Alex