Re: [c-nsp] Cisco ME3600X IOS 15.5.3S7 and pseudowires
David Wilkinson wrote on 08/08/2018 19:43: The MPLS interfaces are on SVIs That's probably your problem then. We've seen 15.5 causing catastrophic asic misprogramming events, assert failures and arbitrary traffic blackholing when configured with MPLS on SVIs. We tried several versions of 15.5 up to and including 15.5(3)S6, but couldn't find anything that worked properly. Do you know if moving them from SVIs to sub-interfaces would a be less buggy configuation? no idea tbh. You may be better off using physical interfaces for mpls, as it's a less complex configuration for the me3600 nile asics to handle. 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] Fixed switch based on N9K-X9636C-RX
--- Begin Message --- There isn't one. Closest is Nexus 3636C-R, this is J+ based like the 9636C-RX but with on-chip tables only (no external TCAM). Tim -Original Message- From: cisco-nsp On Behalf Of Drew Weaver Sent: Wednesday, August 8, 2018 5:39 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Fixed switch based on N9K-X9636C-RX Has anyone come across a 1U Nexus switch that has TCAM like the N9K-X9636C-RX? 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/ --- End Message --- ___ 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 ME3600X IOS 15.5.3S7 and pseudowires
On 2018-08-07 11:38, Nick Hilliard wrote: David Wilkinson wrote on 07/08/2018 13:11: I was setting up a couple of EoMPLS circuits on pair of Cisco ME3600Xs and while the pseudowires would come up and a "show mpls l2transport vc" would show the sent counter increasing the receive counter at the remote end was 0. Are any of your mpls interfaces configured on SVIs? 15.5 is unusably buggy with this style of config. 15.3 works a good deal better, if you can live with marginally fewer features. Nick Hi Nick, The MPLS interfaces are on SVIs, Do you know if moving them from SVIs to sub-interfaces would a be less buggy configuation? The EoMPLS xconnects are on ports. I might stick with 15.4 as that is working at the moment and hope we don't need to upgrade to 15.5 or 15.6 in the future. Thanks David ___ 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] Fixed switch based on N9K-X9636C-RX
Has anyone come across a 1U Nexus switch that has TCAM like the N9K-X9636C-RX? 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] One PE router, one customer, several sites
>From Christoffer: >From Victor Sudakov: >>If a customer has several separate sites each with Wifi, for example, will >>all these Wifi NETs go into the same VRF? > >Yes. >That is how it is most often when as31027 have customer links coming in on the >PE. >Customer locations will often be their own segmented broadcast domains. With >their own gateways IPs. >L3 wise. It will more often than not be one big routed domain across SP core. >(We rarely do L2VPN solutions (e.g. point-to-multipoint VPLS) because >technical debt/legacy equipment not yet completely outphased from production) > >Solutions tends to have centralized Internet outbreak(s)/Firewall(s) were >traffic between VRFs (also out to Internet/WAN) will then be policed. We have from time to time done solutions where CPE equipment (spoke role) at customer sites ran the same private asn-no. With only the CPE equipment (hub sites) ran with a different asn-no(s). Still all in the same VRF. Have the benefit of not needing import/export policies because of BGP loop prevention mechanicms kicking in and preventing spoke sites being able to speak with each other. Christoffer ___ 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] One PE router, one customer, several sites
Hi Victor, >From Victor Sudakov: >If a customer has several separate sites each with Wifi, for example, will >all these Wifi NETs go into the same VRF? Yes. That is how it is most often when as31027 have customer links coming in on the PE. Customer locations will often be their own segmented broadcast domains. With their own gateways IPs. L3 wise. It will more often than not be one big routed domain across SP core. (We rarely do L2VPN solutions (e.g. point-to-multipoint VPLS) because technical debt/legacy equipment not yet completely outphased from production) Solutions tends to have centralized Internet outbreak(s)/Firewall(s) were traffic between VRFs (also out to Internet/WAN) will then be policed. Christoffer ___ 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] One PE router, one customer, several sites
--- Begin Message --- >Dear Colleagues, > >If a customer's several sites are connected to the same PE router, >but to different interfaces, which is the recommended practice, >assuming that all these sites must be reachable from one another: > >1. Place all the interfaces into the same VRF. > >2. Place each site into a separate VRF and set up route import/export > between the VRFs. > >Thanks in advance for any input. It all depends on your VPN routing policy. If you want all sites to freely communicate between each other, put all of them into the same VRF. If you need to restrict communication (like forcing traffic to a central site/hub), use different VRFs with an appropriate import/export policy. Using different VRFs with an unrestricted import/export policy is IMHO a waste of resources, but your mileage might vary. oli --- End Message --- ___ 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/
