Re: [c-nsp] BGP routes disappearing
On 10/06/2024 11:20, Saku Ytti wrote: I don't think there is enough information here to understand the problem. Since you asked: Router B is exaBGP sending announcements to router A (128.139.220.90). 192.0.2.1 is a GigE interface on router A. I want to null0 all traffic which is easy to do but I also want a record of every attempt someone tried to reach one of these null0 routes. Think of something like: https://www.team-cymru.com/ty/cisco-router-traditional-bogons So I want an ACL like: ipv4 access-list log-traffic 10 permit ipv4 any any log But an ACL can't be placed on a null0 interface nor on a loopback interface so I created a fake VLAN and route the traffic there (to 192.0.2.1), and there I can install an ACL and log the traffic: RP/0/RSP0/CPU0:2024 Jun 10 10:27:44 : ipv4_acl_mgr[343]: %ACL-IPV4_ACL-6-IPACCESSLOGP : access-list log-traffic (10) deny udp 128.139.6.11(40652) -> 192.0.2.1(53), 1 packet In any event, I solved it. Thanks, Hank So you have RouterA - RouterB RouterA is 192.0.2.1/24 RouterB is 128.139.197.146 RouterB advertises bunch of /32s to routerA, with next-hop 192.0.2.1? This seems nonsensical to me, where is routerA supposed to send the packets? So I must be misunderstanding what you're doing. But you probably can look at the disappeared routers in adjRIB for some clue, or turn on debugging on BGP, to see why they are invalidated. I'm expecting invalid next-hop, next-hop loop or BGP session itself has the most-specific route to the BGP session over the BGP session. On Mon, 10 Jun 2024 at 11:09, Hank Nussbacher via cisco-nsp wrote: I have a simple iBGP peer defined as follows: neighbor 128.139.197.146 remote-as 378 update-source Loopback0 address-family ipv4 unicast I have a GigE interface defined as: interface GigabitEthernet0/0/0/43.1 ipv4 address 192.0.2.1 255.255.255.0 encapsulation dot1q 1 This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem is all routes disappear. NeighborSpkAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 128.139.197.146 0 378 10437 627880 1006011900 00:15:41 0 If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the routing table. If I then change the IP address on interface GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well after having made it into the routing table. I am obviously missing something very simple. Clue-bat welcome. Thanks, Hank ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP routes disappearing
Hi Hank If I understand correctly you are trying to send bgp routes to a router that have a next hop local to the router? I think this would contrast with the route selection process and not be accepted.. as the route would not be installable. i.e. The router would route it to itself on the Ge interface and then ? route it to itself in a loop? Maybe I am misunderstanding ... Brian Brian Turnbow +39 02 6706800 [image: CDLAN SPA] [image: CDLAN SPA] <https://www.cdlan.it//> | [image: CDLAN SPA - LinkedIn] <https://it.linkedin.com/company/cdlan> Il giorno lun 10 giu 2024 alle ore 10:09 Hank Nussbacher via cisco-nsp < cisco-nsp@puck.nether.net> ha scritto: > I have a simple iBGP peer defined as follows: > > neighbor 128.139.197.146 >remote-as 378 >update-source Loopback0 >address-family ipv4 unicast > > > I have a GigE interface defined as: > > interface GigabitEthernet0/0/0/43.1 > ipv4 address 192.0.2.1 255.255.255.0 > encapsulation dot1q 1 > > This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem > is all routes disappear. > > NeighborSpkAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > St/PfxRcd > 128.139.197.146 0 378 10437 627880 1006011900 > 00:15:41 0 > > > If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the > routing table. If I then change the IP address on interface > GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well > after having made it into the routing table. > > > I am obviously missing something very simple. Clue-bat welcome. > > > Thanks, > > Hank > > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP routes disappearing
On 10/06/2024 11:05, Hank Nussbacher wrote: Ignore. There was an ACL on GigabitEthernet0/0/0/43.1 that blocked the traffic. Nothing like solving your own issues. -Hank I have a simple iBGP peer defined as follows: neighbor 128.139.197.146 remote-as 378 update-source Loopback0 address-family ipv4 unicast I have a GigE interface defined as: interface GigabitEthernet0/0/0/43.1 ipv4 address 192.0.2.1 255.255.255.0 encapsulation dot1q 1 This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem is all routes disappear. Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 128.139.197.146 0 378 10437 627880 10060119 0 0 00:15:41 0 If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the routing table. If I then change the IP address on interface GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well after having made it into the routing table. I am obviously missing something very simple. Clue-bat welcome. Thanks, Hank ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP routes disappearing
Hi, On Mon, Jun 10, 2024 at 11:05:18AM +0300, Hank Nussbacher via cisco-nsp wrote: > If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the > routing table. If I then change the IP address on interface > GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well > after having made it into the routing table. Why would you want routes pointing to *your own* IP? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP routes disappearing
I don't think there is enough information here to understand the problem. So you have RouterA - RouterB RouterA is 192.0.2.1/24 RouterB is 128.139.197.146 RouterB advertises bunch of /32s to routerA, with next-hop 192.0.2.1? This seems nonsensical to me, where is routerA supposed to send the packets? So I must be misunderstanding what you're doing. But you probably can look at the disappeared routers in adjRIB for some clue, or turn on debugging on BGP, to see why they are invalidated. I'm expecting invalid next-hop, next-hop loop or BGP session itself has the most-specific route to the BGP session over the BGP session. On Mon, 10 Jun 2024 at 11:09, Hank Nussbacher via cisco-nsp wrote: > > I have a simple iBGP peer defined as follows: > > neighbor 128.139.197.146 >remote-as 378 >update-source Loopback0 >address-family ipv4 unicast > > > I have a GigE interface defined as: > > interface GigabitEthernet0/0/0/43.1 > ipv4 address 192.0.2.1 255.255.255.0 > encapsulation dot1q 1 > > This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem > is all routes disappear. > > NeighborSpkAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down > St/PfxRcd > 128.139.197.146 0 378 10437 627880 1006011900 > 00:15:41 0 > > > If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the > routing table. If I then change the IP address on interface > GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well > after having made it into the routing table. > > > I am obviously missing something very simple. Clue-bat welcome. > > > Thanks, > > Hank > > > > _______ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BGP routes disappearing
I have a simple iBGP peer defined as follows: neighbor 128.139.197.146 remote-as 378 update-source Loopback0 address-family ipv4 unicast I have a GigE interface defined as: interface GigabitEthernet0/0/0/43.1 ipv4 address 192.0.2.1 255.255.255.0 encapsulation dot1q 1 This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem is all routes disappear. Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 128.139.197.146 0 378 10437 627880 10060119 0 0 00:15:41 0 If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the routing table. If I then change the IP address on interface GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well after having made it into the routing table. I am obviously missing something very simple. Clue-bat welcome. Thanks, Hank ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] MPLS TE FRR - IOS XR
Greetings I have the below topology for which am trying to deploy MPLS TE FRR (Link protection) on IOS XR. CE1 – PE2 – P3 – PE6 – CE7 || | P4P5 Nothing special about the deployment , static routing running between PE and CE for VRF transport. The main concern is PE6 (Which is IOS XR based). The active tunnel is tunnel-te0: interface tunnel-te0 ipv4 unnumbered Loopback0 autoroute announce destination 10.1.100.2 fast-reroute path-option 1 explicit name PATH The backup tunnel is tunnel-te1: interface tunnel-te1 ipv4 unnumbered Loopback0 autoroute announce ! destination 10.1.100.2 path-option 1 explicit name REPAIR2 protected-by 2 path-option 2 dynamic The REPAIR2 explicit path is to exclude the link between PE6 and P3 The active tunnel is working fine (Trace between both CEs is functioning well). RP/0/0/CPU0:PE6#show mpls traffic-eng tunnels brief Sun Jun 9 07:59:43.561 UTC TUNNEL NAME DESTINATION STATUS STATE tunnel-te0 10.1.100.2 up up tunnel-te1 10.1.100.2 up up PE2_t0 10.1.100.6 up up RP/0/0/CPU0:PE6#show mpls traffic-eng fast-reroute database Sun Jun 9 08:00:00.430 UTC Tunnel head FRR information: Tunnel Out Intf : Label FRR Intf : Label Status -- -- --- tt0 Gi0/0/0/2:30 tt1:PopReady Is there anything missing? Note : MPLS LDP is enabled globally to ensure LFIB population. Appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] vs route leaking
And your problem is, you get multiple default routes? route-map FOO permit 100 match extcommunity 100 match ip address prefix-list DEFAULT route-map FOO deny 200 match ip address prefix-list DEFAULT route-map FOO permit 300 in your VRF_SHARED_SERVICE, so that you only import DEFAULT from RT defined in extcommunity 100. On Sun, 9 Jun 2024 at 07:57, Arne Larsen wrote: > > Sort off, I need the default route from the vrf with the import target > 64515:112, that's our leak for the shared vrf to the internet > > > /Arne > > On 08/06/2024 17.31, Saku Ytti wrote: > > On Sat, 8 Jun 2024 at 18:26, Arne Larsen via cisco-nsp > > wrote: > > > >> Yes, it'd with route-target I'm trying to get it to work, and what I'm > >> trying to get rid off is the default route from the IOT vrf to be > >> imported into the SHARED vrf. > > Ok so the problem is not sharing routes between VRF, problem is > > sharing selectively routes between VRF? > > > > In the example the problem is that VRF_SHARED_SERVICE gets default > > route from VN_IOT. > > > > You could accomplish this two ways > > > > a) VRF_SHARED_SERVICE has import policy, which drops the default route > > for 64515:136 > > b) VN_IOT has export policy, which doesn't set 64515:95 on default route > > > > > > I think a) is more robust, you'd probably just deny importing any > > default route at all, if you know you're going to have the 64515:95 > > default route you want. So no matter what happens in the other VRFs, > > you'd never end up importing their default. > > > > Like > > > > vrf definition VRF_SHARED_SERVICE > >address-family ipv4 > >import map FOO > > > > route-map FOO deny 100 > > match ip address prefix-list DEFAULT > > route-map FOO permit 200 > > > > > >> Here are the vrf definition.: > >> > >> > >> vrf definition VRF_SHARED_SERVICE > >>rd 192.168.101.110:95 > >>! > >>address-family ipv4 > >> route-target export 64515:95 > >> route-target import 64515:95 > >> route-target import 64515:10 > >> route-target import 64515:136 > >> route-target import 64515:112 > >> route-target import 64515:101 > >>exit-address-family > >> > >> > >> > >> vrf definition VN_IOT > >>rd 192.168.101.110:136 > >>! > >>address-family ipv4 > >> route-target export 64515:136 > >> route-target import 64515:136 > >> route-target import 64515:95 > >>exit-address-family > >> > >> > >> /Arne > >> > >> > >> > >> On 08/06/2024 12.25, James Bensley wrote: > >>> Hi Arne, > >>> > >>> The normal way to do this is with route targets but you didn't mention > >>> route targets in your email. Are you importing the export RTs from VRF1 > >>> and VRF2 in to VRF3? > >>> > >>> You also mentioned route-maps. Are you already importing the export RTs > >>> and trying to filter which routes are imported to only be the default > >>> route? > >>> > >>> You didn't post any config, it always helps people to help you if you can > >>> show what you have tried already. > >>> > >>> Cheers, > >>> James. > >>> > >>> > >>> > >>> Ursprüngliche Nachricht > >>> Am 08.06.24 08:04 um Arne Larsen via cisco-nsp schrieb > >>> : > >>> > >>>>Hi all > >>>> > >>>>I’m struggling with an 9606 Cisco router and route leaking between > >>>> vrf’s. > >>>> > >>>>I have 2 vrf’s with a default route that needs to imported into a 3. > >>>> > >>>> The default route from the one vrf’s is direct connected on the box, > >>>>andthe other is via mBGP. > >>>> > >>>>I’ve tried several forms for import maps base on community, prefix, > >>>> acl > >>>>and so on, but I always ends up with pulling my legs. > >>>> > >>>>The 3 vrf is for shared services, so I import more the the 2 vrf’s > >>>> with > >>>>the default route. > >>>> > >>>>Can someone give me a hint how to get this to work. > >>>> > >>>>The 2 vrf’s with the def route has community x:112 and x:114. > >>>>I need to import all other routes from all other vrf’s including the 2 > >>>>with the def route. > >>>> > >>>>Hope someone can help me out here > >>>> > >>>>Regards Arne > >>>>___ > >>>>cisco-nsp mailing list cisco-nsp@puck.nether.net > >>>>https://puck.nether.net/mailman/listinfo/cisco-nsp > >>>>archive at http://puck.nether.net/pipermail/cisco-nsp/ > >>>> > >> ___ > >> cisco-nsp mailing list cisco-nsp@puck.nether.net > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] vs route leaking
Sort off, I need the default route from the vrf with the import target 64515:112, that's our leak for the shared vrf to the internet /Arne On 08/06/2024 17.31, Saku Ytti wrote: On Sat, 8 Jun 2024 at 18:26, Arne Larsen via cisco-nsp wrote: Yes, it'd with route-target I'm trying to get it to work, and what I'm trying to get rid off is the default route from the IOT vrf to be imported into the SHARED vrf. Ok so the problem is not sharing routes between VRF, problem is sharing selectively routes between VRF? In the example the problem is that VRF_SHARED_SERVICE gets default route from VN_IOT. You could accomplish this two ways a) VRF_SHARED_SERVICE has import policy, which drops the default route for 64515:136 b) VN_IOT has export policy, which doesn't set 64515:95 on default route I think a) is more robust, you'd probably just deny importing any default route at all, if you know you're going to have the 64515:95 default route you want. So no matter what happens in the other VRFs, you'd never end up importing their default. Like vrf definition VRF_SHARED_SERVICE address-family ipv4 import map FOO route-map FOO deny 100 match ip address prefix-list DEFAULT route-map FOO permit 200 Here are the vrf definition.: vrf definition VRF_SHARED_SERVICE rd 192.168.101.110:95 ! address-family ipv4 route-target export 64515:95 route-target import 64515:95 route-target import 64515:10 route-target import 64515:136 route-target import 64515:112 route-target import 64515:101 exit-address-family vrf definition VN_IOT rd 192.168.101.110:136 ! address-family ipv4 route-target export 64515:136 route-target import 64515:136 route-target import 64515:95 exit-address-family /Arne On 08/06/2024 12.25, James Bensley wrote: Hi Arne, The normal way to do this is with route targets but you didn't mention route targets in your email. Are you importing the export RTs from VRF1 and VRF2 in to VRF3? You also mentioned route-maps. Are you already importing the export RTs and trying to filter which routes are imported to only be the default route? You didn't post any config, it always helps people to help you if you can show what you have tried already. Cheers, James. Ursprüngliche Nachricht Am 08.06.24 08:04 um Arne Larsen via cisco-nsp schrieb : Hi all I’m struggling with an 9606 Cisco router and route leaking between vrf’s. I have 2 vrf’s with a default route that needs to imported into a 3. The default route from the one vrf’s is direct connected on the box, andthe other is via mBGP. I’ve tried several forms for import maps base on community, prefix, acl and so on, but I always ends up with pulling my legs. The 3 vrf is for shared services, so I import more the the 2 vrf’s with the default route. Can someone give me a hint how to get this to work. The 2 vrf’s with the def route has community x:112 and x:114. I need to import all other routes from all other vrf’s including the 2 with the def route. Hope someone can help me out here Regards Arne ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] vs route leaking
On Sat, 8 Jun 2024 at 18:26, Arne Larsen via cisco-nsp wrote: > Yes, it'd with route-target I'm trying to get it to work, and what I'm > trying to get rid off is the default route from the IOT vrf to be > imported into the SHARED vrf. Ok so the problem is not sharing routes between VRF, problem is sharing selectively routes between VRF? In the example the problem is that VRF_SHARED_SERVICE gets default route from VN_IOT. You could accomplish this two ways a) VRF_SHARED_SERVICE has import policy, which drops the default route for 64515:136 b) VN_IOT has export policy, which doesn't set 64515:95 on default route I think a) is more robust, you'd probably just deny importing any default route at all, if you know you're going to have the 64515:95 default route you want. So no matter what happens in the other VRFs, you'd never end up importing their default. Like vrf definition VRF_SHARED_SERVICE address-family ipv4 import map FOO route-map FOO deny 100 match ip address prefix-list DEFAULT route-map FOO permit 200 > > Here are the vrf definition.: > > > vrf definition VRF_SHARED_SERVICE > rd 192.168.101.110:95 > ! > address-family ipv4 >route-target export 64515:95 >route-target import 64515:95 >route-target import 64515:10 >route-target import 64515:136 >route-target import 64515:112 >route-target import 64515:101 > exit-address-family > > > > vrf definition VN_IOT > rd 192.168.101.110:136 > ! > address-family ipv4 >route-target export 64515:136 >route-target import 64515:136 >route-target import 64515:95 > exit-address-family > > > /Arne > > > > On 08/06/2024 12.25, James Bensley wrote: > > Hi Arne, > > > > The normal way to do this is with route targets but you didn't mention > > route targets in your email. Are you importing the export RTs from VRF1 and > > VRF2 in to VRF3? > > > > You also mentioned route-maps. Are you already importing the export RTs and > > trying to filter which routes are imported to only be the default route? > > > > You didn't post any config, it always helps people to help you if you can > > show what you have tried already. > > > > Cheers, > > James. > > > > > > > > Ursprüngliche Nachricht > > Am 08.06.24 08:04 um Arne Larsen via cisco-nsp schrieb > > : > > > >> Hi all > >> > >> I’m struggling with an 9606 Cisco router and route leaking between vrf’s. > >> > >> I have 2 vrf’s with a default route that needs to imported into a 3. > >> > >> The default route from the one vrf’s is direct connected on the box, > >> andthe other is via mBGP. > >> > >> I’ve tried several forms for import maps base on community, prefix, acl > >> and so on, but I always ends up with pulling my legs. > >> > >> The 3 vrf is for shared services, so I import more the the 2 vrf’s with > >> the default route. > >> > >> Can someone give me a hint how to get this to work. > >> > >> The 2 vrf’s with the def route has community x:112 and x:114. > >> I need to import all other routes from all other vrf’s including the 2 > >> with the def route. > >> > >> Hope someone can help me out here > >> > >> Regards Arne > >> ___ > >> cisco-nsp mailing list cisco-nsp@puck.nether.net > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > >> > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] vs route leaking
Sorry James and all others I hope this will clarify a bit more. Yes, it'd with route-target I'm trying to get it to work, and what I'm trying to get rid off is the default route from the IOT vrf to be imported into the SHARED vrf. Here are the vrf definition.: vrf definition VRF_SHARED_SERVICE rd 192.168.101.110:95 ! address-family ipv4 route-target export 64515:95 route-target import 64515:95 route-target import 64515:10 route-target import 64515:136 route-target import 64515:112 route-target import 64515:101 exit-address-family vrf definition VN_IOT rd 192.168.101.110:136 ! address-family ipv4 route-target export 64515:136 route-target import 64515:136 route-target import 64515:95 exit-address-family /Arne On 08/06/2024 12.25, James Bensley wrote: Hi Arne, The normal way to do this is with route targets but you didn't mention route targets in your email. Are you importing the export RTs from VRF1 and VRF2 in to VRF3? You also mentioned route-maps. Are you already importing the export RTs and trying to filter which routes are imported to only be the default route? You didn't post any config, it always helps people to help you if you can show what you have tried already. Cheers, James. Ursprüngliche Nachricht Am 08.06.24 08:04 um Arne Larsen via cisco-nsp schrieb : Hi all I’m struggling with an 9606 Cisco router and route leaking between vrf’s. I have 2 vrf’s with a default route that needs to imported into a 3. The default route from the one vrf’s is direct connected on the box, andthe other is via mBGP. I’ve tried several forms for import maps base on community, prefix, acl and so on, but I always ends up with pulling my legs. The 3 vrf is for shared services, so I import more the the 2 vrf’s with the default route. Can someone give me a hint how to get this to work. The 2 vrf’s with the def route has community x:112 and x:114. I need to import all other routes from all other vrf’s including the 2 with the def route. Hope someone can help me out here Regards Arne ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] vs route leaking
Hi all I’m struggling with an 9606 Cisco router and route leaking between vrf’s. I have 2 vrf’s with a default route that needs to imported into a 3. The default route from the one vrf’s is direct connected on the box, andthe other is via mBGP. I’ve tried several forms for import maps base on community, prefix, acl and so on, but I always ends up with pulling my legs. The 3 vrf is for shared services, so I import more the the 2 vrf’s with the default route. Can someone give me a hint how to get this to work. The 2 vrf’s with the def route has community x:112 and x:114. I need to import all other routes from all other vrf’s including the 2 with the def route. Hope someone can help me out here Regards Arne ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASA5516-x DATAPATH-0-1648 and DATAPATH-0-1648 CPU hog
So, this was tracked down to be an issue with the ASA doing debug logging. As soon as we changed the logging back down to alert level logging, the issue resolved. Only caught the issue when watching the Process CPU-Usage and saw that the logger process pop up at 52%, then 64% and then 84% CPU usage before falling off in a 10 second period. vpn-gw# sh proc cpu-usage non-zero Hardware: ASA5516 Cisco Adaptive Security Appliance Software Version 9.16(4)57 ASLR enabled, text region 56474105f000-564744cef285 PC Thread 5Sec 1Min 5Min Process 0x564743c1c050 0x7f2cef4bbe80 1.0% 1.5% 1.0% Unicorn Proxy Thread 0x564743a1b57b 0x7f2cef4bb000 0.0% 0.2% 0.3% 0x5647439821d6 0x7f2cef4bbae0 0.0% 0.2% 0.1% snmp_master_callback_thread 0x564743982226 0x7f2cef4bb740 0.0% 0.4% 0.4% snmp_client_callback_thread 0x5647437cf58c 0x7f2cef4be2c0 0.0% 0.1% 0.1% radius_snd 0x5647421c5dd4 0x7f2cef4dc4e052.1%11.5%11.1% Logger 0x5647427c3cb6 0x7f2cef4c5e00 0.0% 0.1% 0.1% ARP Thread 0x564743c1c050 0x7f2cef4ebf00 0.0% 0.1% 0.1% aaa_shim_thread 0x564741cdf31c 0x7f2cef4ec640 0.0% 0.1% 0.1% aaa - - 0.8% 2.1% 2.2% DATAPATH-0-1665 - - 2.6% 2.3% 2.4% DATAPATH-1-1666 vpn-gw# sh proc cpu-usage non-zero Hardware: ASA5516 Cisco Adaptive Security Appliance Software Version 9.16(4)57 ASLR enabled, text region 56474105f000-564744cef285 PC Thread 5Sec 1Min 5Min Process 0x564743bf433f 0x7f2cef4bbe80 0.0% 1.2% 1.0% Unicorn Proxy Thread 0x564743a1b57b 0x7f2cef4bb000 0.0% 0.1% 0.2% 0x5647439821d6 0x7f2cef4bbae0 0.0% 0.1% 0.1% snmp_master_callback_thread 0x564743982226 0x7f2cef4bb740 0.0% 0.2% 0.4% snmp_client_callback_thread 0x5647421c5dd4 0x7f2cef4dc4e064.1%12.7%11.3% Logger 0x5647427c3cb6 0x7f2cef4c5e00 0.0% 0.1% 0.1% ARP Thread - - 1.3% 2.1% 2.2% DATAPATH-0-1665 - - 4.7% 2.5% 2.4% DATAPATH-1-1666 vpn-gw# sh proc cpu-usage non-zero Hardware: ASA5516 Cisco Adaptive Security Appliance Software Version 9.16(4)57 ASLR enabled, text region 56474105f000-564744cef285 PC Thread 5Sec 1Min 5Min Process 0x564743c1c050 0x7f2cef4bbe80 0.0% 0.9% 0.9% Unicorn Proxy Thread 0x564743a1b57b 0x7f2cef4bb000 0.0% 0.1% 0.2% 0x5647439821d6 0x7f2cef4bbae0 0.0% 0.1% 0.0% snmp_master_callback_thread 0x564743982226 0x7f2cef4bb740 0.0% 0.1% 0.3% snmp_client_callback_thread 0x5647421c5dd4 0x7f2cef4dc4e084.0%15.1%11.8% Logger - - 3.0% 2.3% 2.3% DATAPATH-0-1665 - - 0.4% 2.3% 2.4% DATAPATH-1-1666 vpn-gw# sh proc cpu-usage non-zero Hardware: ASA5516 Cisco Adaptive Security Appliance Software Version 9.16(4)57 ASLR enabled, text region 56474105f000-564744cef285 PC Thread 5Sec 1Min 5Min Process 0x564743c1c050 0x7f2cef4bbe80 1.3% 1.0% 0.9% Unicorn Proxy Thread 0x564743a1b57b 0x7f2cef4bb000 0.0% 0.1% 0.2% 0x564743982226 0x7f2cef4bb740 0.0% 0.1% 0.3% snmp_client_callback_thread 0x5647421c5dd4 0x7f2cef4dc4e0 0.0%12.8%11.4% Logger 0x56474221df82 0x7f2cef4bc5c0 0.1% 0.1% 0.1% emweb/https 0x5647427c3cb6 0x7f2cef4c5e00 0.1% 0.0% 0.0% ARP Thread - - 2.2% 2.3% 2.3% DATAPATH-0-1665 - - 2.4% 2.3% 2.4% DATAPATH-1-1666 vpn-gw# sh proc cpu-usage non-zero Best, -Lee On Wed, Jun 5, 2024 at 2:22 PM Lee Starnes wrote: > Thank you for the link and info. Unfortunately can['t open a TAC case as > this model (5516-X) is not under support. We have a 5508-X under contract > which is how we are able to get the firmware. > > I will check out the links. Thank you for your help. > > Best, > > -Lee > > On Wed, Jun 5, 2024 at 6:15 AM harbor235 wrote: > >> Here is an overall performance troubleshooting oc: >> >> >> https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113185-asaperformance.html >> >> Mike >> >> On Wed, Jun 5, 2024 at 9:12 AM harbor235 wrote: >> >>> If you cannot open a TAc case I would look through your syslog messages >>> looking for errors/critcals/warnings. Also look at all interfaces to ensure >>> there are no input or output errors as well. After that I would verify >>> traffic is hitting your box and is not an
Re: [c-nsp] Cisco ASA5516-x DATAPATH-0-1648 and DATAPATH-0-1648 CPU hog
Can you post "show proc cpu | exc 0.0" show proc cpu-usage sorted non-zero Mike On Tue, Jun 4, 2024 at 7:02 PM harbor235 wrote: > What features do you have enabled? NGFW and/or NGIPS? These features can > limit the box to 450Mbps. > > Mike > > On Tue, Jun 4, 2024 at 6:53 PM Lee Starnes via cisco-nsp < > cisco-nsp@puck.nether.net> wrote: > >> Hello Everyone, >> >> I have an odd issue trying to track down. We are seeing issue whereby >> traffic just "pauses" through the ASA for about 2-4 seconds before >> resuming. >> >> We started seeing this when the device was low on memory (about 600M >> available). we rebooted it and did an firmware update the current version. >> >> Still seeing this behavior. >> >> After another reboot, still seeing this. >> >> Process: DATAPATH-0-1665, PROC_PC_TOTAL: 407, MAXHOG: 10, LASTHOG: 5 >> MAXHOG At:15:31:54 PDT Jun 4 2024 >> LASTHOG At: 15:37:48 PDT Jun 4 2024 >> PC: 0x (suspend) >> >> Process: DATAPATH-0-1665, NUMHOG: 385, MAXHOG: 10, LASTHOG: 5 >> MAXHOG At:15:31:54 PDT Jun 4 2024 >> LASTHOG At: 15:37:48 PDT Jun 4 2024 >> PC: 0x (suspend) >> Call stack: 0x564741c98c49 0x564742188996 0x5647436c2d28 >> 0x5647436d2abc 0x5647436e2ae0 0x7f2d2067bff5 >> 0x7f2d1f88416f >> >> >> Process: DATAPATH-1-1666, PROC_PC_TOTAL: 402, MAXHOG: 12, LASTHOG: 5 >> MAXHOG At:15:31:48 PDT Jun 4 2024 >> LASTHOG At: 15:37:41 PDT Jun 4 2024 >> PC: 0x (suspend) >> >> Process: DATAPATH-1-1666, NUMHOG: 376, MAXHOG: 12, LASTHOG: 5 >> MAXHOG At:15:31:48 PDT Jun 4 2024 >> LASTHOG At: 15:37:41 PDT Jun 4 2024 >> PC: 0x (suspend) >> Call stack: 0x564741c98c49 0x564742188996 0x5647436c2d28 >> 0x5647436d2abc 0x5647436e2ae0 0x7f2d2067bff5 >> 0x7f2d1f88416f >> >> >> >> I did disable logging flash-bufferwrap to stop it from writing to flash. >> The logging process stopped using 29% CPU, but still the issue persists. >> >> Anyone got any Ideas on what the cause is and how to resolve it? >> >> Best, >> >> -Lee >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco ASA5516-x DATAPATH-0-1648 and DATAPATH-0-1648 CPU hog
What features do you have enabled? NGFW and/or NGIPS? These features can limit the box to 450Mbps. Mike On Tue, Jun 4, 2024 at 6:53 PM Lee Starnes via cisco-nsp < cisco-nsp@puck.nether.net> wrote: > Hello Everyone, > > I have an odd issue trying to track down. We are seeing issue whereby > traffic just "pauses" through the ASA for about 2-4 seconds before > resuming. > > We started seeing this when the device was low on memory (about 600M > available). we rebooted it and did an firmware update the current version. > > Still seeing this behavior. > > After another reboot, still seeing this. > > Process: DATAPATH-0-1665, PROC_PC_TOTAL: 407, MAXHOG: 10, LASTHOG: 5 > MAXHOG At:15:31:54 PDT Jun 4 2024 > LASTHOG At: 15:37:48 PDT Jun 4 2024 > PC: 0x (suspend) > > Process: DATAPATH-0-1665, NUMHOG: 385, MAXHOG: 10, LASTHOG: 5 > MAXHOG At:15:31:54 PDT Jun 4 2024 > LASTHOG At: 15:37:48 PDT Jun 4 2024 > PC: 0x (suspend) > Call stack: 0x564741c98c49 0x564742188996 0x5647436c2d28 > 0x5647436d2abc 0x5647436e2ae0 0x7f2d2067bff5 > 0x7f2d1f88416f > > > Process: DATAPATH-1-1666, PROC_PC_TOTAL: 402, MAXHOG: 12, LASTHOG: 5 > MAXHOG At:15:31:48 PDT Jun 4 2024 > LASTHOG At: 15:37:41 PDT Jun 4 2024 > PC: 0x (suspend) > > Process: DATAPATH-1-1666, NUMHOG: 376, MAXHOG: 12, LASTHOG: 5 > MAXHOG At:15:31:48 PDT Jun 4 2024 > LASTHOG At: 15:37:41 PDT Jun 4 2024 > PC: 0x (suspend) > Call stack: 0x564741c98c49 0x564742188996 0x5647436c2d28 > 0x5647436d2abc 0x5647436e2ae0 0x7f2d2067bff5 > 0x7f2d1f88416f > > > > I did disable logging flash-bufferwrap to stop it from writing to flash. > The logging process stopped using 29% CPU, but still the issue persists. > > Anyone got any Ideas on what the cause is and how to resolve it? > > Best, > > -Lee > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Cisco ASA5516-x DATAPATH-0-1648 and DATAPATH-0-1648 CPU hog
Hello Everyone, I have an odd issue trying to track down. We are seeing issue whereby traffic just "pauses" through the ASA for about 2-4 seconds before resuming. We started seeing this when the device was low on memory (about 600M available). we rebooted it and did an firmware update the current version. Still seeing this behavior. After another reboot, still seeing this. Process: DATAPATH-0-1665, PROC_PC_TOTAL: 407, MAXHOG: 10, LASTHOG: 5 MAXHOG At:15:31:54 PDT Jun 4 2024 LASTHOG At: 15:37:48 PDT Jun 4 2024 PC: 0x (suspend) Process: DATAPATH-0-1665, NUMHOG: 385, MAXHOG: 10, LASTHOG: 5 MAXHOG At:15:31:54 PDT Jun 4 2024 LASTHOG At: 15:37:48 PDT Jun 4 2024 PC: 0x (suspend) Call stack: 0x564741c98c49 0x564742188996 0x5647436c2d28 0x5647436d2abc 0x5647436e2ae0 0x7f2d2067bff5 0x7f2d1f88416f Process: DATAPATH-1-1666, PROC_PC_TOTAL: 402, MAXHOG: 12, LASTHOG: 5 MAXHOG At:15:31:48 PDT Jun 4 2024 LASTHOG At: 15:37:41 PDT Jun 4 2024 PC: 0x (suspend) Process: DATAPATH-1-1666, NUMHOG: 376, MAXHOG: 12, LASTHOG: 5 MAXHOG At:15:31:48 PDT Jun 4 2024 LASTHOG At: 15:37:41 PDT Jun 4 2024 PC: 0x (suspend) Call stack: 0x564741c98c49 0x564742188996 0x5647436c2d28 0x5647436d2abc 0x5647436e2ae0 0x7f2d2067bff5 0x7f2d1f88416f I did disable logging flash-bufferwrap to stop it from writing to flash. The logging process stopped using 29% CPU, but still the issue persists. Anyone got any Ideas on what the cause is and how to resolve it? Best, -Lee ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] STP over Port-channel issue
Thanks good point on LACP Fast, we'll test it. RSTP should be in any case slower than 3 seconds with LACP FAST. Cheers James Il giorno lun 6 mag 2024 alle ore 15:22 Saku Ytti ha scritto: > On Mon, 6 May 2024 at 15:53, james list via cisco-nsp > wrote: > > > The question: since the PO remains up, why we see this behaviour ? > > are BDPU sent just over one link (ie the higher interfac e) ? > > Correct. > > > how can we solve this issue keeping this scenario ? > > moving to RSTP could solve ? > > No. > > I understand you want topology to remain intact, as long as there is > at least 1 member up, but I'm not sure we can guarantee that. I think > if you set LACP to fast, it'll fail in max 3s, and you ensure STP > fails slower (i.e. don't use rapid pvst), you probably will just see > BPDU switch physical interface, instead of STP convergence. > > You'd need something similar to microBFD on LAGs, where BFD PDU is > sent on each member, instead of an unspecified single member, but > afaik this does not exist. > > So what you really need is L3/MPLS topology :/. > > -- > ++ytti > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] STP over Port-channel issue
On Mon, 6 May 2024 at 15:53, james list via cisco-nsp wrote: > The question: since the PO remains up, why we see this behaviour ? > are BDPU sent just over one link (ie the higher interfac e) ? Correct. > how can we solve this issue keeping this scenario ? > moving to RSTP could solve ? No. I understand you want topology to remain intact, as long as there is at least 1 member up, but I'm not sure we can guarantee that. I think if you set LACP to fast, it'll fail in max 3s, and you ensure STP fails slower (i.e. don't use rapid pvst), you probably will just see BPDU switch physical interface, instead of STP convergence. You'd need something similar to microBFD on LAGs, where BFD PDU is sent on each member, instead of an unspecified single member, but afaik this does not exist. So what you really need is L3/MPLS topology :/. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] STP over Port-channel issue
dear experts a customer of mine has a legacy environment with 4 x Cisco 9500 (IOS XE 17.09.03) connected in a square mode with 2 links (2 per each connection) and each couple of links is considered a single virtual port (port-channel). Loops are managed with PVSTP. Two x C9500 are in DC1 while the other two x 9500 are in DC2. 9500-1 == 9500-3 || || 9500-2 == 9500-4 The issue is: when there is a provider flapping, ie one out of the two link connecting C9500 in the two DC is flapping, we see one port flaps, port-channel remains UP but PVSTP reconverge and there is a communication failure. The question: since the PO remains up, why we see this behaviour ? are BDPU sent just over one link (ie the higher interfac e) ? how can we solve this issue keeping this scenario ? moving to RSTP could solve ? Thanks in advance Cheers James here some logs: May 6 11:48:35.590: %LINEPROTO-5-UPDOWN: Line protocol on Interface TwentyFiveGigE1/0/48, changed state to down May 6 11:48:36.593: %LINK-3-UPDOWN: Interface TwentyFiveGigE1/0/48, changed state to down May 6 11:48:40.343: %LINK-3-UPDOWN: Interface TwentyFiveGigE1/0/48, changed state to up May 6 11:48:44.171: %LINEPROTO-5-UPDOWN: Line protocol on Interface TwentyFiveGigE1/0/48, changed state to up #sh etherchannel summary --+-+---+--- 1 Po1(SU) LACPTwe1/0/1(P) Twe1/0/2(P) 12 Po12(SU)LACPTwe1/0/47(P)Twe1/0/48(P) Port-channel: Po12(Primary Aggregator) Age of the Port-channel = 187d:15h:09m:01s Logical slot/port = 9/12 Number of ports = 2 HotStandBy port = null Port state = Port-channel Ag-Inuse Protocol= LACP Port security = Disabled Fast-switchover = disabled Fast-switchover Dampening = disabled Ports in the Port-channel: Index Load PortEC stateNo of bits --+--+--+--+--- 0 00 Twe1/0/47 Active 0 0 00 Twe1/0/48 Active 0 Time since last port bundled:0d:01h:50m:00s Twe1/0/48 Time since last port Un-bundled: 0d:01h:50m:09s Twe1/0/48 # sh spanning-tree interface port-channel 12 state VLAN0015blocking VLAN0016forwarding # sh spanning-tree vlan 15 detail VLAN0015 is executing the rstp compatible Spanning Tree protocol Bridge Identifier has priority 20480, sysid 15, address 8c84.4236.5fe0 Configured hello time 2, max age 20, forward delay 15, transmit hold-count 6 Current root has priority 8207, address 444c.a830.ff71 Root port is 2089 (Port-channel1), cost of root path is 2000 Topology change flag not set, detected flag not set Number of topology changes 73 last change occurred 01:52:13 ago from Port-channel1 Times: hold 1, topology change 35, notification 2 hello 2, max age 20, forward delay 15 Timers: hello 0, topology change 0, notification 0, aging 300 Port 2089 (Port-channel1) of VLAN0015 is root forwarding Port path cost 1000, Port priority 128, Port Identifier 128.2089. Designated root has priority 8207, address 444c.a830.ff71 Designated bridge has priority 16399, address cc79.d760.73e0 Designated port id is 128.2089, designated path cost 1000 Timers: message age 15, forward delay 0, hold 0 Number of transitions to forwarding state: 18 Link type is point-to-point by default BPDU: sent 289, received 4527220 Port 2100 (Port-channel12) of VLAN0015 is alternate blocking Port path cost 1000, Port priority 128, Port Identifier 128.2100. Designated root has priority 8207, address 444c.a830.ff71 Designated bridge has priority 12303, address 444c.a830.fc01 Designated port id is 128.107, designated path cost 1999 Timers: message age 15, forward delay 0, hold 0 Number of transitions to forwarding state: 20 Link type is point-to-point by default BPDU: sent 340, received 4525304 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] vPC members use identical virtual addresses without HSRP
Hi, Chen, The Arista configuration snippet you sent over is related to implementation of VXLAN distributed anycast gateway, not a traditional FHRP like HSRP, VRRP, or GLBP. In a standard VRRP configuration on Arista, Juniper or anything, one would expect to use multiple IPs for master and backup nodes/roles. You can implement this same configuration for Nexus following the configuration documentation for VXLAN anycast gateway. Thank you, Nathan On Sun, Apr 21, 2024 at 8:55 PM Chen Jiang via cisco-nsp < cisco-nsp@puck.nether.net> wrote: > Hi! Michael > > Thanks for your advice, I mean could 2*cisco devices support just use only > one identical address? > > ... > interface Vlan100 >vrf v101 >ip address virtual 192.168.100.254/24 > interface Vlan101 >vrf v101 >ip address virtual 192.168.101.254/24 > > On Sun, Apr 21, 2024 at 3:24 PM Michael Lee wrote: > > > Cisco support VRRP as well. > > > > Sent from my iPhone > > > > > On Apr 18, 2024, at 10:08 PM, Chen Jiang via cisco-nsp < > > cisco-nsp@puck.nether.net> wrote: > > > > > > Hi! Experts > > > > > > I wonder if Cisco support vPC members use identical virtual addresses > as > > > host's layer 3 gateway? > > > > > > Just like Arista or Juniper, > > > > > > Arista for example: > > > ... > > > interface Vlan100 > > > vrf v101 > > > ip address virtual 192.168.100.254/24 > > > interface Vlan101 > > > vrf v101 > > > ip address virtual 192.168.101.254/24 > > > ... > > > > > > From the Cisco document it seems all examples use HSRP and it needs to > > > occupy 3 IP addresses. > > > > > > Thanks for your help. > > > > > > -- > > > BR! > > > > > > > > > > > > James Chen > > > ___ > > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > -- > BR! > > > > James Chen > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] vPC members use identical virtual addresses without HSRP
Hi! Michael Thanks for your advice, I mean could 2*cisco devices support just use only one identical address? ... interface Vlan100 vrf v101 ip address virtual 192.168.100.254/24 interface Vlan101 vrf v101 ip address virtual 192.168.101.254/24 On Sun, Apr 21, 2024 at 3:24 PM Michael Lee wrote: > Cisco support VRRP as well. > > Sent from my iPhone > > > On Apr 18, 2024, at 10:08 PM, Chen Jiang via cisco-nsp < > cisco-nsp@puck.nether.net> wrote: > > > > Hi! Experts > > > > I wonder if Cisco support vPC members use identical virtual addresses as > > host's layer 3 gateway? > > > > Just like Arista or Juniper, > > > > Arista for example: > > ... > > interface Vlan100 > > vrf v101 > > ip address virtual 192.168.100.254/24 > > interface Vlan101 > > vrf v101 > > ip address virtual 192.168.101.254/24 > > ... > > > > From the Cisco document it seems all examples use HSRP and it needs to > > occupy 3 IP addresses. > > > > Thanks for your help. > > > > -- > > BR! > > > > > > > > James Chen > > ___ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- BR! James Chen ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] vPC members use identical virtual addresses without HSRP
Cisco support VRRP as well. Sent from my iPhone > On Apr 18, 2024, at 10:08 PM, Chen Jiang via cisco-nsp > wrote: > > Hi! Experts > > I wonder if Cisco support vPC members use identical virtual addresses as > host's layer 3 gateway? > > Just like Arista or Juniper, > > Arista for example: > ... > interface Vlan100 > vrf v101 > ip address virtual 192.168.100.254/24 > interface Vlan101 > vrf v101 > ip address virtual 192.168.101.254/24 > ... > > From the Cisco document it seems all examples use HSRP and it needs to > occupy 3 IP addresses. > > Thanks for your help. > > -- > BR! > > > > James Chen > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] vPC members use identical virtual addresses without HSRP
Hi! Experts I wonder if Cisco support vPC members use identical virtual addresses as host's layer 3 gateway? Just like Arista or Juniper, Arista for example: ... interface Vlan100 vrf v101 ip address virtual 192.168.100.254/24 interface Vlan101 vrf v101 ip address virtual 192.168.101.254/24 ... >From the Cisco document it seems all examples use HSRP and it needs to occupy 3 IP addresses. Thanks for your help. -- BR! James Chen ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Serious Bug in Cisco's 6500 & 6800 Platforms
On 4/9/24 15:29, Gert Doering wrote: I'm so glad our single box with SUP-2T has been retired many years ago... (We still do have one (1) Sup720-10G 6500 running, but that is being migrated away from right now) You are the first person I thought about, when I saw this advisory... Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Serious Bug in Cisco's 6500 & 6800 Platforms
hi, On Tue, Apr 09, 2024 at 03:20:15PM +0200, Mark Tinka via cisco-nsp wrote: > https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ios-dos-Hq4d3tZG I'm so glad our single box with SUP-2T has been retired many years ago... (We still do have one (1) Sup720-10G 6500 running, but that is being migrated away from right now) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Serious Bug in Cisco's 6500 & 6800 Platforms
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ios-dos-Hq4d3tZG Mark. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] CFM Configuration
Greetings all I am trying to configure CFM using simple topology with xconnect as L2VPN service. CE1 - PE2 - PE3 - CE7 ethernet cfm ieee ethernet cfm global ethernet cfm traceroute cache ethernet cfm alarm notification all ethernet cfm domain SPCOR_DOMAIN level 7 service EVC_SRVC evc EVC1 mep mpid 170 mip auto-create ! ethernet evc EVC1 oam protocol cfm domain SPCOR_DOMAIN interface GigabitEthernet1 no ip address negotiation auto no mop enabled no mop sysid service instance 10 ethernet EVC1 encapsulation dot1q 17 xconnect 10.1.100.3 17 encapsulation mpls cfm mep domain SPCOR_DOMAIN mpid 170 For local learning , am able to get the information. PE2#show ethernet cfm maintenance-points local Local MEPs: MPID Domain Name Lvl MacAddress Type CC Ofld Domain Id Dir Port Id MA Name SrvcInst Source EVC name 170 SPCOR_DOMAIN7 001e.f636.e6bf XCON I No SPCOR_DOMAINUpGi1N/A EVC_SRVC 10 Static EVC1 Total Local MEPs: 1 Local MIPs: None But am not able to get any remote information. PE2#show ethernet cfm maintenance-points remote PE2# PE2#ping ethernet mpid 170 domain SPCOR_DOMAIN service EVC_SRVC % No RMEP entry found in for mpid 170 at domain SPCOR_DOMAIN service EVC_SRVC, evc EVC1. Any lights would be appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Firepower Threat Defense Geolocation DB
Also it doesn't hurt to otherwise advertise your 8805 geofeed as per: https://datatracker.ietf.org/doc/html/rfc9092 -Original Message- From: Hank Nussbacher via cisco-nsp mailto:hank%20nussbacher%20via%20cisco-nsp%20%3ccisco-...@puck.nether.net%3e>> Reply-To: Hank Nussbacher mailto:hank%20nussbacher%20%3ch...@interall.co.il%3e>> To: cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net> Subject: Re: [c-nsp] Firepower Threat Defense Geolocation DB Date: Wed, 27 Mar 2024 16:54:26 +0200 On 26/03/2024 17:29, Jon Lewis via cisco-nsp wrote: Find out from Cisco where you can publish your geo-location data as per: https://www.rfc-editor.org/rfc/rfc8805.html If it is Google related, report the issue here: https://support.google.com/websearch/workflow/9308722?hl=en or define your geo-feed for Google here: https://isp.google.com/geo_feed/ Also test here: https://geolocatemuch.com/ Regards, Hank I've been going back and forth with cisco support for 2 weeks on this and gotten nowhere. Does anyone know of a way to verify (and update if needed) Cisco's IP Geo data for the FTD platform? I've been trying to get support to let me download the DB files from https://software.cisco.com/download/home/286322194/type/286321931/release/GeoDB but as I don't have the appropriate service contract, that seems to not be happening. We have an IP block (57.135/16) that is former RIPE space. We've had some IP Geo issues with it, but thought those were behind us. Recently, we've run into IP Geo based filtering/redirection issues with this space. The first was a network that admitted it was an issue with their FTD blocking our traffic & needing an update. So, I assume the latest IP Geo data from cisco has 57.135/16 correctly listed as ARIN/US, but I'd like to be sure of that and also look back at past versions of the DB to see how far behind someone needs to be to have it listed as RIPE/EU space. -- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Firepower Threat Defense Geolocation DB
On 26/03/2024 17:29, Jon Lewis via cisco-nsp wrote: Find out from Cisco where you can publish your geo-location data as per: https://www.rfc-editor.org/rfc/rfc8805.html If it is Google related, report the issue here: https://support.google.com/websearch/workflow/9308722?hl=en or define your geo-feed for Google here: https://isp.google.com/geo_feed/ Also test here: https://geolocatemuch.com/ Regards, Hank I've been going back and forth with cisco support for 2 weeks on this and gotten nowhere. Does anyone know of a way to verify (and update if needed) Cisco's IP Geo data for the FTD platform? I've been trying to get support to let me download the DB files from https://software.cisco.com/download/home/286322194/type/286321931/release/GeoDB but as I don't have the appropriate service contract, that seems to not be happening. We have an IP block (57.135/16) that is former RIPE space. We've had some IP Geo issues with it, but thought those were behind us. Recently, we've run into IP Geo based filtering/redirection issues with this space. The first was a network that admitted it was an issue with their FTD blocking our traffic & needing an update. So, I assume the latest IP Geo data from cisco has 57.135/16 correctly listed as ARIN/US, but I'd like to be sure of that and also look back at past versions of the DB to see how far behind someone needs to be to have it listed as RIPE/EU space. -- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Firepower Threat Defense Geolocation DB
I've been going back and forth with cisco support for 2 weeks on this and gotten nowhere. Does anyone know of a way to verify (and update if needed) Cisco's IP Geo data for the FTD platform? I've been trying to get support to let me download the DB files from https://software.cisco.com/download/home/286322194/type/286321931/release/GeoDB but as I don't have the appropriate service contract, that seems to not be happening. We have an IP block (57.135/16) that is former RIPE space. We've had some IP Geo issues with it, but thought those were behind us. Recently, we've run into IP Geo based filtering/redirection issues with this space. The first was a network that admitted it was an issue with their FTD blocking our traffic & needing an update. So, I assume the latest IP Geo data from cisco has 57.135/16 correctly listed as ARIN/US, but I'd like to be sure of that and also look back at past versions of the DB to see how far behind someone needs to be to have it listed as RIPE/EU space. -- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Teo En Ming's Notes on Basic Configuration of Cisco ASA 5516-X Firewall - Version 1
Subject: Teo En Ming's Notes on Basic Configuration of Cisco ASA 5516-X Firewall - Version 1 Good day from Singapore, Author: Mr. Turritopsis Dohrnii Teo En Ming Country: Singapore Date of Publication: 20 March 2024 Wednesday Document Version: 1 I have bought this refurbished/second hand/used Cisco ASA 5516-X firewall with FirePOWER Services for SGD$100 at Bukit Panjang Ring Road on 17 Mar 2024 Sunday at about 8.30 PM Singapore Time. On 19 March 2024 Tuesday, I have completed basic configuration of this firewall. Configuration Start: 19 March 2024 Tuesday, 9.22 PM Configuration End: 19 March 2024 Tuesday, 11.33 PM Below are my notes on configuring the Cisco ASA 5516-X firewall (basic). Part 1: Factory reset the Cisco ASA 5516-X firewall === Reference guide: Clearing, resetting or erasing configuration on Cisco ASA Link: https://www.linkedin.com/pulse/clearing-resetting-erasing-configuration-cisco-asa-darko-raki%C4%87?utm_source=share_medium=member_android_campaign=share_via cisco> en Password: * cisco# conf t cisco(config)# * NOTICE * Help to improve the ASA platform by enabling anonymous reporting, which allows Cisco to securely receive minimal error and health information from the device. To learn more about this feature, please visit: http://www.cisco.com/go/smartcall Would you like to enable anonymous error reporting to help improve the product? [Y]es, [N]o, [A]sk later: Y Enabling anonymous reporting. Adding "call-home reporting anonymous" to running configuration... Creating trustpoint "_SmartCallHome_ServerCA" and installing certificate... Trustpoint CA certificate accepted. Please remember to save your configuration. cisco(config)# configure factory-default Based on the inside IP address and mask, the DHCP address pool size is reduced to 250 from the platform limit 256 WARNING: The boot system configuration will be cleared. The first image found in disk0:/ will be used to boot the system on the next reload. Verify there is a valid image on disk0:/ or the system will not boot. Begin to apply factory-default configuration: Clear all configuration Executing command: ! Executing command: interface Management1/1 Executing command: management-only Executing command: no nameif Executing command: no security-level Executing command: no ip address Executing command: no shutdown Executing command: exit Executing command: ! Executing command: interface GigabitEthernet1/1 Executing command: nameif outside INFO: Security level for "outside" set to 0 by default. Executing command: security-level 0 Executing command: ip address dhcp setroute Executing command: no shutdown Executing command: exit Executing command: ! Executing command: interface GigabitEthernet1/2 Executing command: nameif inside INFO: Security level for "inside" set to 100 by default. Executing command: security-level 100 Executing command: ip address 192.168.1.1 255.255.255.0 Executing command: no shutdown Executing command: exit Executing command: ! Executing command: object network obj_any Executing command: subnet 0.0.0.0 0.0.0.0 Executing command: nat (any,outside) dynamic interface Executing command: exit Executing command: ! Executing command: http server enable Executing command: http 192.168.1.0 255.255.255.0 inside Executing command: ! Executing command: dhcpd auto_config outside Executing command: dhcpd address 192.168.1.5-192.168.1.254 inside Executing command: dhcpd enable inside Executing command: ! Executing command: logging asdm informational Executing command: ! Executing command: ! Executing command: ! Factory-default configuration is completed ciscoasa(config)# reload System config has been modified. Save? [Y]es/[N]o: y Cryptochecksum: 200435a9 cee9c848 4fb5e91d ac201631 3250 bytes copied in 0.150 secs Proceed with reload? [confirm] ciscoasa(config)# *** *** --- START GRACEFUL SHUTDOWN --- Shutting down isakmp Shutting down webvpn Shutting down sw-module Shutting down License Controller Shutting down File system *** *** --- SHUTDOWN NOW --- Process shutdown finished Rebooting... (status 0x9) .. INIT: Sending processes the TERM signal Deconfiguring network interfaces... done. Sending all processes the TERM signal... Sending all processes the KILL signal... Deactivating swap... Unmounting local filesystems... Rebooting... Part 2: Basic Configuration of Cisco ASA 5516-X Firewall ===== Reference guide: Basic Cisco ASA 5506-x Configuration Example Link: https://www.speaknetworks.com/basic-cisco-asa-5506-x-configuration-example/ ciscoasa> en Password: ciscoasa# ciscoasa# show bootvar BOOT variable = Current BOOT variable = CONFIG_FILE variable = Current CONFIG_FILE variable = Step 1: Configure ASA int
[c-nsp] Cisco ASA 5516-X Firewall (Open Source) Console Bootup Messages and Show Version
Subject: Cisco ASA 5516-X Firewall (Open Source) Console Bootup Messages and Show Version Good day from Singapore, I have bought this refurbished/second hand/used Cisco ASA 5516-X firewall with FirePOWER Services for SGD$100 at Bukit Panjang Ring Road on 17 Mar 2024 Sunday at about 8.30 PM Singapore Time. Cisco ASA firewalls use open source software. Console Output Below = Rom image verified correctly Cisco Systems ROMMON, Version 1.1.8, RELEASE SOFTWARE Copyright (c) 1994-2015 by Cisco Systems, Inc. Compiled Thu 06/18/2015 12:15:56.43 by builders Current image running: Boot ROM0 Last reset cause: PowerOn DIMM Slot 0 : Present DIMM Slot 1 : Present Platform ASA5516 with 8192 Mbytes of main memory MAC Address: 70:70:8b:67:c9:64 Use BREAK or ESC to interrupt boot. Use SPACE to begin boot immediately. Located '.boot_string' @ cluster 841081. # Attempt autoboot: "boot disk0:" Located 'asa971-4-lfbff-k8.SPA' @ cluster 11. ## ### LFBFF signature verified. INIT: version 2.88 booting Starting udev Configuring network interfaces... done. Populating dev cache dosfsck 2.11, 12 Mar 2005, FAT32, LFN There are differences between boot sector and its backup. Differences: (offset:original/backup) 65:01/00 Not automatically fixing this. Starting check/repair pass. Starting verification pass. /dev/sdb1: 116 files, 820003/1798211 clusters dosfsck(/dev/sdb1) returned 0 Mounting /dev/sdb1 IO Memory Nodes: 1 IO Memory Per Node: 499122176 bytes Global Reserve Memory Per Node: 314572800 bytes Nodes=1 LCMB: got 499122176 bytes on numa-id=0, phys=0x1b140, virt=0x2ae0 LCMB: HEAP-CACHE POOL got 314572800 bytes on numa-id=0, virt=0x2aaac8a0 Processor memory: 4379978902 Compiled on Fri 31-Mar-17 07:21 PDT by builders Total NICs found: 14 i354 rev03 Gigabit Ethernet @ irq255 dev 20 index 08 MAC: 7070.8b67.c964 ivshmem rev03 Backplane Data Interface @ index 09 MAC: .0001.0002 en_vtun rev00 Backplane Control Interface @ index 10 MAC: .0001.0001 en_vtun rev00 Backplane Int-Mgmt Interface @ index 11 MAC: .0001.0003 en_vtun rev00 Backplane Ext-Mgmt Interface @ index 12 MAC: .. en_vtun rev00 Backplane Tap Interface @ index 13 MAC: .0100.0001 Verify the activation-key, it might take a while... Running Permanent Activation Key: Licensed features for this platform: Maximum Physical Interfaces : Unlimited perpetual Maximum VLANs : 150perpetual Inside Hosts : Unlimited perpetual Failover : Active/Active perpetual Encryption-DES: Enabledperpetual Encryption-3DES-AES : Enabledperpetual Security Contexts : 2 perpetual Carrier : Disabled perpetual AnyConnect Premium Peers : 4 perpetual AnyConnect Essentials : Disabled perpetual Other VPN Peers : 300perpetual Total VPN Peers : 300perpetual AnyConnect for Mobile : Disabled perpetual AnyConnect for Cisco VPN Phone: Disabled perpetual Advanced Endpoint Assessment : Disabled perpetual Shared License: Disabled perpetual Total TLS Proxy Sessions : 1000 perpetual Botnet Traffic Filter : Disabled perpetual Cluster : Enabledperpetual Cluster Members : 2 perpetual VPN Load Balancing: Enabledperpetual Encryption hardware device : Cisco ASA Crypto on-board accelerator (revision 0x1) Cisco Adaptive Security Appliance Software Version 9.7(1)4 ** Warning *** This product contains cryptographic features and is
[c-nsp] Login Alarms
Greetings Do Cisco has similar feature to :https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/login-alarms-edit-system.html Appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Not to hijack the thread, but I wanted to add -- Just because the fiber jumpers are new, does not mean they are clean. I had a 40 gig link that started taking errors. Moreso when it was under load. I personally cleaned everything. Still had issues. Replaced the optics, no change. New, cleaned jumper. No change. Eventually had our fiber techs look at it. When they scoped the jumpers, they were awful. They cleaned them (one-click, and wipe style cleaner), still bad. After a serious wet clean they finally pronounced them good. Circuit has been fibe ever since. On Mon, Feb 12, 2024 at 3:24 AM Saku Ytti via cisco-nsp < cisco-nsp@puck.nether.net> wrote: > On Mon, 12 Feb 2024 at 09:44, james list wrote: > > > I'd like to test with LACP slow, then can see if physical interface > still flaps... > > I don't think that's good idea, like what would we know? Would we have > to wait 30 times longer, so month-3months, to hit what ever it is, > before we have confidence? > > I would suggest > - turn on debugging, to see cisco emitting LACP PDU, and juniper > receiving LACP PDU > - do packet capture, if at all reasonable, ideally tap, but in > absence of tap mirror > - turn off LACP distributed handling on junos > - ping on the link, ideally 0.2-0.5s interval, to record how ping > stops in relation to first syslog emitted about LACP going down > - wait for 4days > > > -- > ++ytti > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
On Mon, 12 Feb 2024 at 09:44, james list wrote: > I'd like to test with LACP slow, then can see if physical interface still > flaps... I don't think that's good idea, like what would we know? Would we have to wait 30 times longer, so month-3months, to hit what ever it is, before we have confidence? I would suggest - turn on debugging, to see cisco emitting LACP PDU, and juniper receiving LACP PDU - do packet capture, if at all reasonable, ideally tap, but in absence of tap mirror - turn off LACP distributed handling on junos - ping on the link, ideally 0.2-0.5s interval, to record how ping stops in relation to first syslog emitted about LACP going down - wait for 4days -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
hi I'd like to test with LACP slow, then can see if physical interface still flaps... Thanks for your support Il giorno dom 11 feb 2024 alle ore 18:02 Saku Ytti ha scritto: > On Sun, 11 Feb 2024 at 17:52, james list wrote: > > > - why physical interface flaps in DC1 if it is related to lacp ? > > 16:39:35.813 Juniper reports LACP timeout (so problem started at > 16:39:32, (was traffic passing at 32, 33, 34 seconds?)) > 16:39:36.xxx Cisco reports interface down, long after problem has > already started > > Why Cisco reports physical interface down, I'm not sure. But clearly > the problem was already happening before interface down, and first log > entry is LACP timeout, which occurs 3s after the problem starts. > Perhaps Juniper asserts for some reason RFI? Perhaps Cisco resets the > physical interface once removed from LACP? > > > - why the same setup in DC2 do not report issues ? > > If this is is LACP related software issue, could be difference not > identified. You need to gather more information, like how does ping > look throughout this event, particularly before syslog entries. And if > ping still works up-until syslog, you almost certainly have software > issue with LACP inject at Cisco, or more likely LACP punt at Juniper. > > -- > ++ytti > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
On Sun, 11 Feb 2024 at 17:52, james list wrote: > - why physical interface flaps in DC1 if it is related to lacp ? 16:39:35.813 Juniper reports LACP timeout (so problem started at 16:39:32, (was traffic passing at 32, 33, 34 seconds?)) 16:39:36.xxx Cisco reports interface down, long after problem has already started Why Cisco reports physical interface down, I'm not sure. But clearly the problem was already happening before interface down, and first log entry is LACP timeout, which occurs 3s after the problem starts. Perhaps Juniper asserts for some reason RFI? Perhaps Cisco resets the physical interface once removed from LACP? > - why the same setup in DC2 do not report issues ? If this is is LACP related software issue, could be difference not identified. You need to gather more information, like how does ping look throughout this event, particularly before syslog entries. And if ping still works up-until syslog, you almost certainly have software issue with LACP inject at Cisco, or more likely LACP punt at Juniper. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Hi I have a couple of points to ask related to your idea: - why physical interface flaps in DC1 if it is related to lacp ? - why the same setup in DC2 do not report issues ? NEXUS01# sh logging | in Initia | last 15 2024 Jan 17 22:37:49 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 18 23:54:25 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 19 00:58:13 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 19 07:15:04 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 22 16:03:13 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 25 21:32:29 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 26 18:41:12 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 28 05:07:20 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 29 04:06:52 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Jan 30 03:09:44 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Feb 5 18:13:20 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Feb 6 02:17:25 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Feb 6 22:00:24 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Feb 9 09:29:36 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Feb 9 16:39:36 NEXUS01 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) Il giorno dom 11 feb 2024 alle ore 14:36 Saku Ytti ha scritto: > On Sun, 11 Feb 2024 at 15:24, james list wrote: > > > While on Juniper when the issue happens I always see: > > > > show log messages | last 440 | match LACPD_TIMEOUT > > Jan 25 21:32:27.948 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: > lacp current while timer expired current Receive State: CURRENT > > > Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: > lacp current while timer expired current Receive State: CURRENT > > Ok so problem always starts by Juniper seeing 3seconds without LACP > PDU, i.e. missing 3 consecutive LACP PDU. It would be good to ping > while this problem is happening, to see if ping stops at 3s before the > syslog lines, or at the same time as syslog lines. > If ping stops 3s before, it's link problem from cisco to juniper. > If ping stops at syslog time (my guess), it's software problem. > > There is unfortunately log of bug surface here, both on inject and on > punt path. You could be hitting PR1541056 on the Juniper end. You > could test for this by removing distributed LACP handling with 'set > routing-options ppm no-delegate-processing' > You could also do packet capture for LACP on both ends, to try to see > if LACP was sent by Cisco and received by capture, but not by system. > > > -- > ++ytti > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
On Sun, 11 Feb 2024 at 15:24, james list wrote: > While on Juniper when the issue happens I always see: > > show log messages | last 440 | match LACPD_TIMEOUT > Jan 25 21:32:27.948 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp > current while timer expired current Receive State: CURRENT > Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp > current while timer expired current Receive State: CURRENT Ok so problem always starts by Juniper seeing 3seconds without LACP PDU, i.e. missing 3 consecutive LACP PDU. It would be good to ping while this problem is happening, to see if ping stops at 3s before the syslog lines, or at the same time as syslog lines. If ping stops 3s before, it's link problem from cisco to juniper. If ping stops at syslog time (my guess), it's software problem. There is unfortunately log of bug surface here, both on inject and on punt path. You could be hitting PR1541056 on the Juniper end. You could test for this by removing distributed LACP handling with 'set routing-options ppm no-delegate-processing' You could also do packet capture for LACP on both ends, to try to see if LACP was sent by Cisco and received by capture, but not by system. -- ++ytti _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
On Cisco I see physical goes down (initializing), what does that mean? While on Juniper when the issue happens I always see: show log messages | last 440 | match LACPD_TIMEOUT Jan 25 21:32:27.948 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Jan 26 18:41:12.514 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Jan 28 05:07:20.283 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Jan 29 04:06:51.768 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Jan 30 03:09:43.923 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Feb 5 18:13:20.158 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Feb 6 02:17:23.703 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Feb 6 22:00:23.758 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Feb 9 09:29:35.728 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Il giorno dom 11 feb 2024 alle ore 14:10 Saku Ytti ha scritto: > Hey James, > > You shared this off-list, I think it's sufficiently material to share. > > 2024 Feb 9 16:39:36 NEXUS1 > %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface > port-channel101 is down (No operational members) > 2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_DOWN: > port-channel101: Ethernet1/44 is down > Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: > lacp current while timer expired current Receive State: CURRENT > Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACP_INTF_DOWN: ae49: > Interface marked down due to lacp timeout on member et-0/1/5 > > We can't know the order of events here, due to no subsecond precision > enabled on Cisco end. > > But if failure would start from interface down, it would take 3seconds > for Juniper to realise LACP failure. However we can see that it > happens in less than 1s, so we can determine the interface was not > down first, the first problem was Juniper not receiving 3 consecutive > LACP PDUs, 1s apart, prior to noticing any type of interface state > related problems. > > Is this always the order of events? Does it always happen with Juniper > noticing problems receiving LACP PDU first? > > > On Sun, 11 Feb 2024 at 14:55, james list via juniper-nsp > wrote: > > > > Hi > > > > 1) cable has been replaced with a brand new one, they said that to check > an > > MPO 100 Gbs cable is not that easy > > > > 3) no errors reported on both side > > > > 2) here the output of cisco and juniper > > > > NEXUS1# sh interface eth1/44 transceiver details > > Ethernet1/44 > > transceiver is present > > type is QSFP-100G-SR4 > > name is CISCO-INNOLIGHT > > part number is TR-FC85S-NC3 > > revision is 2C > > serial number is INL27050TVT > > nominal bitrate is 25500 MBit/sec > > Link length supported for 50/125um OM3 fiber is 70 m > > cisco id is 17 > > cisco extended id number is 220 > > cisco part number is 10-3142-03 > > cisco product id is QSFP-100G-SR4-S > > cisco version id is V03 > > > > Lane Number:1 Network Lane > >SFP Detail Diagnostics Information (internal calibration) > > > > > > > Current Alarms Warnings > > Measurement HighLow High Low > > > > > > > Temperature 30.51 C75.00 C -5.00 C 70.00 C > 0.00 C > > Voltage3.28 V 3.63 V 2.97 V 3.46 V > 3.13 V > > Current6.40 mA 12.45 mA 3.25 mA12.45 mA > 3.25 > > mA > > Tx Power 0.98 dBm 5.39 dBm -12.44 dBm2.39 dBm > -8.41 > > dBm > > Rx Power -1.60 dBm 5.39 dBm -14.31 dBm2.39 dBm > -10.31 > > dBm > > Transmit Fault Count = 0 > > > > > > > Note: ++ high-alarm;
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Hey James, You shared this off-list, I think it's sufficiently material to share. 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel101 is down (No operational members) 2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel101: Ethernet1/44 is down Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACP_INTF_DOWN: ae49: Interface marked down due to lacp timeout on member et-0/1/5 We can't know the order of events here, due to no subsecond precision enabled on Cisco end. But if failure would start from interface down, it would take 3seconds for Juniper to realise LACP failure. However we can see that it happens in less than 1s, so we can determine the interface was not down first, the first problem was Juniper not receiving 3 consecutive LACP PDUs, 1s apart, prior to noticing any type of interface state related problems. Is this always the order of events? Does it always happen with Juniper noticing problems receiving LACP PDU first? On Sun, 11 Feb 2024 at 14:55, james list via juniper-nsp wrote: > > Hi > > 1) cable has been replaced with a brand new one, they said that to check an > MPO 100 Gbs cable is not that easy > > 3) no errors reported on both side > > 2) here the output of cisco and juniper > > NEXUS1# sh interface eth1/44 transceiver details > Ethernet1/44 > transceiver is present > type is QSFP-100G-SR4 > name is CISCO-INNOLIGHT > part number is TR-FC85S-NC3 > revision is 2C > serial number is INL27050TVT > nominal bitrate is 25500 MBit/sec > Link length supported for 50/125um OM3 fiber is 70 m > cisco id is 17 > cisco extended id number is 220 > cisco part number is 10-3142-03 > cisco product id is QSFP-100G-SR4-S > cisco version id is V03 > > Lane Number:1 Network Lane >SFP Detail Diagnostics Information (internal calibration) > > > Current Alarms Warnings > Measurement HighLow High Low > > > Temperature 30.51 C75.00 C -5.00 C 70.00 C0.00 C > Voltage3.28 V 3.63 V 2.97 V 3.46 V3.13 V > Current6.40 mA 12.45 mA 3.25 mA12.45 mA 3.25 > mA > Tx Power 0.98 dBm 5.39 dBm -12.44 dBm2.39 dBm -8.41 > dBm > Rx Power -1.60 dBm 5.39 dBm -14.31 dBm2.39 dBm-10.31 > dBm > Transmit Fault Count = 0 > > > Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning > > Lane Number:2 Network Lane >SFP Detail Diagnostics Information (internal calibration) > > > Current Alarms Warnings > Measurement HighLow High Low > > > Temperature 30.51 C75.00 C -5.00 C 70.00 C0.00 C > Voltage3.28 V 3.63 V 2.97 V 3.46 V3.13 V > Current6.40 mA 12.45 mA 3.25 mA12.45 mA 3.25 > mA > Tx Power 0.62 dBm 5.39 dBm -12.44 dBm2.39 dBm -8.41 > dBm > Rx Power -1.18 dBm 5.39 dBm -14.31 dBm2.39 dBm-10.31 > dBm > Transmit Fault Count = 0 > > > Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning > > Lane Number:3 Network Lane >SFP Detail Diagnostics Information (internal calibration) > > > Current Alarms Warnings > Measurement HighLow High Low > > > Temperature 30.51 C75.00 C -5.00 C 70.00 C0.00 C > Voltage3.28 V 3.63 V 2.97 V 3.46 V3.13 V > Current6.40 mA 12.45 mA 3.25 mA12.45 mA 3.25 > mA > Tx Power 0.87 dBm 5.39 dBm -12.44 dBm2.39 dBm -8.41 > dBm > Rx Power 0.01 dBm 5.39 dBm -14.31 dBm2.39 dBm-10.31 > d
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Hi 1) cable has been replaced with a brand new one, they said that to check an MPO 100 Gbs cable is not that easy 3) no errors reported on both side 2) here the output of cisco and juniper NEXUS1# sh interface eth1/44 transceiver details Ethernet1/44 transceiver is present type is QSFP-100G-SR4 name is CISCO-INNOLIGHT part number is TR-FC85S-NC3 revision is 2C serial number is INL27050TVT nominal bitrate is 25500 MBit/sec Link length supported for 50/125um OM3 fiber is 70 m cisco id is 17 cisco extended id number is 220 cisco part number is 10-3142-03 cisco product id is QSFP-100G-SR4-S cisco version id is V03 Lane Number:1 Network Lane SFP Detail Diagnostics Information (internal calibration) Current Alarms Warnings Measurement HighLow High Low Temperature 30.51 C75.00 C -5.00 C 70.00 C0.00 C Voltage3.28 V 3.63 V 2.97 V 3.46 V3.13 V Current6.40 mA 12.45 mA 3.25 mA12.45 mA 3.25 mA Tx Power 0.98 dBm 5.39 dBm -12.44 dBm2.39 dBm -8.41 dBm Rx Power -1.60 dBm 5.39 dBm -14.31 dBm2.39 dBm-10.31 dBm Transmit Fault Count = 0 Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning Lane Number:2 Network Lane SFP Detail Diagnostics Information (internal calibration) Current Alarms Warnings Measurement HighLow High Low Temperature 30.51 C75.00 C -5.00 C 70.00 C0.00 C Voltage3.28 V 3.63 V 2.97 V 3.46 V3.13 V Current6.40 mA 12.45 mA 3.25 mA12.45 mA 3.25 mA Tx Power 0.62 dBm 5.39 dBm -12.44 dBm2.39 dBm -8.41 dBm Rx Power -1.18 dBm 5.39 dBm -14.31 dBm2.39 dBm-10.31 dBm Transmit Fault Count = 0 Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning Lane Number:3 Network Lane SFP Detail Diagnostics Information (internal calibration) Current Alarms Warnings Measurement HighLow High Low Temperature 30.51 C75.00 C -5.00 C 70.00 C0.00 C Voltage3.28 V 3.63 V 2.97 V 3.46 V3.13 V Current6.40 mA 12.45 mA 3.25 mA12.45 mA 3.25 mA Tx Power 0.87 dBm 5.39 dBm -12.44 dBm2.39 dBm -8.41 dBm Rx Power 0.01 dBm 5.39 dBm -14.31 dBm2.39 dBm-10.31 dBm Transmit Fault Count = 0 Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning Lane Number:4 Network Lane SFP Detail Diagnostics Information (internal calibration) Current Alarms Warnings Measurement HighLow High Low Temperature 30.51 C75.00 C -5.00 C 70.00 C0.00 C Voltage3.28 V 3.63 V 2.97 V 3.46 V3.13 V Current6.40 mA 12.45 mA 3.25 mA12.45 mA 3.25 mA Tx Power 0.67 dBm 5.39 dBm -12.44 dBm2.39 dBm -8.41 dBm Rx Power 0.11 dBm 5.39 dBm -14.31 dBm2.39 dBm-10.31 dBm Transmit Fault Count = 0 Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning MX1> show interfaces diagnostics optics et-1/0/5 Physical interface: et-1/0/5 Module temperature: 38 degrees C / 100 degrees F Module voltage: 3.2740 V Module temperature high alarm : Off Module temperature low alarm : Off Module temperature high warning : Off Module temperature low warning: Off Module voltage high al
Re: [c-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Hi there are no errors on both interfaces (Cisco and Juniper). here following logs of one event on both side, config and LACP stats. LOGS of one event time 16:39: CISCO 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel101 is down (No operational members) 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_PARENT_DOWN: Interface port-channel101.2303 is down (Parent interface is down) 2024 Feb 9 16:39:36 NEXUS1 %BGP-5-ADJCHANGE: bgp- [xxx] (xxx) neighbor 172.16.6.17 Down - sent: other configuration change 2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-FOP_CHANGED: port-channel101: first operational port changed from Ethernet1/44 to none 2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel101: Ethernet1/44 is down 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_BANDWIDTH_CHANGE: Interface port-channel101,bandwidth changed to 10 Kbit 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel101 is down (No operational members) 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-SPEED: Interface port-channel101, operational speed changed to 100 Gbps 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DUPLEX: Interface port-channel101, operational duplex mode changed to Full 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface port-channel101, operational Receive Flow Control state changed to off 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface port-channel101, operational Transmit Flow Control state changed to off 2024 Feb 9 16:39:39 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_UP: port-channel101: Ethernet1/44 is up 2024 Feb 9 16:39:39 NEXUS1 %ETH_PORT_CHANNEL-5-FOP_CHANGED: port-channel101: first operational port changed from none to Ethernet1/44 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_BANDWIDTH_CHANGE: Interface port-channel101,bandwidth changed to 1 Kbit 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_UP: Interface Ethernet1/44 is up in Layer3 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_UP: Interface port-channel101 is up in Layer3 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_UP: Interface port-channel101.2303 is up in Layer3 2024 Feb 9 16:39:43 NEXUS1 %BGP-5-ADJCHANGE: bgp- [xxx] (xxx) neighbor 172.16.6.17 Up Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACPD_TIMEOUT: et-0/1/5: lacp current while timer expired current Receive State: CURRENT Feb 9 16:39:35.813 2024 MX1 lacpd[31632]: LACP_INTF_DOWN: ae49: Interface marked down due to lacp timeout on member et-0/1/5 Feb 9 16:39:35.819 2024 MX1 kernel: lag_bundlestate_ifd_change: bundle ae49: bundle IFD minimum bandwidth or minimum links not met, Bandwidth (Current : Required) 0 : 1000 Number of links (Current : Required) 0 : 1 Feb 9 16:39:35.815 2024 MX1 lacpd[31632]: LACP_INTF_MUX_STATE_CHANGED: ae49: et-0/1/5: Lacp state changed from COLLECTING_DISTRIBUTING to ATTACHED, actor port state : |EXP|-|-|-|IN_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|DIS|COL|OUT_OF_SYNC|AGG|SHORT|ACT| Feb 9 16:39:35.869 2024 MX1 rpd[31866]: bgp_ifachange_group:10697: NOTIFICATION sent to 172.16.6.18 (External AS xxx): code 6 (Cease) subcode 6 (Other Configuration Change), Reason: Interface change for the peer-group Feb 9 16:39:35.909 2024 MX1 mib2d[31909]: SNMP_TRAP_LINK_DOWN: ifIndex 684, ifAdminStatus up(1), ifOperStatus down(2), ifName ae49 Feb 9 16:39:36.083 2024 MX1 lacpd[31632]: LACP_INTF_MUX_STATE_CHANGED: ae49: et-0/1/5: Lacp state changed from ATTACHED to COLLECTING_DISTRIBUTING, actor port state : |-|-|DIS|COL|IN_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|DIS|COL|IN_SYNC|AGG|SHORT|ACT| Feb 9 16:39:36.089 2024 MX1 kernel: lag_bundlestate_ifd_change: bundle ae49 is now Up. uplinks 1 >= min_links 1 Feb 9 16:39:36.089 2024 MX1 kernel: lag_bundlestate_ifd_change: bundle ae49: bundle IFD minimum bandwidth or minimum links not met, Bandwidth (Current : Required) 0 : 1000 Number of links (Current : Required) 0 : 1 Feb 9 16:39:36.085 2024 MX1 lacpd[31632]: LACP_INTF_MUX_STATE_CHANGED: ae49: et-0/1/5: Lacp state changed from COLLECTING_DISTRIBUTING to ATTACHED, actor port state : |-|-|-|-|IN_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|-|-|OUT_OF_SYNC|AGG|SHORT|ACT| Feb 9 16:39:39.095 2024 MX1 lacpd[31632]: LACP_INTF_MUX_STATE_CHANGED: ae49: et-0/1/5: Lacp state changed from ATTACHED to COLLECTING_DISTRIBUTING, actor port state : |-|-|DIS|COL|IN_SYNC|AGG|SHORT|ACT|, partner port state : |-|-|-|-|IN_SYNC|AGG|SHORT|ACT| Feb 9 16:39:39.101 2024 MX1 kernel: lag_bundlestate_ifd_change: bundle ae49 is now Up. uplinks 1 >= min_links 1 Feb 9 16:39:39.109 2024 MX1 mib2d[31909]: SNMP_TRAP_LINK_UP: ifIndex 684, ifAdminStatus up(1), ifOperStatus up(1), ifName ae49 Feb 9 16:39:41.190 2024 MX1 rpd[31866]: bgp_recv: read from peer 172.16.6.18 (External AS xxx) failed: Unknown error: 48110976 CONFIG: CISCO NEXUS1# sh r
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
I want to clarify, I meant this in the context of the original question.
That is, if you have a BGP specific problem, and no FCS errors, then
you can't have link problems.
But in this case, the problem is not BGP specific, in fact it has
nothing to do with BGP, since the problem begins on observing link
flap.
On Sun, 11 Feb 2024 at 14:14, Saku Ytti wrote:
>
> I don't think any of these matter. You'd see FCS failure on any
> link-related issue causing the BGP packet to drop.
>
> If you're not seeing FCS failures, you can ignore all link related
> problems in this case.
>
>
> On Sun, 11 Feb 2024 at 14:13, Havard Eidnes via juniper-nsp
> wrote:
> >
> > > DC technicians states cable are the same in both DCs and
> > > direct, no patch panel
> >
> > Things I would look at:
> >
> > * Has all the connectors been verified clean via microscope?
> >
> > * Optical levels relative to threshold values (may relate to the
> >first).
> >
> > * Any end seeing any input errors? (May relate to the above
> >two.) On the Juniper you can see some of this via PCS
> >("Physical Coding Sublayer") unexpected events independently
> >of whether you have payload traffic, not sure you can do the
> >same on the Nexus boxes.
> >
> > Regards,
> >
> > - Håvard
> > ___
> > juniper-nsp mailing list juniper-...@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> ++ytti
--
++ytti
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
I don't think any of these matter. You'd see FCS failure on any
link-related issue causing the BGP packet to drop.
If you're not seeing FCS failures, you can ignore all link related
problems in this case.
On Sun, 11 Feb 2024 at 14:13, Havard Eidnes via juniper-nsp
wrote:
>
> > DC technicians states cable are the same in both DCs and
> > direct, no patch panel
>
> Things I would look at:
>
> * Has all the connectors been verified clean via microscope?
>
> * Optical levels relative to threshold values (may relate to the
>first).
>
> * Any end seeing any input errors? (May relate to the above
>two.) On the Juniper you can see some of this via PCS
>("Physical Coding Sublayer") unexpected events independently
>of whether you have payload traffic, not sure you can do the
>same on the Nexus boxes.
>
> Regards,
>
> - Håvard
> ___
> juniper-nsp mailing list juniper-...@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
--
++ytti
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
> DC technicians states cable are the same in both DCs and
> direct, no patch panel
Things I would look at:
* Has all the connectors been verified clean via microscope?
* Optical levels relative to threshold values (may relate to the
first).
* Any end seeing any input errors? (May relate to the above
two.) On the Juniper you can see some of this via PCS
("Physical Coding Sublayer") unexpected events independently
of whether you have payload traffic, not sure you can do the
same on the Nexus boxes.
Regards,
- Håvard
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
On Sun, 11 Feb 2024 at 13:51, james list via juniper-nsp wrote: > One think I've omit to say is that BGP is over a LACP with currently just > one interface 100 Gbs. > > I see that the issue is triggered on Cisco when eth interface seems to go > in Initializing state: Ok, so we can forget BGP entirely. And focus on why the LACP is going down. Is the LACP single port, eth1/44? When the LACP fails, does Juniper end emit any syslog? Does Juniper see the interface facing eth1/44 flapping? -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
DC technicians states cable are the same in both DCs and direct, no patch panel Cheers Il giorno dom 11 feb 2024 alle ore 11:20 nivalMcNd d ha scritto: > Can it be DC1 is connecting links over an intermediary patch panel and you > face fibre disturbance? That may be eliminated if your interfaces on DC1 > links do not go down > > On Sun, Feb 11, 2024, 21:16 Igor Sukhomlinov via cisco-nsp < > cisco-nsp@puck.nether.net> wrote: > >> Hi James, >> >> Do you happen to run the same software on all nexuses and all MXes? >> Do the DC1 and DC2 bgp session exchange the same amount of routing updates >> across the links? >> >> >> On Sun, Feb 11, 2024, 21:09 james list via cisco-nsp < >> cisco-nsp@puck.nether.net> wrote: >> >> > Dear experts >> > we have a couple of BGP peers over a 100 Gbs interconnection between >> > Juniper (MX10003) and Cisco (Nexus N9K-C9364C) in two different >> datacenters >> > like this: >> > >> > DC1 >> > MX1 -- bgp -- NEXUS1 >> > MX2 -- bgp -- NEXUS2 >> > >> > DC2 >> > MX3 -- bgp -- NEXUS3 >> > MX4 -- bgp -- NEXUS4 >> > >> > The issue we see is that sporadically (ie every 1 to 3 days) we notice >> BGP >> > flaps only in DC1 on both interconnections (not at the same time), >> there is >> > still no traffic since once noticed the flaps we have blocked deploy on >> > production. >> > >> > We've already changed SPF (we moved the ones from DC2 to DC1 and >> viceversa) >> > and cables on both the interconnetion at DC1 without any solution. >> > >> > SFP we use in both DCs: >> > >> > Juniper - QSFP-100G-SR4-T2 >> > Cisco - QSFP-100G-SR4 >> > >> > over MPO cable OM4. >> > >> > Distance is DC1 70 mt and DC2 80 mt, hence is less where we see the >> issue. >> > >> > Any idea or suggestion what to check or to do ? >> > >> > Thanks in advance >> > Cheers >> > James >> > ___ >> > cisco-nsp mailing list cisco-nsp@puck.nether.net >> > https://puck.nether.net/mailman/listinfo/cisco-nsp >> > archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
yes same version currently no traffic exchange is in place, just BGP peer setup no traffic Il giorno dom 11 feb 2024 alle ore 11:16 Igor Sukhomlinov < dvalinsw...@gmail.com> ha scritto: > Hi James, > > Do you happen to run the same software on all nexuses and all MXes? > Do the DC1 and DC2 bgp session exchange the same amount of routing updates > across the links? > > > On Sun, Feb 11, 2024, 21:09 james list via cisco-nsp < > cisco-nsp@puck.nether.net> wrote: > >> Dear experts >> we have a couple of BGP peers over a 100 Gbs interconnection between >> Juniper (MX10003) and Cisco (Nexus N9K-C9364C) in two different >> datacenters >> like this: >> >> DC1 >> MX1 -- bgp -- NEXUS1 >> MX2 -- bgp -- NEXUS2 >> >> DC2 >> MX3 -- bgp -- NEXUS3 >> MX4 -- bgp -- NEXUS4 >> >> The issue we see is that sporadically (ie every 1 to 3 days) we notice BGP >> flaps only in DC1 on both interconnections (not at the same time), there >> is >> still no traffic since once noticed the flaps we have blocked deploy on >> production. >> >> We've already changed SPF (we moved the ones from DC2 to DC1 and >> viceversa) >> and cables on both the interconnetion at DC1 without any solution. >> >> SFP we use in both DCs: >> >> Juniper - QSFP-100G-SR4-T2 >> Cisco - QSFP-100G-SR4 >> >> over MPO cable OM4. >> >> Distance is DC1 70 mt and DC2 80 mt, hence is less where we see the issue. >> >> Any idea or suggestion what to check or to do ? >> >> Thanks in advance >> Cheers >> James >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Hi One think I've omit to say is that BGP is over a LACP with currently just one interface 100 Gbs. I see that the issue is triggered on Cisco when eth interface seems to go in Initializing state: 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel101 is down (No operational members) 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_PARENT_DOWN: Interface port-channel101.2303 is down (Parent interface is down) 2024 Feb 9 16:39:36 NEXUS1 %BGP-5-ADJCHANGE: bgp- [xxx] (xxx) neighbor 172.16.6.17 Down - sent: other configuration change 2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-FOP_CHANGED: port-channel101: first operational port changed from Ethernet1/44 to none 2024 Feb 9 16:39:36 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel101: Ethernet1/44 is down 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_BANDWIDTH_CHANGE: Interface port-channel101,bandwidth changed to 10 Kbit 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface Ethernet1/44 is down (Initializing) 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DOWN_PORT_CHANNEL_MEMBERS_DOWN: Interface port-channel101 is down (No operational members) 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-SPEED: Interface port-channel101, operational speed changed to 100 Gbps 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_DUPLEX: Interface port-channel101, operational duplex mode changed to Full 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_RX_FLOW_CONTROL: Interface port-channel101, operational Receive Flow Control state changed to off 2024 Feb 9 16:39:36 NEXUS1 %ETHPORT-5-IF_TX_FLOW_CONTROL: Interface port-channel101, operational Transmit Flow Control state changed to off 2024 Feb 9 16:39:39 NEXUS1 %ETH_PORT_CHANNEL-5-PORT_UP: port-channel101: Ethernet1/44 is up 2024 Feb 9 16:39:39 NEXUS1 %ETH_PORT_CHANNEL-5-FOP_CHANGED: port-channel101: first operational port changed from none to Ethernet1/44 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_BANDWIDTH_CHANGE: Interface port-channel101,bandwidth changed to 1 Kbit 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_UP: Interface Ethernet1/44 is up in Layer3 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_UP: Interface port-channel101 is up in Layer3 2024 Feb 9 16:39:39 NEXUS1 %ETHPORT-5-IF_UP: Interface port-channel101.2303 is up in Layer3 2024 Feb 9 16:39:43 NEXUS1 %BGP-5-ADJCHANGE: bgp- [xxx] (xxx) neighbor 172.16.6.17 Up Cheers James Il giorno dom 11 feb 2024 alle ore 11:12 Gert Doering ha scritto: > Hi, > > On Sun, Feb 11, 2024 at 11:08:29AM +0100, james list via cisco-nsp wrote: > > we notice BGP flaps > > Any particular error message? BGP flaps can happen due to many different > reasons, and usually $C is fairly good at logging the reason. > > Any interface errors, packet errors, ping packets lost? > > "BGP flaps" *can* be related to lower layer issues (so: interface counters, > error counters, extended pings) or to something unrelated, like "MaxPfx > exceeded"... > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Can it be DC1 is connecting links over an intermediary patch panel and you face fibre disturbance? That may be eliminated if your interfaces on DC1 links do not go down On Sun, Feb 11, 2024, 21:16 Igor Sukhomlinov via cisco-nsp < cisco-nsp@puck.nether.net> wrote: > Hi James, > > Do you happen to run the same software on all nexuses and all MXes? > Do the DC1 and DC2 bgp session exchange the same amount of routing updates > across the links? > > > On Sun, Feb 11, 2024, 21:09 james list via cisco-nsp < > cisco-nsp@puck.nether.net> wrote: > > > Dear experts > > we have a couple of BGP peers over a 100 Gbs interconnection between > > Juniper (MX10003) and Cisco (Nexus N9K-C9364C) in two different > datacenters > > like this: > > > > DC1 > > MX1 -- bgp -- NEXUS1 > > MX2 -- bgp -- NEXUS2 > > > > DC2 > > MX3 -- bgp -- NEXUS3 > > MX4 -- bgp -- NEXUS4 > > > > The issue we see is that sporadically (ie every 1 to 3 days) we notice > BGP > > flaps only in DC1 on both interconnections (not at the same time), there > is > > still no traffic since once noticed the flaps we have blocked deploy on > > production. > > > > We've already changed SPF (we moved the ones from DC2 to DC1 and > viceversa) > > and cables on both the interconnetion at DC1 without any solution. > > > > SFP we use in both DCs: > > > > Juniper - QSFP-100G-SR4-T2 > > Cisco - QSFP-100G-SR4 > > > > over MPO cable OM4. > > > > Distance is DC1 70 mt and DC2 80 mt, hence is less where we see the > issue. > > > > Any idea or suggestion what to check or to do ? > > > > Thanks in advance > > Cheers > > James > > _______ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Open JTAC and CTAC cases. The amount of information provided is wildly insufficient. 'BGP flaps' what does that mean, is it always the same direction? If so, which direction thinks it's not seeing keepalives? Do you also observe loss in 'ping' between the links during the period? Purely stabbing in the dark, I'd say you always observe it in a single direction, because in that direction you are losing reliably every nTh keepalive, and statistically it takes 1-3 days to lose 3 in a row, with the probability you're seeing. Now why exactly is this, is one end not sending to wire or is one end not receiving from wire. Again stabbing in the dark, more likely that problem is in the punt path, rather than inject path, so I would focus my investigation on the party who is tearing down the session, due to lack of keepalive, on thesis this device has problem in punt path and is for some reason dropping at reliable probability BGP packets from the wire. On Sun, 11 Feb 2024 at 12:09, james list via juniper-nsp wrote: > > Dear experts > we have a couple of BGP peers over a 100 Gbs interconnection between > Juniper (MX10003) and Cisco (Nexus N9K-C9364C) in two different datacenters > like this: > > DC1 > MX1 -- bgp -- NEXUS1 > MX2 -- bgp -- NEXUS2 > > DC2 > MX3 -- bgp -- NEXUS3 > MX4 -- bgp -- NEXUS4 > > The issue we see is that sporadically (ie every 1 to 3 days) we notice BGP > flaps only in DC1 on both interconnections (not at the same time), there is > still no traffic since once noticed the flaps we have blocked deploy on > production. > > We've already changed SPF (we moved the ones from DC2 to DC1 and viceversa) > and cables on both the interconnetion at DC1 without any solution. > > SFP we use in both DCs: > > Juniper - QSFP-100G-SR4-T2 > Cisco - QSFP-100G-SR4 > > over MPO cable OM4. > > Distance is DC1 70 mt and DC2 80 mt, hence is less where we see the issue. > > Any idea or suggestion what to check or to do ? > > Thanks in advance > Cheers > James > ___ > juniper-nsp mailing list juniper-...@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Hi James, Do you happen to run the same software on all nexuses and all MXes? Do the DC1 and DC2 bgp session exchange the same amount of routing updates across the links? On Sun, Feb 11, 2024, 21:09 james list via cisco-nsp < cisco-nsp@puck.nether.net> wrote: > Dear experts > we have a couple of BGP peers over a 100 Gbs interconnection between > Juniper (MX10003) and Cisco (Nexus N9K-C9364C) in two different datacenters > like this: > > DC1 > MX1 -- bgp -- NEXUS1 > MX2 -- bgp -- NEXUS2 > > DC2 > MX3 -- bgp -- NEXUS3 > MX4 -- bgp -- NEXUS4 > > The issue we see is that sporadically (ie every 1 to 3 days) we notice BGP > flaps only in DC1 on both interconnections (not at the same time), there is > still no traffic since once noticed the flaps we have blocked deploy on > production. > > We've already changed SPF (we moved the ones from DC2 to DC1 and viceversa) > and cables on both the interconnetion at DC1 without any solution. > > SFP we use in both DCs: > > Juniper - QSFP-100G-SR4-T2 > Cisco - QSFP-100G-SR4 > > over MPO cable OM4. > > Distance is DC1 70 mt and DC2 80 mt, hence is less where we see the issue. > > Any idea or suggestion what to check or to do ? > > Thanks in advance > Cheers > James > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Stange issue on 100 Gbs interconnection Juniper - Cisco
Dear experts we have a couple of BGP peers over a 100 Gbs interconnection between Juniper (MX10003) and Cisco (Nexus N9K-C9364C) in two different datacenters like this: DC1 MX1 -- bgp -- NEXUS1 MX2 -- bgp -- NEXUS2 DC2 MX3 -- bgp -- NEXUS3 MX4 -- bgp -- NEXUS4 The issue we see is that sporadically (ie every 1 to 3 days) we notice BGP flaps only in DC1 on both interconnections (not at the same time), there is still no traffic since once noticed the flaps we have blocked deploy on production. We've already changed SPF (we moved the ones from DC2 to DC1 and viceversa) and cables on both the interconnetion at DC1 without any solution. SFP we use in both DCs: Juniper - QSFP-100G-SR4-T2 Cisco - QSFP-100G-SR4 over MPO cable OM4. Distance is DC1 70 mt and DC2 80 mt, hence is less where we see the issue. Any idea or suggestion what to check or to do ? Thanks in advance Cheers James ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [External] Re: Support for CFP2
Hi Rob, Sorry for the delay, yes, SO use Cisco Acacia QDD Bright 400ZR+ and DCP-404 also seems to support Cisco Acacia 100G QDD DWDM pluggable. I'm unsure about the 100G QDD DWDM spec and price, but Bright 400ZR+ can definitely cover that distance at 200G and 100G within 50 GHz. Best Regards Ted > On 25 Jan 2024, at 00:27, Rob Evans wrote: > > Hi, >> That product looks rather old; why not use Smartoptics DCP-404 instead? And >> it's QDD based too, for the day when you want to move the QDD pluggable into >> the router instead. > > Yeah, as I mentioned, there may be alternatives. Noting that the OP wanted a > range of 800km+, do SO also offer a suitable pluggable for the line-side? > The ones I could see from a cursory glance appear to be dispersion limited to > 450km at 50GHz, or need 100GHz. > > Cheers, > Rob > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [External] Re: Support for CFP2
Rob Evans via cisco-nsp wrote on 24/01/2024 23:27: Yeah, as I mentioned, there may be alternatives. Noting that the OP wanted a range of 800km+, do SO also offer a suitable pluggable for the line-side? The ones I could see from a cursory glance appear to be dispersion limited to 450km at 50GHz, or need 100GHz. oh duh, I missed the 800km+ requirement bit. This is definitely the sort of area where for ease of implementation / longer-term support, getting an off-the-shelf 100G transport device would be useful. A DCI / transponder solution here would leave local hand-off to short-haul optics (lr4 / sr4 / aoc), which abstracts all the complexity / transceiver cost / etc away from any L3 device. The OP would also need to figure out what's happening with regen in the middle. Is this OEO or optical-only amplification? Link characterisation becomes a thing once you're outside short-haul / metro connectivity. Obviously this isn't to say that you can't do long haul on alien waves - you certainly can. But I wouldn't like to get involved when something goes wrong and everyone starts finger-pointing at everyone else about whose kit is acting the maggot. Strategically it's usually simpler to abstract off potentially complex areas like this into their own self-contained box which can be managed as a discrete unit. Once you factor in the cost of managing complexity, it's usually no more expensive and often less. All the more so in cases where the A and B ends of a link are different organisations. There are plenty of market options for this. An internet search for "long haul dci" will give manufacturer names. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Local switching on EVPN port
Yes, I am trying to provision some new EVPN services while keeping the existing bridge-domains for local switching between vlans in place. On 02/02/2024 13:11, Catalin Dominte wrote: Are you trying to migrate to EVPN? What are you trying to achieve? :) Catalin *From:* cisco-nsp on behalf of Mihai via cisco-nsp *Sent:* Friday, February 2, 2024 1:05:12 PM *To:* cisco-nsp@puck.nether.net *Subject:* [c-nsp] Local switching on EVPN port Hi, On Cisco NCS I can configure local switching between two subinterfaces/vlans by adding them to a bridge domain as below: l2vpn bridge group X bridge-domain X interface Bundle-Ether1.10 l2vpn bridge group X bridge-domain X interface Bundle-Ether1.20 Once I enable EVPN on the physical interface/bundle the local switching no longer works. I kinda understand why it wouldn't work with EVPN but is there some knob that I can enable in order to preserve the functionality? Thanks! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp <https://puck.nether.net/mailman/listinfo/cisco-nsp> archive at http://puck.nether.net/pipermail/cisco-nsp/ <http://puck.nether.net/pipermail/cisco-nsp/> ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Local switching on EVPN port
Are you trying to migrate to EVPN? What are you trying to achieve? :) Catalin From: cisco-nsp on behalf of Mihai via cisco-nsp Sent: Friday, February 2, 2024 1:05:12 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Local switching on EVPN port Hi, On Cisco NCS I can configure local switching between two subinterfaces/vlans by adding them to a bridge domain as below: l2vpn bridge group X bridge-domain X interface Bundle-Ether1.10 l2vpn bridge group X bridge-domain X interface Bundle-Ether1.20 Once I enable EVPN on the physical interface/bundle the local switching no longer works. I kinda understand why it wouldn't work with EVPN but is there some knob that I can enable in order to preserve the functionality? Thanks! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Local switching on EVPN port
Hi, On Cisco NCS I can configure local switching between two subinterfaces/vlans by adding them to a bridge domain as below: l2vpn bridge group X bridge-domain X interface Bundle-Ether1.10 l2vpn bridge group X bridge-domain X interface Bundle-Ether1.20 Once I enable EVPN on the physical interface/bundle the local switching no longer works. I kinda understand why it wouldn't work with EVPN but is there some knob that I can enable in order to preserve the functionality? Thanks! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Acceptable port configurations for ASR 9902 (gripe)
Drew Weaver wrote on 31/01/2024 14:12: I know it is not the same but if it can do 1x100GE,1x100GE,1x100GE,1x100GE it would sort of follow that it can do 1x100GE,1x100GE,1x100GE,10x10GE tbh this will depend on the hardware and how the gearboxes are set up. For example if you had a single ASIC/NPU with 400G forwarding capacity split out into 2x200G, with two gearboxes available on the two southbound paths, that might give you one of: 4x100G (i.e. gearboxes bypassed and 4 separate 100G ports directly connected to the ASIC/NPU), or 2x100G + one gearbox activated / taking all the traffic. The gearbox traffic could then be split out into various combinations of lower speed ports. But because you now have a breakout south of the gearbox, the architecture no longer has the physical capability to provide native 100G ports. Oops. This isn't necessarily an explanation of what the ASR 9902 is actually doing - it's just an example of how gearbox implementations can lead to unexpected outcomes. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Acceptable port configurations for ASR 9902 (gripe)
I know it is not the same but if it can do 1x100GE,1x100GE,1x100GE,1x100GE it would sort of follow that it can do 1x100GE,1x100GE,1x100GE,10x10GE I can't really imagine a way that the underlying line card could be attached to the 'switch' whereby it wouldn't allow this given what it already does allow. If the slices didn’t have the possibility of failing independently of one another this would matter slightly less as one could configure slice0 as 1x100GE x4 and slice1 as 2x100GE +10x10+10x10 but since the slices can indeed fail independently it seems like a good idea to port-channel one port from each slice for each 'service'. That is just my opinion though. Thanks, -Drew -Original Message- From: Nick Hilliard Sent: Wednesday, January 31, 2024 9:06 AM To: Drew Weaver Cc: 'cisco-nsp@puck.nether.net' Subject: Re: [c-nsp] Acceptable port configurations for ASR 9902 (gripe) Drew Weaver via cisco-nsp wrote on 31/01/2024 14:00: > So having a 1x100GE,1x100GE,4x25GE,10x10GE option and not a > 1x100GE,1x100GE,1x100GE,10x10GE option is just... laziness I guess is > how I would describe it. 4x25G is not the same as 1x100G - sounds like there's some weird gearbox stuff going on under the surface. It would be interesting to see a technical description of why this restriction exists. Nick _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Acceptable port configurations for ASR 9902 (gripe)
Drew Weaver via cisco-nsp wrote on 31/01/2024 14:00: So having a 1x100GE,1x100GE,4x25GE,10x10GE option and not a 1x100GE,1x100GE,1x100GE,10x10GE option is just... laziness I guess is how I would describe it. 4x25G is not the same as 1x100G - sounds like there's some weird gearbox stuff going on under the surface. It would be interesting to see a technical description of why this restriction exists. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Acceptable port configurations for ASR 9902 (gripe)
Yes, my point was that there is no reason for it to be limited that way. You can do 1x100GE,1x100GE,1x100GE,1x100GE So having a 1x100GE,1x100GE,4x25GE,10x10GE option and not a 1x100GE,1x100GE,1x100GE,10x10GE option is just... laziness I guess is how I would describe it. Actually if it were up to me I would've made all of the ports on the ASR9902 available for use but bandwidth not to exceed 800Gbps total. But that is just me. -Original Message- From: cisco-nsp On Behalf Of Hank Nussbacher via cisco-nsp Sent: Saturday, January 27, 2024 2:57 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Acceptable port configurations for ASR 9902 (gripe) On 26/01/2024 15:49, Drew Weaver via cisco-nsp wrote: > Hello, > > I just have a general gripe that I want to share regarding the ASR9902 and > since there is nobody to talk to at Cisco about any of this anymore, I > figured I would just share it here. > > This is an acceptable configuration: > > 1x100GE, 1x100GE, 4x25GE, 10x10GE > > But this is not: > > 1x100GE, 1x100GE, 1x100GE,10x10GE > > Think about that for a moment. Same story for any dual rate card: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_td_docs_iosxr_asr9000_hardware-2Dinstall_ethernet-2Dline-2Dcard-2Dinstallation-2Dguide_b-2Dasr9k-2Dethernt-2Dline-2Dcard-2Dinstall-2Dguide_b-2Dasr9k-2Dethernt-2Dline-2Dcard-2Dinstall-2Dguide-5Fchapter-5F010.html-23id-5F45620=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=QR5dAmTfAD0u9G0mkSLzfRyw-2Ee6Bci75XxGFHaMznfnfwXDddkjM-t3jv1fzKD=xcH5dL4b5ux5WnhblARjWBAfYMpSGld5twtyI4E7h4o= :-( -Hank > > Thanks, > -Drew > > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_m > ailman_listinfo_cisco-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A > _CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=QR5dAmTfA > D0u9G0mkSLzfRyw-2Ee6Bci75XxGFHaMznfnfwXDddkjM-t3jv1fzKD=LvxZ2GtlT_ws > oixslQD3glKXFeNwmmvw_Lz0pg0zFjY= > archive at > https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pi > permail_cisco-2Dnsp_=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnV > fiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=QR5dAmTfAD0u9G0m > kSLzfRyw-2Ee6Bci75XxGFHaMznfnfwXDddkjM-t3jv1fzKD=xwhvYRBk6MqAOgFWPRu > 9pG3gQiiESaHe7EjhePKC1RA= ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=QR5dAmTfAD0u9G0mkSLzfRyw-2Ee6Bci75XxGFHaMznfnfwXDddkjM-t3jv1fzKD=LvxZ2GtlT_wsoixslQD3glKXFeNwmmvw_Lz0pg0zFjY= archive at https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=QR5dAmTfAD0u9G0mkSLzfRyw-2Ee6Bci75XxGFHaMznfnfwXDddkjM-t3jv1fzKD=xwhvYRBk6MqAOgFWPRu9pG3gQiiESaHe7EjhePKC1RA= ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Acceptable port configurations for ASR 9902 (gripe)
On 26/01/2024 15:49, Drew Weaver via cisco-nsp wrote: Hello, I just have a general gripe that I want to share regarding the ASR9902 and since there is nobody to talk to at Cisco about any of this anymore, I figured I would just share it here. This is an acceptable configuration: 1x100GE, 1x100GE, 4x25GE, 10x10GE But this is not: 1x100GE, 1x100GE, 1x100GE,10x10GE Think about that for a moment. Same story for any dual rate card: https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/hardware-install/ethernet-line-card-installation-guide/b-asr9k-ethernt-line-card-install-guide/b-asr9k-ethernt-line-card-install-guide_chapter_010.html#id_45620 :-( -Hank Thanks, -Drew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Acceptable port configurations for ASR 9902 (gripe)
Hello, I just have a general gripe that I want to share regarding the ASR9902 and since there is nobody to talk to at Cisco about any of this anymore, I figured I would just share it here. This is an acceptable configuration: 1x100GE, 1x100GE, 4x25GE, 10x10GE But this is not: 1x100GE, 1x100GE, 1x100GE,10x10GE Think about that for a moment. Thanks, -Drew ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [External] Re: Support for CFP2
Hi, That product looks rather old; why not use Smartoptics DCP-404 instead? > And it's QDD based too, for the day when you want to move the QDD pluggable > into the router instead. > Yeah, as I mentioned, there may be alternatives. Noting that the OP wanted a range of 800km+, do SO also offer a suitable pluggable for the line-side? The ones I could see from a cursory glance appear to be dispersion limited to 450km at 50GHz, or need 100GHz. Cheers, Rob _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [External] Re: Support for CFP2
Thanks -- I was looking at that exact box earlier today and have sent them a request for more information. In a perfect world I'd like to keep it as simple as possible, but I also want to get this project moving and get things turned up, so other options are greatly appreciated. Shawn On Wed, Jan 24, 2024 at 12:57 PM Rob Evans wrote: > ...and I've just re-read that you were looking for what you could use. > > There's something like this: > > https://www.packetlight.com/products/100g-200g-dwdm-transport/200g-single-wavelength-muxponder > > I've no personal experience of it, and there may be other similar > products on the market, but that looks like it could have a > 100GBASE-LR4 uplink to your router, and a CFP2-ACO transceiver facing > the provider. > > Rob > > On Wed, 24 Jan 2024 at 17:50, Rob Evans wrote: > > > > It sounds as though your provider is suggesting a CFP2-DCO, such as > > one of these: > > > https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/datasheet-c78-743732.html > > > > They're giving you a specification that includes the entire C band > > (4.8THz), but stating that your wavelength must fit within 50GHz, > > which is a traditional ITU-T channel width for DWDM systems, so they > > should probably also specify which channel you're going to use. > > > > CFP2-DCOs tend to work because they've got the space and power for the > > DSPs, and it has been difficult to cram that into QSFP28s (coherent > > optics requires a lot of signal processing). As you've already noted, > > there are products in the pipeline, but I'm not aware of any that are > > widely supported yet. Cisco do seem to suggest there is a QSFP-DD > > using QPSK for 100G, but I've not looked too closely at it (and note > > that QSFP-DD is different to QSFP28, having about three times the > > electrical power available): > > > https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/datasheet-c78-744377.html > > > > Cheers, > > Rob > > > > On Tue, 23 Jan 2024 at 19:54, Shawn L via cisco-nsp > > wrote: > > > > > > Thanks - we don't really understand the intricacies either. This is > our > > > first adventure in this area. > > > > > > The distances are quite large (800+ Km). It's a dark wave service, > though > > > we don't have to worry about anything in the middle, just the 2 end > points. > > > > > > I'm told Adva / Adtran will be releasing a ZR+ 0dBm QSFP28 that would > (or > > > should) work in Q2 2024, but I'm looking for other options. I did > check > > > out FS.com, but they're telling me the only option they have available > uses > > > a 200Gig CFP2 and 2 100gig QSFP28s. > > > > > > Any idea where else we might look? We'd be happy to engage someone to > help > > > us design a solution, we're just not sure where to turn. > > > > > > Shawn > > > > > > On Fri, Jan 19, 2024 at 1:25 PM Hunter Fuller wrote: > > > > > > > I know when we are talking about DWDM my usual expectation these days > > > > is to use a "0km optic" (aka one that is meant to launch just far > > > > enough to make it into an amp)... so one of those (from anyone, e.g. > > > > fs.com, whatever) followed by an amp might be doable? I would advise > > > > you to contract someone to work that out though (I myself don't even > > > > fully understand the intricacies). > > > > > > > > the point of the 0km optic is that it fits in QSFP+ generally. It's a > > > > lot to ask, to get a precisely tuned DWDM wave coming out of a lil > > > > QSFP+ at ZR levels. > > > > > > > > The other option of course being to send it LR and then use a > > > > transponder closer to the DWDM gear, as Nick suggested. > > > > > > > > -- > > > > Hunter Fuller (they) > > > > Router Jockey > > > > VBH M-1C > > > > +1 256 824 5331 > > > > > > > > Office of Information Technology > > > > The University of Alabama in Huntsville > > > > Network Engineering > > > > > > > > On Fri, Jan 19, 2024 at 9:07 AM Nick Hilliard via cisco-nsp > > > > wrote: > > > > > > > > > > Shawn L via cisco-nsp wrote on 19/01/2024 14:58: > > > > > > The pluggable optic must be DWDM 1530 to 1563 nm with QPSK > modulation > > > > that > > > > > > fits 50Ghz (
Re: [c-nsp] [External] Re: Support for CFP2
...and I've just re-read that you were looking for what you could use. There's something like this: https://www.packetlight.com/products/100g-200g-dwdm-transport/200g-single-wavelength-muxponder I've no personal experience of it, and there may be other similar products on the market, but that looks like it could have a 100GBASE-LR4 uplink to your router, and a CFP2-ACO transceiver facing the provider. Rob On Wed, 24 Jan 2024 at 17:50, Rob Evans wrote: > > It sounds as though your provider is suggesting a CFP2-DCO, such as > one of these: > https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/datasheet-c78-743732.html > > They're giving you a specification that includes the entire C band > (4.8THz), but stating that your wavelength must fit within 50GHz, > which is a traditional ITU-T channel width for DWDM systems, so they > should probably also specify which channel you're going to use. > > CFP2-DCOs tend to work because they've got the space and power for the > DSPs, and it has been difficult to cram that into QSFP28s (coherent > optics requires a lot of signal processing). As you've already noted, > there are products in the pipeline, but I'm not aware of any that are > widely supported yet. Cisco do seem to suggest there is a QSFP-DD > using QPSK for 100G, but I've not looked too closely at it (and note > that QSFP-DD is different to QSFP28, having about three times the > electrical power available): > https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/datasheet-c78-744377.html > > Cheers, > Rob > > On Tue, 23 Jan 2024 at 19:54, Shawn L via cisco-nsp > wrote: > > > > Thanks - we don't really understand the intricacies either. This is our > > first adventure in this area. > > > > The distances are quite large (800+ Km). It's a dark wave service, though > > we don't have to worry about anything in the middle, just the 2 end points. > > > > I'm told Adva / Adtran will be releasing a ZR+ 0dBm QSFP28 that would (or > > should) work in Q2 2024, but I'm looking for other options. I did check > > out FS.com, but they're telling me the only option they have available uses > > a 200Gig CFP2 and 2 100gig QSFP28s. > > > > Any idea where else we might look? We'd be happy to engage someone to help > > us design a solution, we're just not sure where to turn. > > > > Shawn > > > > On Fri, Jan 19, 2024 at 1:25 PM Hunter Fuller wrote: > > > > > I know when we are talking about DWDM my usual expectation these days > > > is to use a "0km optic" (aka one that is meant to launch just far > > > enough to make it into an amp)... so one of those (from anyone, e.g. > > > fs.com, whatever) followed by an amp might be doable? I would advise > > > you to contract someone to work that out though (I myself don't even > > > fully understand the intricacies). > > > > > > the point of the 0km optic is that it fits in QSFP+ generally. It's a > > > lot to ask, to get a precisely tuned DWDM wave coming out of a lil > > > QSFP+ at ZR levels. > > > > > > The other option of course being to send it LR and then use a > > > transponder closer to the DWDM gear, as Nick suggested. > > > > > > -- > > > Hunter Fuller (they) > > > Router Jockey > > > VBH M-1C > > > +1 256 824 5331 > > > > > > Office of Information Technology > > > The University of Alabama in Huntsville > > > Network Engineering > > > > > > On Fri, Jan 19, 2024 at 9:07 AM Nick Hilliard via cisco-nsp > > > wrote: > > > > > > > > Shawn L via cisco-nsp wrote on 19/01/2024 14:58: > > > > > The pluggable optic must be DWDM 1530 to 1563 nm with QPSK modulation > > > that > > > > > fits 50Ghz (~31 to 35Gbaud) and a launch power of ZR+ 0dBm. The > > > customer > > > > > channel should have Rx: Max <-10 dBm/Ch and Tx: Min: >–5 dBm/Ch to > > > Max: <+ > > > > > 6.5dBm/Ch in order to meet the GOSNR margin of 2.5dBm or more. > > > > > > > > right, so DWDM alien wave requirement then. That's very non-portable and > > > > kit specific. > > > > > > > > Depending on the application, you might be better off ditching the > > > > requirements that they're imposing and simply using 100G transponders > > > > (i.e. 100G as a service). Or something like the smartoptics open line > > > > system with PAM4 QSFP28 transceivers. > > > > > > > > It really depen
Re: [c-nsp] [External] Re: Support for CFP2
It sounds as though your provider is suggesting a CFP2-DCO, such as one of these: https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/datasheet-c78-743732.html They're giving you a specification that includes the entire C band (4.8THz), but stating that your wavelength must fit within 50GHz, which is a traditional ITU-T channel width for DWDM systems, so they should probably also specify which channel you're going to use. CFP2-DCOs tend to work because they've got the space and power for the DSPs, and it has been difficult to cram that into QSFP28s (coherent optics requires a lot of signal processing). As you've already noted, there are products in the pipeline, but I'm not aware of any that are widely supported yet. Cisco do seem to suggest there is a QSFP-DD using QPSK for 100G, but I've not looked too closely at it (and note that QSFP-DD is different to QSFP28, having about three times the electrical power available): https://www.cisco.com/c/en/us/products/collateral/interfaces-modules/transceiver-modules/datasheet-c78-744377.html Cheers, Rob On Tue, 23 Jan 2024 at 19:54, Shawn L via cisco-nsp wrote: > > Thanks - we don't really understand the intricacies either. This is our > first adventure in this area. > > The distances are quite large (800+ Km). It's a dark wave service, though > we don't have to worry about anything in the middle, just the 2 end points. > > I'm told Adva / Adtran will be releasing a ZR+ 0dBm QSFP28 that would (or > should) work in Q2 2024, but I'm looking for other options. I did check > out FS.com, but they're telling me the only option they have available uses > a 200Gig CFP2 and 2 100gig QSFP28s. > > Any idea where else we might look? We'd be happy to engage someone to help > us design a solution, we're just not sure where to turn. > > Shawn > > On Fri, Jan 19, 2024 at 1:25 PM Hunter Fuller wrote: > > > I know when we are talking about DWDM my usual expectation these days > > is to use a "0km optic" (aka one that is meant to launch just far > > enough to make it into an amp)... so one of those (from anyone, e.g. > > fs.com, whatever) followed by an amp might be doable? I would advise > > you to contract someone to work that out though (I myself don't even > > fully understand the intricacies). > > > > the point of the 0km optic is that it fits in QSFP+ generally. It's a > > lot to ask, to get a precisely tuned DWDM wave coming out of a lil > > QSFP+ at ZR levels. > > > > The other option of course being to send it LR and then use a > > transponder closer to the DWDM gear, as Nick suggested. > > > > -- > > Hunter Fuller (they) > > Router Jockey > > VBH M-1C > > +1 256 824 5331 > > > > Office of Information Technology > > The University of Alabama in Huntsville > > Network Engineering > > > > On Fri, Jan 19, 2024 at 9:07 AM Nick Hilliard via cisco-nsp > > wrote: > > > > > > Shawn L via cisco-nsp wrote on 19/01/2024 14:58: > > > > The pluggable optic must be DWDM 1530 to 1563 nm with QPSK modulation > > that > > > > fits 50Ghz (~31 to 35Gbaud) and a launch power of ZR+ 0dBm. The > > customer > > > > channel should have Rx: Max <-10 dBm/Ch and Tx: Min: >–5 dBm/Ch to > > Max: <+ > > > > 6.5dBm/Ch in order to meet the GOSNR margin of 2.5dBm or more. > > > > > > right, so DWDM alien wave requirement then. That's very non-portable and > > > kit specific. > > > > > > Depending on the application, you might be better off ditching the > > > requirements that they're imposing and simply using 100G transponders > > > (i.e. 100G as a service). Or something like the smartoptics open line > > > system with PAM4 QSFP28 transceivers. > > > > > > It really depends on what's between you and the other end. D/F has > > > simple options open for single 100G. If you're connecting into something > > > more complicated, it can get messy and expensive. > > > > > > Nick > > > _______ > > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [External] Re: Support for CFP2
Thanks - we don't really understand the intricacies either. This is our first adventure in this area. The distances are quite large (800+ Km). It's a dark wave service, though we don't have to worry about anything in the middle, just the 2 end points. I'm told Adva / Adtran will be releasing a ZR+ 0dBm QSFP28 that would (or should) work in Q2 2024, but I'm looking for other options. I did check out FS.com, but they're telling me the only option they have available uses a 200Gig CFP2 and 2 100gig QSFP28s. Any idea where else we might look? We'd be happy to engage someone to help us design a solution, we're just not sure where to turn. Shawn On Fri, Jan 19, 2024 at 1:25 PM Hunter Fuller wrote: > I know when we are talking about DWDM my usual expectation these days > is to use a "0km optic" (aka one that is meant to launch just far > enough to make it into an amp)... so one of those (from anyone, e.g. > fs.com, whatever) followed by an amp might be doable? I would advise > you to contract someone to work that out though (I myself don't even > fully understand the intricacies). > > the point of the 0km optic is that it fits in QSFP+ generally. It's a > lot to ask, to get a precisely tuned DWDM wave coming out of a lil > QSFP+ at ZR levels. > > The other option of course being to send it LR and then use a > transponder closer to the DWDM gear, as Nick suggested. > > -- > Hunter Fuller (they) > Router Jockey > VBH M-1C > +1 256 824 5331 > > Office of Information Technology > The University of Alabama in Huntsville > Network Engineering > > On Fri, Jan 19, 2024 at 9:07 AM Nick Hilliard via cisco-nsp > wrote: > > > > Shawn L via cisco-nsp wrote on 19/01/2024 14:58: > > > The pluggable optic must be DWDM 1530 to 1563 nm with QPSK modulation > that > > > fits 50Ghz (~31 to 35Gbaud) and a launch power of ZR+ 0dBm. The > customer > > > channel should have Rx: Max <-10 dBm/Ch and Tx: Min: >–5 dBm/Ch to > Max: <+ > > > 6.5dBm/Ch in order to meet the GOSNR margin of 2.5dBm or more. > > > > right, so DWDM alien wave requirement then. That's very non-portable and > > kit specific. > > > > Depending on the application, you might be better off ditching the > > requirements that they're imposing and simply using 100G transponders > > (i.e. 100G as a service). Or something like the smartoptics open line > > system with PAM4 QSFP28 transceivers. > > > > It really depends on what's between you and the other end. D/F has > > simple options open for single 100G. If you're connecting into something > > more complicated, it can get messy and expensive. > > > > Nick > > _______ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS-XR unsuppressed map BGP
Hello TP is the below what you are looking for? P4-P5 (IOS-IOSXR). route-policy BGP unsuppress-route end-policy router bgp 5 address-family ipv4 unicast network 192.168.64.0/24 network 192.168.65.0/24 aggregate-address 192.168.64.0/23 summary-only ! neighbor 10.1.45.4 remote-as 4 address-family ipv4 unicast route-policy ALLOW in route-policy BGP out P4#show ip bgp BGP table version is 8, local router ID is 10.1.100.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next HopMetric LocPrf Weight Path *> 192.168.64.0 10.1.45.50 0 5 i *> 192.168.64.0/23 10.1.45.5 0 5 i *> 192.168.65.0 10.1.45.50 0 5 i ____ From: cisco-nsp on behalf of Harold Ritter (hritter) via cisco-nsp Sent: Sunday, January 21, 2024 8:31 PM To: Toje TJ ; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] IOS-XR unsuppressed map BGP Hi TP, In XR, this would be done through RPL. Please refer to the “unsuppress-route” attribute in the following configuration guide: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-7/configuration/guide/b-routing-cg-asr9000-77x/implementing-routing-policy.html Regards, Harold De : cisco-nsp de la part de Toje TJ via cisco-nsp Date : samedi, 20 janvier 2024 à 08:28 À : cisco-nsp@puck.nether.net Objet : [c-nsp] IOS-XR unsuppressed map BGP Good day,. Apologize if I ask the wrong question or anything, I just wondering how to configure an unsuppressed map in iox-xr for BGP aggregate with summary-only, hence I tried to google but was unable to find any good sample. I am doing this for my lab, thank you so much for answering this question. Regards. TP ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS-XR unsuppressed map BGP
Hi TP, In XR, this would be done through RPL. Please refer to the “unsuppress-route” attribute in the following configuration guide: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-7/configuration/guide/b-routing-cg-asr9000-77x/implementing-routing-policy.html Regards, Harold De : cisco-nsp de la part de Toje TJ via cisco-nsp Date : samedi, 20 janvier 2024 à 08:28 À : cisco-nsp@puck.nether.net Objet : [c-nsp] IOS-XR unsuppressed map BGP Good day,. Apologize if I ask the wrong question or anything, I just wondering how to configure an unsuppressed map in iox-xr for BGP aggregate with summary-only, hence I tried to google but was unable to find any good sample. I am doing this for my lab, thank you so much for answering this question. Regards. TP ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9000 QoS counters on LAG
On Jun, 21 Jan 2024 at 03:17, Ross Halliday wrote: > Moving to qos-group for egress classes got me the result I was looking for. > Thank you very much! I'm happy that you got the results you wanted, but that shouldn't have fixed it. The 'priority level 3' is the only thing that I can think of which might cause it to fail to program. Just to continue on the priority level, if you set it on ingress, it'll still carry the values on egress. But you receive a lot more protection, because you ensure that fabric isn't being congested by less important traffic, causing more important traffic to drop during fabric congestion. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9000 QoS counters on LAG
Moving to qos-group for egress classes got me the result I was looking for. Thank you very much! Cheers Ross -Original Message- From: cisco-nsp On Behalf Of Ross Halliday via cisco-nsp Sent: Saturday, January 20, 2024 4:44 PM To: Saku Ytti Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR9000 QoS counters on LAG Hi Saku, > Any syslog messages when you attach it? Nope, though I'm quite ignorant as to whether I have the appropriate logging options turned on. > I don't think the device supports 'priority level 3', there is only > default, 2 and 1 . Default being the worst and 1 the best (well in > CLI, in NPU they are reversed to make debugging less boring). > Practically all the utility of priority level has already been used, > by the time egress policy is considered, so they don't much here, you > should set them on ingress. I read that this is very much true for ingress queuing as it applies a priority across the fabric (apparently there's a separate mcast priority too). I believe this card supports four egress queues, which seems to be supported by my earlier failed commit checks! Regardless I would expect *something* to hit the counters, even if half of them are broken, no? > Not related, but I can't help myself, you shouldn't classify and > schedule on egress, you classify on ingress, and schedule/rewrite on > egress. That is 'your match dscp/cos' should be on ingress, with 'set > qos-group N', and on 'egress' you do 'match qos-group N'. Not only > will this separation of concerns make things a lot easier to rationale > and manage, but it's the only way you can do QoS on many other > platforms, so you don't have re-invent policies for different > platforms. Thanks for the tips, I'll have to investigate the use of "qos-group". Thanks Ross ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9000 QoS counters on LAG
Hi Saku, > Any syslog messages when you attach it? Nope, though I'm quite ignorant as to whether I have the appropriate logging options turned on. > I don't think the device supports 'priority level 3', there is only > default, 2 and 1 . Default being the worst and 1 the best (well in > CLI, in NPU they are reversed to make debugging less boring). > Practically all the utility of priority level has already been used, > by the time egress policy is considered, so they don't much here, you > should set them on ingress. I read that this is very much true for ingress queuing as it applies a priority across the fabric (apparently there's a separate mcast priority too). I believe this card supports four egress queues, which seems to be supported by my earlier failed commit checks! Regardless I would expect *something* to hit the counters, even if half of them are broken, no? > Not related, but I can't help myself, you shouldn't classify and > schedule on egress, you classify on ingress, and schedule/rewrite on > egress. That is 'your match dscp/cos' should be on ingress, with 'set > qos-group N', and on 'egress' you do 'match qos-group N'. Not only > will this separation of concerns make things a lot easier to rationale > and manage, but it's the only way you can do QoS on many other > platforms, so you don't have re-invent policies for different > platforms. Thanks for the tips, I'll have to investigate the use of "qos-group". Thanks Ross ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] IOS-XR unsuppressed map BGP
Good day,. Apologize if I ask the wrong question or anything, I just wondering how to configure an unsuppressed map in iox-xr for BGP aggregate with summary-only, hence I tried to google but was unable to find any good sample. I am doing this for my lab, thank you so much for answering this question. Regards. TP ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] C2C ASR9K
Thanks, Harold, for the great insight , actually I missed configuring the /32 route : ) My bad. From: Harold Ritter (hritter) Sent: Friday, January 19, 2024 6:51 PM To: Mohammad Khalil ; cisco-nsp@puck.nether.net Subject: Re: C2C ASR9K Hi Mohammad, XR requires the PE to have a /32 route towards the directly connected CE. This will enable MPLS on the interface. PE3: router static vrf CORE address-family ipv4 unicast 172.16.23.2/32 The same thing needs to be done on PE6 towards CE7. One more thing. You should specify the update-source on both CE2 and CE7. For instance on CE2: neighbor 10.1.100.7 update-source lo0 Regards, Harold De : cisco-nsp de la part de Mohammad Khalil via cisco-nsp Date : vendredi, 19 janvier 2024 à 06:00 À : cisco-nsp@puck.nether.net Objet : [c-nsp] C2C ASR9K Greetings I am trying to configure C2C with BGP as the PE-CE routing protocol and Static as the C to CE routing protocol. The main issue am running now is the eBGP session (VPNv4) between the CEs , routes are delivered but there is no connectivity and hence the eBGP session is not coming up. Per my understanding , the BGP should be labelled unicast between the PE (XRV 6.6.2) and the respective CE. Before i changed the BGP session from IPv4 unicast to labeled unicast it was working (CE to CE traffic) , when I moved to the C traffic , I had to change the BGP to labeled unicast. C1 – CE2 – PE3 – P4 – P5 – PE6 – CE7 – C8 PE3: router bgp 100 address-family ipv4 unicast ! address-family vpnv4 unicast ! neighbor 10.1.100.6 remote-as 100 update-source Loopback0 address-family vpnv4 unicast vrf CORE rd 100:1 address-family ipv4 unicast allocate-label all ! neighbor 172.16.23.2 remote-as 10 address-family ipv4 labeled-unicast route-policy ALLOW in route-policy ALLOW out CE2: router bgp 10 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 10.1.100.7 remote-as 7 neighbor 10.1.100.7 ebgp-multihop 5 neighbor 172.16.23.3 remote-as 100 ! address-family ipv4 network 10.1.100.2 mask 255.255.255.255 neighbor 172.16.23.3 activate neighbor 172.16.23.3 send-label exit-address-family ! address-family vpnv4 neighbor 10.1.100.7 activate neighbor 10.1.100.7 send-community extended exit-address-family ! address-family ipv4 vrf CUST redistribute static exit-address-family Nothing on the C except for a default route , is there anything I am missing? LDP is functioning well along the path. Appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [External] Re: Support for CFP2
I know when we are talking about DWDM my usual expectation these days is to use a "0km optic" (aka one that is meant to launch just far enough to make it into an amp)... so one of those (from anyone, e.g. fs.com, whatever) followed by an amp might be doable? I would advise you to contract someone to work that out though (I myself don't even fully understand the intricacies). the point of the 0km optic is that it fits in QSFP+ generally. It's a lot to ask, to get a precisely tuned DWDM wave coming out of a lil QSFP+ at ZR levels. The other option of course being to send it LR and then use a transponder closer to the DWDM gear, as Nick suggested. -- Hunter Fuller (they) Router Jockey VBH M-1C +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Fri, Jan 19, 2024 at 9:07 AM Nick Hilliard via cisco-nsp wrote: > > Shawn L via cisco-nsp wrote on 19/01/2024 14:58: > > The pluggable optic must be DWDM 1530 to 1563 nm with QPSK modulation that > > fits 50Ghz (~31 to 35Gbaud) and a launch power of ZR+ 0dBm. The customer > > channel should have Rx: Max <-10 dBm/Ch and Tx: Min: >–5 dBm/Ch to Max: <+ > > 6.5dBm/Ch in order to meet the GOSNR margin of 2.5dBm or more. > > right, so DWDM alien wave requirement then. That's very non-portable and > kit specific. > > Depending on the application, you might be better off ditching the > requirements that they're imposing and simply using 100G transponders > (i.e. 100G as a service). Or something like the smartoptics open line > system with PAM4 QSFP28 transceivers. > > It really depends on what's between you and the other end. D/F has > simple options open for single 100G. If you're connecting into something > more complicated, it can get messy and expensive. > > Nick > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] C2C ASR9K
Hi Mohammad, XR requires the PE to have a /32 route towards the directly connected CE. This will enable MPLS on the interface. PE3: router static vrf CORE address-family ipv4 unicast 172.16.23.2/32 The same thing needs to be done on PE6 towards CE7. One more thing. You should specify the update-source on both CE2 and CE7. For instance on CE2: neighbor 10.1.100.7 update-source lo0 Regards, Harold De : cisco-nsp de la part de Mohammad Khalil via cisco-nsp Date : vendredi, 19 janvier 2024 à 06:00 À : cisco-nsp@puck.nether.net Objet : [c-nsp] C2C ASR9K Greetings I am trying to configure C2C with BGP as the PE-CE routing protocol and Static as the C to CE routing protocol. The main issue am running now is the eBGP session (VPNv4) between the CEs , routes are delivered but there is no connectivity and hence the eBGP session is not coming up. Per my understanding , the BGP should be labelled unicast between the PE (XRV 6.6.2) and the respective CE. Before i changed the BGP session from IPv4 unicast to labeled unicast it was working (CE to CE traffic) , when I moved to the C traffic , I had to change the BGP to labeled unicast. C1 – CE2 – PE3 – P4 – P5 – PE6 – CE7 – C8 PE3: router bgp 100 address-family ipv4 unicast ! address-family vpnv4 unicast ! neighbor 10.1.100.6 remote-as 100 update-source Loopback0 address-family vpnv4 unicast vrf CORE rd 100:1 address-family ipv4 unicast allocate-label all ! neighbor 172.16.23.2 remote-as 10 address-family ipv4 labeled-unicast route-policy ALLOW in route-policy ALLOW out CE2: router bgp 10 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 10.1.100.7 remote-as 7 neighbor 10.1.100.7 ebgp-multihop 5 neighbor 172.16.23.3 remote-as 100 ! address-family ipv4 network 10.1.100.2 mask 255.255.255.255 neighbor 172.16.23.3 activate neighbor 172.16.23.3 send-label exit-address-family ! address-family vpnv4 neighbor 10.1.100.7 activate neighbor 10.1.100.7 send-community extended exit-address-family ! address-family ipv4 vrf CUST redistribute static exit-address-family Nothing on the C except for a default route , is there anything I am missing? LDP is functioning well along the path. Appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Support for CFP2
Shawn L via cisco-nsp wrote on 19/01/2024 14:58: The pluggable optic must be DWDM 1530 to 1563 nm with QPSK modulation that fits 50Ghz (~31 to 35Gbaud) and a launch power of ZR+ 0dBm. The customer channel should have Rx: Max <-10 dBm/Ch and Tx: Min: >–5 dBm/Ch to Max: <+ 6.5dBm/Ch in order to meet the GOSNR margin of 2.5dBm or more. right, so DWDM alien wave requirement then. That's very non-portable and kit specific. Depending on the application, you might be better off ditching the requirements that they're imposing and simply using 100G transponders (i.e. 100G as a service). Or something like the smartoptics open line system with PAM4 QSFP28 transceivers. It really depends on what's between you and the other end. D/F has simple options open for single 100G. If you're connecting into something more complicated, it can get messy and expensive. Nick _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Support for CFP2
Shawn L via cisco-nsp wrote on 19/01/2024 14:35: At $dayjob we're working on turning up a 100G connection with a provider. At this point, it looks like the only optic that's meets their criteria is a CFP2. sounds like metro 100G connectivity. What sort of distances are involved, and is there a requirement for DWDM? If it's shorter distance and no DWDM, 100G LR4 extended reach might work (8dB power budget, compared to the usual 4dB for standard LR4). Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Support for CFP2
I have. They're telling me I need The pluggable optic must be DWDM 1530 to 1563 nm with QPSK modulation that fits 50Ghz (~31 to 35Gbaud) and a launch power of ZR+ 0dBm. The customer channel should have Rx: Max <-10 dBm/Ch and Tx: Min: >–5 dBm/Ch to Max: <+ 6.5dBm/Ch in order to meet the GOSNR margin of 2.5dBm or more. On Fri, Jan 19, 2024 at 9:44 AM Nathan Lannine wrote: > >> Everything we have uses the QSFP28 form factor, and there doesn't seem to >> be any optics on the market yet with that form factor that is going to >> work, though there should be some coming out in the second quarter. >> >> At this point, we'd like to turn the service up sooner that later, so >> we're >> looking for options. We could put something in between their equipment >> and >> ours (AST9901 fixed chassis), but I have no idea what that might be. >> We're >> >> > Have you checked out the Transceiver compatibility matrix ( > https://tmgmatrix.cisco.com/iop?tpid=6)? In particular, the page I > linked (and I may just not be understanding correctly) seems to be saying > that QSFP-100G-ER4L-S may be compatible with what you are looking for. > > Regards, > Nathan > _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Support for CFP2
> > > Everything we have uses the QSFP28 form factor, and there doesn't seem to > be any optics on the market yet with that form factor that is going to > work, though there should be some coming out in the second quarter. > > At this point, we'd like to turn the service up sooner that later, so we're > looking for options. We could put something in between their equipment and > ours (AST9901 fixed chassis), but I have no idea what that might be. We're > > Have you checked out the Transceiver compatibility matrix ( https://tmgmatrix.cisco.com/iop?tpid=6)? In particular, the page I linked (and I may just not be understanding correctly) seems to be saying that QSFP-100G-ER4L-S may be compatible with what you are looking for. Regards, Nathan ___________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Support for CFP2
At $dayjob we're working on turning up a 100G connection with a provider. At this point, it looks like the only optic that's meets their criteria is a CFP2. Unfortunately, we don't have any equipment that supports those. Everything we have uses the QSFP28 form factor, and there doesn't seem to be any optics on the market yet with that form factor that is going to work, though there should be some coming out in the second quarter. At this point, we'd like to turn the service up sooner that later, so we're looking for options. We could put something in between their equipment and ours (AST9901 fixed chassis), but I have no idea what that might be. We're not real familiar with the newer optics, DWDM, etc. at this point. I don't really want to add more complexity to the circuit by adding in additional equipment (or spending a lot more $$), but hoping there might be something that we can use to convert it somehow. Thanks Shawn ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] C2C ASR9K
Greetings I am trying to configure C2C with BGP as the PE-CE routing protocol and Static as the C to CE routing protocol. The main issue am running now is the eBGP session (VPNv4) between the CEs , routes are delivered but there is no connectivity and hence the eBGP session is not coming up. Per my understanding , the BGP should be labelled unicast between the PE (XRV 6.6.2) and the respective CE. Before i changed the BGP session from IPv4 unicast to labeled unicast it was working (CE to CE traffic) , when I moved to the C traffic , I had to change the BGP to labeled unicast. C1 – CE2 – PE3 – P4 – P5 – PE6 – CE7 – C8 PE3: router bgp 100 address-family ipv4 unicast ! address-family vpnv4 unicast ! neighbor 10.1.100.6 remote-as 100 update-source Loopback0 address-family vpnv4 unicast vrf CORE rd 100:1 address-family ipv4 unicast allocate-label all ! neighbor 172.16.23.2 remote-as 10 address-family ipv4 labeled-unicast route-policy ALLOW in route-policy ALLOW out CE2: router bgp 10 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 10.1.100.7 remote-as 7 neighbor 10.1.100.7 ebgp-multihop 5 neighbor 172.16.23.3 remote-as 100 ! address-family ipv4 network 10.1.100.2 mask 255.255.255.255 neighbor 172.16.23.3 activate neighbor 172.16.23.3 send-label exit-address-family ! address-family vpnv4 neighbor 10.1.100.7 activate neighbor 10.1.100.7 send-community extended exit-address-family ! address-family ipv4 vrf CUST redistribute static exit-address-family Nothing on the C except for a default route , is there anything I am missing? LDP is functioning well along the path. Appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9000 QoS counters on LAG
On Fri, 19 Jan 2024 at 05:10, Ross Halliday via cisco-nsp wrote: > We've inherited some older ASR9000 systems that we're trying to support > in-place. The software version on this one router is fairly old at 6.1.4. > Driving it are a pair of RSP440-SE. The line cards are A9K-MOD160-SE with > A9K-MPA-8X10GE in each. > > I haven't had any issues until trying to apply a policy map in the egress > direction on a LAG. The counters simply don't increase. I'm aware of the > complexities of policing, but right now I just want to see packets match a > class - any class - even class-default doesn't increment as expected. > Everything works as expected on a non-LAG port. Ingress works fine, as well - > this is just egress on a LAG. > > IOS-XR is not my strong point at all. I'm not sure if I'm missing something > very obvious, but this seems so weird that it feels like a display bug. > > The LAG members are split between the two linecards. > > Any suggestions would be greatly appreciated! Any syslog messages when you attach it? I don't think the device supports 'priority level 3', there is only default, 2 and 1 . Default being the worst and 1 the best (well in CLI, in NPU they are reversed to make debugging less boring). Practically all the utility of priority level has already been used, by the time egress policy is considered, so they don't much here, you should set them on ingress. Not related, but I can't help myself, you shouldn't classify and schedule on egress, you classify on ingress, and schedule/rewrite on egress. That is 'your match dscp/cos' should be on ingress, with 'set qos-group N', and on 'egress' you do 'match qos-group N'. Not only will this separation of concerns make things a lot easier to rationale and manage, but it's the only way you can do QoS on many other platforms, so you don't have re-invent policies for different platforms. Do remember that by default 'police X' in LAG in ASR9000 means X in each interface, for total LAG capacity of X*interfaces_up (variant). There is no way to configure shared policer in any platform at all, but there is a way to tell platform to divide X by active member count for each member, so aggregate cannot be more than X, but no single interface can burst more than X/member_count. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ASR9000 QoS counters on LAG
Hello, We've inherited some older ASR9000 systems that we're trying to support in-place. The software version on this one router is fairly old at 6.1.4. Driving it are a pair of RSP440-SE. The line cards are A9K-MOD160-SE with A9K-MPA-8X10GE in each. I haven't had any issues until trying to apply a policy map in the egress direction on a LAG. The counters simply don't increase. I'm aware of the complexities of policing, but right now I just want to see packets match a class - any class - even class-default doesn't increment as expected. Everything works as expected on a non-LAG port. Ingress works fine, as well - this is just egress on a LAG. IOS-XR is not my strong point at all. I'm not sure if I'm missing something very obvious, but this seems so weird that it feels like a display bug. The LAG members are split between the two linecards. Any suggestions would be greatly appreciated! config: interface Bundle-Ether4 mtu 9200 service-policy output LLQ-Outbound ! interface BE4.3892 vrf iptv ipv4 mtu 1500 ipv4 address 9 255 ipv4 verify unicast source reachable-via rx allow-self-ping encapsulation dot1q 3892 ! class-map match-any DSCP-Network match dscp cs6 cs7 match cos 6 7 end-class-map ! class-map match-any DSCP-Voice match dscp cs5 ef end-class-map ! class-map match-any DSCP-TV match dscp cs4 af41 end-class-map ! class-map match-any DSCP-Management match dscp cs3 af31 end-class-map ! policy-map LLQ-Outbound class DSCP-Network priority level 1 police rate 100 mbps conform-action transmit exceed-action drop ! ! class DSCP-Voice priority level 2 police rate 200 mbps conform-action transmit exceed-action drop ! ! class DSCP-TV priority level 3 police rate 8000 mbps conform-action transmit exceed-action drop ! ! class DSCP-Management priority level 3 police rate 200 mbps conform-action transmit exceed-action drop ! ! class class-default ! end-policy-map ! ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Pnet XRV 6.6.2
It was interface mapping issue , G0/0/0/0 is actually G0/0/0/2 Thanks everyone. From: cisco-nsp on behalf of Mohammad Khalil via cisco-nsp Sent: Wednesday, December 27, 2023 3:42 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Pnet XRV 6.6.2 Greetings I have uploaded image xrv 6.2.2 on pnet for a lab environment and the image booted successfuly. However , I am not able to ping any connected neighbor on any interface though all interfaces are up/up. Interface IP-Address Status Protocol Vrf-Name Loopback0 10.1.100.3 Up Up default MgmtEth0/0/CPU0/0 unassigned ShutdownDown default GigabitEthernet0/0/0/0 10.1.13.3 Up Up default GigabitEthernet0/0/0/1 10.1.35.3 Up Up default GigabitEthernet0/0/0/2 10.1.23.3 Up Up default GigabitEthernet0/0/0/3 unassigned ShutdownDown default GigabitEthernet0/0/0/4 unassigned ShutdownDown default GigabitEthernet0/0/0/5 unassigned ShutdownDown default Is there anything I should do to resolve this? Appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Pnet XRV 6.6.2
Greetings I have uploaded image xrv 6.2.2 on pnet for a lab environment and the image booted successfuly. However , I am not able to ping any connected neighbor on any interface though all interfaces are up/up. Interface IP-Address Status Protocol Vrf-Name Loopback0 10.1.100.3 Up Up default MgmtEth0/0/CPU0/0 unassigned ShutdownDown default GigabitEthernet0/0/0/0 10.1.13.3 Up Up default GigabitEthernet0/0/0/1 10.1.35.3 Up Up default GigabitEthernet0/0/0/2 10.1.23.3 Up Up default GigabitEthernet0/0/0/3 unassigned ShutdownDown default GigabitEthernet0/0/0/4 unassigned ShutdownDown default GigabitEthernet0/0/0/5 unassigned ShutdownDown default Is there anything I should do to resolve this? Appreciated. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9901 licensing configuration
So, amazingly I opened a TAC case this morning, and had an engineer looking at it by a little after noon. I expected to have a couple of days of information gathering, etc. before someone wanted to do a webex and look at it. Eventually we found that A - the correct parameters for call-home were not in fact the ones that I had in there (according to the docs) B - Even though it really wants to use the management interface, it can't because you cannot seem to get a default route on the management interface so that it can call home. Ultimately, fixing the call-home URLs, and adding an interface / default route (router isn't in production yet, need to get all the little things resolved first) was the key. I'm not sure if it was because it's slow at Cisco right before Christmas or what, but I have to say this was one of the fastest tickets I've ever seen. On Fri, Dec 22, 2023 at 11:29 AM Drew Weaver via cisco-nsp < cisco-nsp@puck.nether.net> wrote: > Good luck is the right response. > > They insist that our ASR9902 is an ASR9903 at TAC every time I open a > ticket. > > It's getting old. > > -Original Message- > From: cisco-nsp On Behalf Of Hank > Nussbacher via cisco-nsp > Sent: Friday, December 22, 2023 2:11 AM > To: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] ASR9901 licensing configuration > > On 21/12/2023 22:35, Shawn L via cisco-nsp wrote: > > Running on IOS-XR 7.5.2 > > I get: > RP/0/RSP0/CPU0:GP1#license smart ? >deregister De-register Device from Cisco Cloud >mfg Factory license reservation feature >register Register Device With Cisco Cloud >renew Renewal Message to Cisco cloud > > Good luck w/ TAC :-) > > Regards, > Hank > > > I have a new ASR9901 and this is my first foray into Cisco's smart > > licensing. Can anyone point me in the right direction? I've found > > numerous cisco docs for configuring it, but the commands don't seem to > > be present on my router. > > > > For example, the ASR9k documentation (I cannot seem to find 9901 > > specific > > info) shows the following to add a token > > > > license smart register idtoken > > > > However, I don't seem to have that > > > > license smart ? > >flexible-consumption flexible-consumption(Vortex) model > >proxy Proxy related commands > >reservation Enable or disable the license reservation > feature > >software-upgrade Enable or disable the software-upgrade feature > >transport Select the type of message transport for Smart > > Licensing > >url Set the Smart Transport Primary URL > > > > I could put in a TAC ticket, but that seems to take forever. Hoping > > someone has done it on a 9901 a time or two and can point me in the > > correct direction. > > ___ > > cisco-nsp mailing list cisco-nsp@puck.nether.net > > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_m > > ailman_listinfo_cisco-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A > > _CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2Yu > > ddwXqdcFRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=0NqBVwwqU4fK > > sY_mQ_XYlH7DIXo3uV3W6R42OcbKKAA= > > archive at > > https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pi > > permail_cisco-2Dnsp_=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnV > > fiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2YuddwXqdc > > FRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=yve23k__j8uVmf0Lx7Z > > -k7I7ekxYaicWQ6RQ5kkjzzs= > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2YuddwXqdcFRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=0NqBVwwqU4fKsY_mQ_XYlH7DIXo3uV3W6R42OcbKKAA= > archive at > https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2YuddwXqdcFRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=yve23k__j8uVmf0Lx7Z-k7I7ekxYaicWQ6RQ5kkjzzs= > _______ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9901 licensing configuration
Good luck is the right response. They insist that our ASR9902 is an ASR9903 at TAC every time I open a ticket. It's getting old. -Original Message- From: cisco-nsp On Behalf Of Hank Nussbacher via cisco-nsp Sent: Friday, December 22, 2023 2:11 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR9901 licensing configuration On 21/12/2023 22:35, Shawn L via cisco-nsp wrote: Running on IOS-XR 7.5.2 I get: RP/0/RSP0/CPU0:GP1#license smart ? deregister De-register Device from Cisco Cloud mfg Factory license reservation feature registerRegister Device With Cisco Cloud renew Renewal Message to Cisco cloud Good luck w/ TAC :-) Regards, Hank > I have a new ASR9901 and this is my first foray into Cisco's smart > licensing. Can anyone point me in the right direction? I've found > numerous cisco docs for configuring it, but the commands don't seem to > be present on my router. > > For example, the ASR9k documentation (I cannot seem to find 9901 > specific > info) shows the following to add a token > > license smart register idtoken > > However, I don't seem to have that > > license smart ? >flexible-consumption flexible-consumption(Vortex) model >proxy Proxy related commands >reservation Enable or disable the license reservation feature >software-upgrade Enable or disable the software-upgrade feature >transport Select the type of message transport for Smart > Licensing >url Set the Smart Transport Primary URL > > I could put in a TAC ticket, but that seems to take forever. Hoping > someone has done it on a 9901 a time or two and can point me in the > correct direction. > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_m > ailman_listinfo_cisco-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A > _CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2Yu > ddwXqdcFRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=0NqBVwwqU4fK > sY_mQ_XYlH7DIXo3uV3W6R42OcbKKAA= > archive at > https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pi > permail_cisco-2Dnsp_=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnV > fiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2YuddwXqdc > FRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=yve23k__j8uVmf0Lx7Z > -k7I7ekxYaicWQ6RQ5kkjzzs= ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2YuddwXqdcFRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=0NqBVwwqU4fKsY_mQ_XYlH7DIXo3uV3W6R42OcbKKAA= archive at https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=bDwjmx2YuddwXqdcFRn6_LpERG6Ug7xCv0qRSy0MEJuHLHlaBEoNu7NTJWVWA76t=yve23k__j8uVmf0Lx7Z-k7I7ekxYaicWQ6RQ5kkjzzs= ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9901 licensing configuration
On 21/12/2023 22:35, Shawn L via cisco-nsp wrote: Running on IOS-XR 7.5.2 I get: RP/0/RSP0/CPU0:GP1#license smart ? deregister De-register Device from Cisco Cloud mfg Factory license reservation feature registerRegister Device With Cisco Cloud renew Renewal Message to Cisco cloud Good luck w/ TAC :-) Regards, Hank I have a new ASR9901 and this is my first foray into Cisco's smart licensing. Can anyone point me in the right direction? I've found numerous cisco docs for configuring it, but the commands don't seem to be present on my router. For example, the ASR9k documentation (I cannot seem to find 9901 specific info) shows the following to add a token license smart register idtoken However, I don't seem to have that license smart ? flexible-consumption flexible-consumption(Vortex) model proxy Proxy related commands reservation Enable or disable the license reservation feature software-upgrade Enable or disable the software-upgrade feature transport Select the type of message transport for Smart Licensing url Set the Smart Transport Primary URL I could put in a TAC ticket, but that seems to take forever. Hoping someone has done it on a 9901 a time or two and can point me in the correct direction. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] ASR9901 licensing configuration
I have a new ASR9901 and this is my first foray into Cisco's smart licensing. Can anyone point me in the right direction? I've found numerous cisco docs for configuring it, but the commands don't seem to be present on my router. For example, the ASR9k documentation (I cannot seem to find 9901 specific info) shows the following to add a token license smart register idtoken However, I don't seem to have that license smart ? flexible-consumption flexible-consumption(Vortex) model proxy Proxy related commands reservation Enable or disable the license reservation feature software-upgrade Enable or disable the software-upgrade feature transport Select the type of message transport for Smart Licensing url Set the Smart Transport Primary URL I could put in a TAC ticket, but that seems to take forever. Hoping someone has done it on a 9901 a time or two and can point me in the correct direction. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 fpd upgrade
I might just be using the quirkiest products in their lineup but if you have to upgrade fpd and reload line cards 8 times to get the firmware to upgrade it seems like the support better be pristine. -Original Message- From: cisco-nsp On Behalf Of Aaron1 via cisco-nsp Sent: Thursday, December 21, 2023 9:05 AM To: Hank Nussbacher Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR9902 fpd upgrade Agreed, often I’ve started a TAC case and also started an email thread with NANOG, juniper nsp or cisco nsp mail lists…. Often the community comes back faster than TACs. …and without needing RSI or show tech… just a pointed response to the issue. Love it Aaron > On Dec 21, 2023, at 1:21 AM, Hank Nussbacher via cisco-nsp > wrote: > On 20/12/2023 17:31, Drew Weaver via cisco-nsp wrote: > > Only a week? I have found this list far more helpful than TAC, which usually > takes 2-3 weeks to request all the necessary logs, with commands that don't > work. > > It used to be TAC was a main selling card of Cisco vs competitors. > Not any longer :-( > > Regards, > Hank > >> Hello, >> I've had a TAC case open on this for more than a week but after we upgraded >> an ASR9902 to 7.9.21 the FPD upgrade process is not completing. >> I've gotten it to this point: >> show hw fpd | i RLOAD >> Wed Dec 20 10:35:41.200 EST >> 0/RP0 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 >> 33.30 >> 0/RP1 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 >> 33.30 >> 0/0ASR-9902-LC 1.0 Primary-BIOS RLOAD REQ 34.28 >> 34.30 >> 0/0ASR-9902-LC 1.0 Sunstreaker RLOAD REQ 0.15 >> 0.19 >> 0/0ASR-9902-LC 1.0 TAMFW-SunstreakerRLOAD REQ 2.65 >> 2.72 >> I've reloaded the entire router, I've reloaded the specific 'locations', and >> I've even pulled the power cords out of the router to see if it needs to >> 'cold start'. >> I'm clearly just banging my head against a wall at this point. >> Does anyone know how to resolve RLOAD REQ on these? >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_ >> mailman_listinfo_cisco-2Dnsp=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v >> 5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=i5wp83 >> AWCeP02dX-xrDiMksDEHG2HurYeaS-lqKSMbnQFjusloQ1AukTJ5TE4Exc=iZ0FIZf7 >> QQXZ7EpeBF79q8i9Dibcm687mGMtCRJi_Gw= >> archive at >> https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_p >> ipermail_cisco-2Dnsp_=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_Cdpg >> nVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=i5wp83AWCeP02 >> dX-xrDiMksDEHG2HurYeaS-lqKSMbnQFjusloQ1AukTJ5TE4Exc=EbXgnm8udswR_ng >> B1y8MoO2W98Rl0Ep7Y9PONHpBK2s= > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_m > ailman_listinfo_cisco-2Dnsp=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A > _CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=i5wp83AWC > eP02dX-xrDiMksDEHG2HurYeaS-lqKSMbnQFjusloQ1AukTJ5TE4Exc=iZ0FIZf7QQXZ > 7EpeBF79q8i9Dibcm687mGMtCRJi_Gw= > archive at > https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pi > permail_cisco-2Dnsp_=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnV > fiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=i5wp83AWCeP02dX- > xrDiMksDEHG2HurYeaS-lqKSMbnQFjusloQ1AukTJ5TE4Exc=EbXgnm8udswR_ngB1y8 > MoO2W98Rl0Ep7Y9PONHpBK2s= ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=i5wp83AWCeP02dX-xrDiMksDEHG2HurYeaS-lqKSMbnQFjusloQ1AukTJ5TE4Exc=iZ0FIZf7QQXZ7EpeBF79q8i9Dibcm687mGMtCRJi_Gw= archive at https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=i5wp83AWCeP02dX-xrDiMksDEHG2HurYeaS-lqKSMbnQFjusloQ1AukTJ5TE4Exc=EbXgnm8udswR_ngB1y8MoO2W98Rl0Ep7Y9PONHpBK2s= ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 fpd upgrade
Agreed, often I’ve started a TAC case and also started an email thread with NANOG, juniper nsp or cisco nsp mail lists…. Often the community comes back faster than TACs. …and without needing RSI or show tech… just a pointed response to the issue. Love it Aaron > On Dec 21, 2023, at 1:21 AM, Hank Nussbacher via cisco-nsp > wrote: > On 20/12/2023 17:31, Drew Weaver via cisco-nsp wrote: > > Only a week? I have found this list far more helpful than TAC, which usually > takes 2-3 weeks to request all the necessary logs, with commands that don't > work. > > It used to be TAC was a main selling card of Cisco vs competitors. Not any > longer :-( > > Regards, > Hank > >> Hello, >> I've had a TAC case open on this for more than a week but after we upgraded >> an ASR9902 to 7.9.21 the FPD upgrade process is not completing. >> I've gotten it to this point: >> show hw fpd | i RLOAD >> Wed Dec 20 10:35:41.200 EST >> 0/RP0 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 >> 33.30 >> 0/RP1 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 >> 33.30 >> 0/0ASR-9902-LC 1.0 Primary-BIOS RLOAD REQ 34.28 >> 34.30 >> 0/0ASR-9902-LC 1.0 Sunstreaker RLOAD REQ 0.15 >> 0.19 >> 0/0ASR-9902-LC 1.0 TAMFW-SunstreakerRLOAD REQ 2.65 >> 2.72 >> I've reloaded the entire router, I've reloaded the specific 'locations', and >> I've even pulled the power cords out of the router to see if it needs to >> 'cold start'. >> I'm clearly just banging my head against a wall at this point. >> Does anyone know how to resolve RLOAD REQ on these? >> ___ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 fpd upgrade
On Thu, 21 Dec 2023 at 09:21, Hank Nussbacher via cisco-nsp wrote: > It used to be TAC was a main selling card of Cisco vs competitors. Not > any longer :-( Don't remember them ever being relatively or absolutely good. Having one support channel for all requests doesn't work, because >99% cases are useless cases from people who didn't do their homework and are just wasting resources, so everyone optimises the process around dealing with those, which makes the experience feel horrible to the legitimate support cases. But vendors sell at premium cost different experience, Cisco calls it HTTS, it's not necessarily that you get better people, but you get named people who will quickly learn that the previous optimisation point doesn't work with you, because your cases are legitimate, so they don't perform the useless volleys in hope that the customer realises their error and doesn't come back, which is good strategy as it works often. Unfortunately HTTS is quite expensive and it feels backwards, that the people who are reporting legitimate problems in your product also have to pay more to get support. It often feels like no one buys Ciscos or Junipers, but leases them, as the support contracts are so outrageous, and you can't go without the support contracts. I'm not blaming Cisco or any other vendor, I think this outcome is a market driven fact. If I try to imagine that someone releases a new NOS, which works as well as Windows or Linux, in that the OS almost never is the reason why basic functionality of your product is broken, then I can imagine lot of my customers would choose not to buy this lease-level support contract, and I'd be out of business. Market requires NOS' to be of really poor quality. -- ++ytti _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 fpd upgrade
On 20/12/2023 17:31, Drew Weaver via cisco-nsp wrote: Only a week? I have found this list far more helpful than TAC, which usually takes 2-3 weeks to request all the necessary logs, with commands that don't work. It used to be TAC was a main selling card of Cisco vs competitors. Not any longer :-( Regards, Hank Hello, I've had a TAC case open on this for more than a week but after we upgraded an ASR9902 to 7.9.21 the FPD upgrade process is not completing. I've gotten it to this point: show hw fpd | i RLOAD Wed Dec 20 10:35:41.200 EST 0/RP0 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 33.30 0/RP1 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 33.30 0/0ASR-9902-LC 1.0 Primary-BIOS RLOAD REQ 34.28 34.30 0/0ASR-9902-LC 1.0 Sunstreaker RLOAD REQ 0.15 0.19 0/0ASR-9902-LC 1.0 TAMFW-SunstreakerRLOAD REQ 2.65 2.72 I've reloaded the entire router, I've reloaded the specific 'locations', and I've even pulled the power cords out of the router to see if it needs to 'cold start'. I'm clearly just banging my head against a wall at this point. Does anyone know how to resolve RLOAD REQ on these? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 fpd upgrade
Hello, I was able to get this resolved by running: upgrade hw-module location 0/RP0 fpd all force and then admin hw-module loc 0/RP0 reload It took 6 times of doing that before the card reloaded with the right BIOS version (?) I only kept doing it because I was curious And upgrade hw-module location 0/RP1 fpd all force and then admin hw-module loc 0/RP1 reload This time it took 8 tries before the card reloaded with the right BIOS version (???) So then I did the same process with 0/0 and: It ended up like this: 0/0ASR-9902-LC 1.0 TimingIC-A UPGD SKIP 7.218 7.218 So then I reloaded 0/0 again.. And oh my god this time it worked. Keep in mind that I had already run the upgrade and reload several times prior to this. Just documenting incase anyone else is unfortunate enough to have to use this product. Thanks, -Drew -Original Message- From: cisco-nsp On Behalf Of Drew Weaver via cisco-nsp Sent: Wednesday, December 20, 2023 11:02 AM To: 'Mouniri Mdahoma' Cc: 'cisco-nsp@puck.nether.net' Subject: Re: [c-nsp] ASR9902 fpd upgrade admin show alarms brief Wed Dec 20 11:08:22.652 EST % No entries found. From: Mouniri Mdahoma <https://urldefense.proofpoint.com/v2/url?u=http-3A__mouniri.mdahoma-40gmail.com=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=YuUzhMBmgSu5ZOijAoLVOaZ9lQSE3GVtvWY1Ya4jqQ1Htqexq0Kys7xDXxPiUgSu=lRw1t6KuldSq0uWPDzo428_QvJnE83quzuCstnWQnJM=> Sent: Wednesday, December 20, 2023 10:59 AM To: Drew Weaver Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR9902 fpd upgrade Hello What is the output of the following command #admin show alarms brief Le mer. 20 déc. 2023, 16:32, Drew Weaver via cisco-nsp mailto:cisco-nsp@puck.nether.net>> a écrit : Hello, I've had a TAC case open on this for more than a week but after we upgraded an ASR9902 to 7.9.21 the FPD upgrade process is not completing. I've gotten it to this point: show hw fpd | i RLOAD Wed Dec 20 10:35:41.200 EST 0/RP0 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 33.30 0/RP1 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 33.30 0/0ASR-9902-LC 1.0 Primary-BIOS RLOAD REQ 34.28 34.30 0/0ASR-9902-LC 1.0 Sunstreaker RLOAD REQ 0.15 0.19 0/0ASR-9902-LC 1.0 TAMFW-SunstreakerRLOAD REQ 2.65 2.72 I've reloaded the entire router, I've reloaded the specific 'locations', and I've even pulled the power cords out of the router to see if it needs to 'cold start'. I'm clearly just banging my head against a wall at this point. Does anyone know how to resolve RLOAD REQ on these? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=YuUzhMBmgSu5ZOijAoLVOaZ9lQSE3GVtvWY1Ya4jqQ1Htqexq0Kys7xDXxPiUgSu=_totrGGQ3NUcR5IykO6Qv7fbwuQvZn6qFPmWDxo7fC4=<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=INb4ufWH-n5CyglZqgiOp3c5PMgnOcT_C4k-lgIXavcfZuAJ0rbVvxoK3mutBgMr=e5sfU1xv-NGJ6lUehivisO2onfx8R-U7SlQZQxv-Z0Q=> archive at https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=YuUzhMBmgSu5ZOijAoLVOaZ9lQSE3GVtvWY1Ya4jqQ1Htqexq0Kys7xDXxPiUgSu=Ob9G2837DmJgB6j41ZOIt6abJ_wWz4wwftqexU5Eu4k=<https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=INb4ufWH-n5CyglZqgiOp3c5PMgnOcT_C4k-lgIXavcfZuAJ0rbVvxoK3mutBgMr=_U-9kW6wmgu5BM4-bsEupn8MmLhGa2q0Gla8Wzie8do=> _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=YuUzhMBmgSu5ZOijAoLVOaZ9lQSE3GVtvWY1Ya4jqQ1Htqexq0Kys7xDXxPiUgSu=_totrGGQ3NUcR5IykO6Qv7fbwuQvZn6qFPmWDxo7fC4= archive at https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwIGaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=YuUzhMBmgSu5ZOijAoLVOaZ9lQSE3GVtvWY1Ya4jqQ1Htqexq0Kys7xDXxPiUgSu=Ob9G2837DmJgB6j41ZOIt6abJ_wWz4wwftqexU5Eu4k= _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mail
Re: [c-nsp] ASR9902 fpd upgrade
admin show alarms brief Wed Dec 20 11:08:22.652 EST % No entries found. From: Mouniri Mdahoma Sent: Wednesday, December 20, 2023 10:59 AM To: Drew Weaver Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ASR9902 fpd upgrade Hello What is the output of the following command #admin show alarms brief Le mer. 20 déc. 2023, 16:32, Drew Weaver via cisco-nsp mailto:cisco-nsp@puck.nether.net>> a écrit : Hello, I've had a TAC case open on this for more than a week but after we upgraded an ASR9902 to 7.9.21 the FPD upgrade process is not completing. I've gotten it to this point: show hw fpd | i RLOAD Wed Dec 20 10:35:41.200 EST 0/RP0 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 33.30 0/RP1 A99-RP-F 1.0 Primary-BIOS RLOAD REQ 33.29 33.30 0/0ASR-9902-LC 1.0 Primary-BIOS RLOAD REQ 34.28 34.30 0/0ASR-9902-LC 1.0 Sunstreaker RLOAD REQ 0.15 0.19 0/0ASR-9902-LC 1.0 TAMFW-SunstreakerRLOAD REQ 2.65 2.72 I've reloaded the entire router, I've reloaded the specific 'locations', and I've even pulled the power cords out of the router to see if it needs to 'cold start'. I'm clearly just banging my head against a wall at this point. Does anyone know how to resolve RLOAD REQ on these? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net<mailto:cisco-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-nsp<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_cisco-2Dnsp=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=INb4ufWH-n5CyglZqgiOp3c5PMgnOcT_C4k-lgIXavcfZuAJ0rbVvxoK3mutBgMr=e5sfU1xv-NGJ6lUehivisO2onfx8R-U7SlQZQxv-Z0Q=> archive at http://puck.nether.net/pipermail/cisco-nsp/<https://urldefense.proofpoint.com/v2/url?u=http-3A__puck.nether.net_pipermail_cisco-2Dnsp_=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=OPufM5oSy-PFpzfoijO_w76wskMALE1o4LtA3tMGmuw=INb4ufWH-n5CyglZqgiOp3c5PMgnOcT_C4k-lgIXavcfZuAJ0rbVvxoK3mutBgMr=_U-9kW6wmgu5BM4-bsEupn8MmLhGa2q0Gla8Wzie8do=> ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 fpd upgrade
Hello What is the output of the following command #admin show alarms brief Le mer. 20 déc. 2023, 16:32, Drew Weaver via cisco-nsp < cisco-nsp@puck.nether.net> a écrit : > Hello, > > I've had a TAC case open on this for more than a week but after we > upgraded an ASR9902 to 7.9.21 the FPD upgrade process is not completing. > > I've gotten it to this point: > > show hw fpd | i RLOAD > Wed Dec 20 10:35:41.200 EST > 0/RP0 A99-RP-F 1.0 Primary-BIOS RLOAD REQ > 33.29 33.30 > 0/RP1 A99-RP-F 1.0 Primary-BIOS RLOAD REQ > 33.29 33.30 > 0/0ASR-9902-LC 1.0 Primary-BIOS RLOAD REQ > 34.28 34.30 > 0/0ASR-9902-LC 1.0 Sunstreaker RLOAD REQ > 0.15 0.19 > 0/0ASR-9902-LC 1.0 TAMFW-SunstreakerRLOAD REQ > 2.65 2.72 > > I've reloaded the entire router, I've reloaded the specific 'locations', > and I've even pulled the power cords out of the router to see if it needs > to 'cold start'. > > I'm clearly just banging my head against a wall at this point. > > Does anyone know how to resolve RLOAD REQ on these? > > > ___ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
