[c-nsp] BGP - unsupported parameter - peer reset

[Vikas Sharma]

Hi,

To my astonishment, everything started working fine after enabling mpls on
juniper ERX globally. Can any one tell me the reason?

My understanding which proved to be wrong in case of ERX is -

The issue we have is bgp session not establishing (not, bgp is not
advertising the vpnv4 routes). ERX can advertise ipv4:vpn unicast (vpnv4
routes) only after mpbgp is in establish state. The statement from juniper
holds true not only for juniper but for any other vendor as until mpls is
not configured it will not advertise any vpnv4 routes.

The process for bgp is -

First bgp session is established then only bgp advertise the routes /
prefixes

The process for mpbgp is -

First the mpbgp session is establish then only one can see any vpnv4 routes

My point is to establish mpbgp session we do not need to enable mpls. After
mpbgp session only vpnv4 prefixes can be seen in mpbgp table.

Thus the answer from Juniper is not to the point. Still we do not know the
reason for mpbgp session not establishing and in the logs it is clearly
stating the reason is capability mismatch.

Further to this mbbgp and mpls are entirely two different independent
protocols and configured separately, one under bgp process and another under
mpls and mpls is just a transport protocol.

Summary of the above is - advertisement of vpnv4 routes, mpbgp session
establishment and enabling mpls are different process. Thus juniper has to
rework on the issue and let us know the actual reason.

Regards,
Vikas Sharma

On 7/14/08, Vikas Sharma <vikassharmas at gmail.com> wrote:
>
> Hi,
>
> I have mpls network where I am connecting ERX (juniper box) as PE to cisco
> 12 k (vpnv4 route reflector). At all locations itsworking fine except one
> and showing me on ERX unsupported capabilities.
>
> from ERX -
>
> We received an unsupported-capability notification from this peer.
>     This indicates that the peer does not ignore unrecognized capabilities.
>     We received the notification before we received an open from this peer.
>     As a result we cannot guess which capabilities are supported by the
> peer.
>     We won't advertise capabilities with known interoperability problems.
>   Capability advertisements:
>     Capabilities option: send
>     Dynamic capability negotiation: send
>     Deprecated dynamic capability negotiation: send
>     Multi-protocol extensions: send
>     Route refresh: send
>     Route refresh (Cisco proprietary): send
>     Four octet AS numbers: send
>     Graceful restart:
>   Graceful restart negotiation:
>     Restart time is 120 seconds
>     Stale paths time is 360 seconds
>     The last time that the session was in state established:
>       We did not send the graceful-restart capability
>       We did not receive the graceful-restart capability
>   Total of 20782 messages sent, 20639 messages received
>   0 update messages sent, 0 update messages received
>
> As per rfc3392, if bgp speaking router does not understand optional
> community, it should ignore it and should not try to re-establish the
> session. I am attaching the status of sh ip bgp vpnv1 a s for the ref.
>
> on ERX -
>
> sh ip bgp vpnv4 all s
> Local router ID 212.74.69.117, local AS 8220
>   Administrative state is Start
>   BGP Operational state is Up
>   Shutdown in overload state is disabled
>   Default local preference is 100
>   IGP synchronization is disabled
>   Default originate is disabled
>   Auto summary is disabled
>   Always compare MED is disabled
>   Compare MED within confederation is disabled
>   Advertise inactive routes is disabled
>   Advertise best external route to internal peers is disabled
>   Enforce first AS is enabled
>   Missing MED as worst is disabled
>   Route flap dampening is disabled
>   Log neighbor changes is enabled
>   Fast External Fallover is disabled
>   No maximum received AS-path length
>   BGP administrative distances are 20 (ext), 200 (int), and 200 (local)
>   Client-to-client reflection is enabled
>   Cluster ID is not configured (local router ID used)
>   Route-target filter is enabled
>   Default IPv4-unicast is enabled
>   Check next-hops of vpn routes is disabled
>   Redistribution of iBGP routes is disabled
>   Graceful restart is globally disabled
>   Global graceful-restart restart time is 120 seconds
>   Global graceful-restart stale paths time is 360 seconds
>   Graceful-restart path selection defer time is 360 seconds
>   Graceful-restart is not ready to switch to the standby SRP
>   The last restart was not graceful
>   Address family ipv4:vpn-unicast in core VRF operationally down due to
> IPv6
>      not present
>   Local-RIB version 2. FIB version 2.
>
>                                                 Messages  Messages
> Prefixes
> Neighbor           AS State       Up/down time      Sent  Received
> Received
> 212.74.69.112    8220 Idle         2d 06:25:40     18301     18166
> 0
>
> 212.74.69.113    8220 Idle         4d 11:06:33     20934     20788
> 0
>
> these are two route reflectors connected to this PE. We have one more PE
> (again ERX box), which does not have any issue.
>
> For your ref. I am also attaching working and non-working ERX, sh ip bgp v
> a nei "" output
>
> working ERX -
>
>  Capability advertisements:
>     Capabilities option: sent, received
>     Dynamic capability negotiation: sent
>     Deprecated dynamic capability negotiation: sent
>     Multi-protocol extensions: sent, received
>     Route refresh: sent, received
>     Route refresh (Cisco proprietary): sent, received
>     Four octet AS numbers: sent
>     Graceful restart:
>   *Multi-protocol extensions negotiation:
>     ip-v4 vpn-unicast: sent, received, used
> *  Dynamic capability negotiation:
>     Multi-protocol extensions: sent
>     Route refresh: sent
>     Graceful restart: sent
>     Route refresh (Cisco proprietary): sent
>   Graceful restart negotiation:
>     Restart time is 120 seconds
>     Stale paths time is 360 seconds
>     We did not send the graceful-restart capability
>
> Non- working ERX -
>
>  Capability advertisements:
>     Capabilities option: send
>     Dynamic capability negotiation: send
>     Deprecated dynamic capability negotiation: send
>     Multi-protocol extensions: send
>     Route refresh: send
>     Route refresh (Cisco proprietary): send
>     Four octet AS numbers: send
>     Graceful restart:
>   Graceful restart negotiation:
>     Restart time is 120 seconds
>     Stale paths time is 360 seconds
>
> Note- I can see the diference as in working I can see multiprotocol
> extensio negotiations while I can not see the same in non-working.
>
> Since the message states issue with 12k !!!, which I am not sure abt,
> sending this to cisaco-mail ;)
>
> Regards,
>
> Vikas Sharma
>
>
>
>
>
>
>