• Breaking News

    [Android][timeline][#f39c12]

    Sunday, August 18, 2019

    Internet Edge Redesign Networking

    Internet Edge Redesign Networking


    Internet Edge Redesign

    Posted: 18 Aug 2019 04:48 AM PDT

    I have been given a rare opportunity to basically start from scratch with our BGP peering configuration to our Internet providers. Don't downgoat yet, this is not a "how do I?" post. I just want your thoughts.

    If you are a service provider, I'd like to have a candid perspective. What do your customers do that you absolutely hate? What do your "model" customers do that most do not? You see where I'm going with this.

    Whether or not you are an ISP, what are some best practices? While BCP 194 is full of great advice, it is not the be-all, end-all, and is generally SP-oriented.

    Our setup: We peer with two ISPs from both of our centralized data centers. That is, ISP1 terminates on DC1-Edge1 and DC2-Edge1, and ISP2 terminates on DC1-Edge2 and DC2-Edge2. Our circuits into the secondary DC are low bandwidth / burstable; they are low-cost DR connections unless we mess up and use them in non-DR situations.

    ASN: We have one ARIN-assigned ASN. If I need to push for a second one, now is the time.

    IPv4: We actually have an ARIN-assigned Class B. It rarely sees the light of day on the Internet, but our firewalls use addresses from the upper-most /21 for NAT. In particular, DC1 will use addresses from anywhere in the 252.0 - 255.255 range, and DC2 will use addresses from the 248.0 - 251.255 range.

    Our DMZ and most other public-facing services use address space from a /21 allocated from ISP1. Not really sure why we did that, but it's deeply embedded at this point. We do announce that /21 to both providers.

    The current plan is to announce the aggregate /16 and /21 from both data centers, to both ISPs, with 3x prepend out of DC2. Out of DC2, I was also going to announce the longer 248.0/22 with no prepending.

    IPv6: We have an ARIN-assigned /36, but we're not as cool as you because we don't use ours in any real capacity at this time. I was going to simply announce the /36 from both DCs, with 3x prepending out of DC2.

    Thoughts? Either on the design or in general?

    submitted by /u/ariesgeek
    [link] [comments]

    Redistribution vs Default Route

    Posted: 18 Aug 2019 11:06 AM PDT

    Trying to understand a network configuration my coworker made. We have a pretty beefy router capable of holding the entire BGP table (its not summarized, dont ask me why) from our internet provider. We are currently redistributing all of it into OSPF.

    I dont understand the point of doing that , and I am sorry if I am being stupid here, when you can just offload all of that CPU utilization with a default route from our internal non edge/core routers and send all requests to the core edge.

    Do I have flawed logic here?

    submitted by /u/NetworkGuy22
    [link] [comments]

    Aruba Instant AP Advisory (v8.5)

    Posted: 18 Aug 2019 06:28 AM PDT

    Got this overnight at work.

    Who in their right mind thought it would be a good idea to ship a version update that shifts the default interface off the first one? I get one version being an oops, too, but 3? Holy cow.

    Hopefully none of you have made the jump yet. I will be holding our ten 375s off for a few months but that's only because we open our gates in 4 days for our big event of the year.

    Default Uplink Change in Instant 8.5.0.0

    Confidentiality Level: Aruba Customers & Partners only | Rev-2 (August 15, 2019)

    AFFECTED PRODUCTS

    · AP-318, AP-374, AP-375, AP-377 when upgraded from Instant 8.3.x or 8.4.x to Instant 8.5.0.0, 8.5.0.1, or 8.5.0.2

    SUMMARY

    In Aruba Instant versions prior to 8.5.0.0, the default uplink port for all Instant APs is eth0 (copper interface). Starting from Instant version 8.5.0.0, the default uplink port for AP-318 and 370 series Access Points was changed to eth1 (fiber interface).

    Therefore, when an Instant AP network with AP-318 and AP-370 series Access Points using port eth0 for uplink connection,

    Is upgraded from Instant 8.3.x.x/8.4.x.x to Instant 8.5.0.0/8.5.0.1/8.5.0.2, OR

    Has the IAP configuration reset to factory defaults on Instant 8.5.0.0, 8.5.0.1 or 8.5.0.2,

    Then, only the AP-318 and AP-370 series Access Points will get disconnected from the network because their default active uplink port configuration will change from eth0 to eth1.

    The disconnected APs can be reconnected to the network by changing the preferred-uplink port configuration from the CLI through the AP's console.

    DESCRIPTION OF THE LIMITATIONS

    In troubleshooting this issue, it was found that the original workaround developed would only address the Master AP in an Instant cluster, or an Instant AP in standalone mode. APs that were cluster members (slave or non-master) will not inherit the workaround change, and as a result will be disconnected from the network.

    As a result, in an abundance of caution and to ensure we minimize as much as possible the potential impact and downtime of the AP-318/370 series APs, Aruba has removed the firmware image for these AP platforms (named 'Hercules') from Support site, Central, and Activate until the firmware with the fix for this issue is released (8.5.0.3). Further, 8.5.0.2 firmware for these AP platforms will be on a 'controlled release' until 8.5.0.3 is published. Because the AP-31x and AP-32x APs share and use the same 'Hercules' firmware image, the removal of 'Hercules' from support sites will also temporarily limit customers using AP-31x and AP-32x seeking to upgrade to 8.5.x.x.

    While the AP-31x and AP-32x Access Points are not impacted by the bug, because the 'Hercules' firmware is being temporarily removed to protect any impact to customers, customers needing 8.5.0.x for the AP-31x and AP-32x APs will simply need to follow the procedures below pursuant to their deployment to be able to access the firmware. These procedures will not be needed after 8.5.0.3 is released.

    RECOMMENDATIONS AND CONDITIONS

    The general recommendation for customers who would like to upgrade to Instant 8.5.0.x and have any of IAP-314/315, IAP-324/325, AP-318 and AP-374/375/377/387 in their network is to wait until 8.5.0.3 releases.Confidentiality Level: Aruba Customers & Partners only | Rev-2 (August 15, 2019)

    AFFECTED PRODUCTS

    · AP-318, AP-374, AP-375, AP-377 when upgraded from Instant 8.3.x or 8.4.x to Instant 8.5.0.0, 8.5.0.1, or 8.5.0.2

    SUMMARY

    In Aruba Instant versions prior to 8.5.0.0, the default uplink port for all Instant APs is eth0 (copper interface). Starting from Instant version 8.5.0.0, the default uplink port for AP-318 and 370 series Access Points was changed to eth1 (fiber interface).

    Therefore, when an Instant AP network with AP-318 and AP-370 series Access Points using port eth0 for uplink connection,

    Is upgraded from Instant 8.3.x.x/8.4.x.x to Instant 8.5.0.0/8.5.0.1/8.5.0.2, OR

    Has the IAP configuration reset to factory defaults on Instant 8.5.0.0, 8.5.0.1 or 8.5.0.2,

    Then, only the AP-318 and AP-370 series Access Points will get disconnected from the network because their default active uplink port configuration will change from eth0 to eth1.

    The disconnected APs can be reconnected to the network by changing the preferred-uplink port configuration from the CLI through the AP's console.

    DESCRIPTION OF THE LIMITATIONS

    In troubleshooting this issue, it was found that the original workaround developed would only address the Master AP in an Instant cluster, or an Instant AP in standalone mode. APs that were cluster members (slave or non-master) will not inherit the workaround change, and as a result will be disconnected from the network.

    As a result, in an abundance of caution and to ensure we minimize as much as possible the potential impact and downtime of the AP-318/370 series APs, Aruba has removed the firmware image for these AP platforms (named 'Hercules') from Support site, Central, and Activate until the firmware with the fix for this issue is released (8.5.0.3). Further, 8.5.0.2 firmware for these AP platforms will be on a 'controlled release' until 8.5.0.3 is published. Because the AP-31x and AP-32x APs share and use the same 'Hercules' firmware image, the removal of 'Hercules' from support sites will also temporarily limit customers using AP-31x and AP-32x seeking to upgrade to 8.5.x.x.

    While the AP-31x and AP-32x Access Points are not impacted by the bug, because the 'Hercules' firmware is being temporarily removed to protect any impact to customers, customers needing 8.5.0.x for the AP-31x and AP-32x APs will simply need to follow the procedures below pursuant to their deployment to be able to access the firmware. These procedures will not be needed after 8.5.0.3 is released.

    RECOMMENDATIONS AND CONDITIONS

    The general recommendation for customers who would like to upgrade to Instant 8.5.0.x and have any of IAP-314/315, IAP-324/325, AP-318 and AP-374/375/377/387 in their network is to wait until 8.5.0.3 releases.

    submitted by /u/d3photo
    [link] [comments]

    Layer 2 circuit between two local interfaces

    Posted: 17 Aug 2019 11:07 PM PDT

    Searching for the best way to configure a circuit between two interfaces same chassis different cards

    No VLAN's - Basic example all traffic entering Card 1 P1 is switched to Card 2 P1

    Reason: for testing near end will be Ethernet Tester and far end hard loop.

    What is the technical term and basic configuration required.

    Layer 2 circuit, Epipe, P2P?

    submitted by /u/leelee__
    [link] [comments]

    IP Prefix List Question

    Posted: 18 Aug 2019 08:29 AM PDT

    Hi all,

    Quick question about prefix lists. I'm peering with a partner and injecting a route map IN (BGP), which restricts the prefixes advertised to us, but a quick question, because I'm trying to save the amount of config to be written up. The partner is advertising a lot of /23 and /24s.

    Example: Let's say the partner is advertising 192.168.206.0/23 and 192.168.207.0/24. To save 2 entries for both prefixes, I thought of writing up a config in this manner:
    ip prefix-list REDDIT seq 5 permit 192.168.206.0/23 le 24.

    My understand is that this will allow both the 192.168.206.0/23 and 192.168.207.0/24.

    Does this look correct?

    Thanks

    submitted by /u/kramer9797
    [link] [comments]

    Is it possible to combine Dante, HiQnet, Art-Net, and Video over IP with a Multilayer Switch?

    Posted: 17 Aug 2019 06:23 PM PDT

    The concept would be applied to temporary AV event setups. Essentially I would like to try to combine all AV signals (audio, lighting, video, and component control) with their respective protocols over fiber so that a single line can be run up to an MLS on the truss hanging from the ceiling and then split off to projectors, speakers, and lights using their various receivers/adapters.

    I'm familiar with the networking involved within each discipline but I've never seen anyone attempt to combine it all under one massive managed network, and as a result I can't find a definitive answer as to whether or not it can technically be done on this scale. Most of my research has brought me to sites talking about permanent AV installations for offices and campuses, however in my opinion this is a whole different kind of AV.

    I'm hoping that this kind of query fits in with this sub, if not then I'll remove it and post it elsewhere. Any advice that people can give would be greatly appreciated!

    submitted by /u/filthylenses
    [link] [comments]

    TFTP fails when restoring Cisco config

    Posted: 18 Aug 2019 07:53 AM PDT

    I'm trying to restore running config from a backup file using tftpd directly from the web GUI on an SG300. Tftpd on the server where the backup is saved shows activity and progress from the switch connection when I initiate the restore. However, it always fails as it reaches the end of the transfer. It's as if it times out the session. Anything else I can try?

    submitted by /u/iamblas
    [link] [comments]

    Nexus 9000v VXLAN EVPN Multi-Site - Duplicate + Looped Packets

    Posted: 17 Aug 2019 05:49 PM PDT

    Hi All

    Has anyone labbed VXLAN EVPN multi-site with on the Nexus 9000v?

    I have a test topology in EVE-NG, with two sites. One site has two BGWs (also acting as a spine), the other has one. Each site has a VTEP leaf.

    When sending unicast layer 2 traffic from the single BGW site to the multi-BGW site, in a capture on the DCI interface of the source BGW I see...

    1 packet to the VIP
    1 packet to the designated forwarder PIP
    1 packet looped back from the designated forwarder PIP

    All the packets make it down to the host on the multi-BGW site.

    The l2fwder output from the single BGW site's BGW indicates that the unicast traffic should be tunnelled to the VIP of the other, multi-BGW site, but for some reason this is ignored and it also seems to be forwarded as BUM traffic too.

    NXOS9# show system internal l2fwder mac Legend: * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC age - seconds since last seen,+ - primary entry using vPC Peer-Link, (T) - True, (F) - False, C - ControlPlane MAC VLAN MAC Address Type age Secure NTFY Ports ---------+-----------------+--------+---------+------+----+------------------ * 10 000c.291a.cfcf static - F F nve-peer1 192.168.101.3 G 101 5000.0009.0007 static - F F sup-eth1(R) G 20 5000.0009.0007 static - F F sup-eth1(R) G 10 5000.0009.0007 static - F F sup-eth1(R) * 10 b862.1f11.5641 static - F F nve-peer1 192.168.101.3 * 10 000c.29ec.ccd2 static - F F nve-peer3 192.168.88.1 <-- other site VIP G - 0200:c0a8:5802 static - F F sup-eth1(R) 1 1 -00:01:00:01:00:10 - 1 

    Does anyone else get the same duplicate traffic? I just want to check if this is a limitation of the l2fwder module of the VM (like maybe it's not storing the learned MACs correctly, causing the BUM treatment and split horizon being ignored), rather than an error in my config.

    submitted by /u/GreggsSausageRolls
    [link] [comments]

    No comments:

    Post a Comment

    Fashion

    Beauty

    Travel