Quickly and easily reference common RHEL administrative tasks now
Quickly and easily reference common RHEL administrative tasks now
View in a Web Browser | |||
ProductsSupportDownloadsSecuritySubscriptions | |||
|
|||
|
|||
|
|||
gewoon, mijn archief
Quickly and easily reference common RHEL administrative tasks now
View in a Web Browser | |||
ProductsSupportDownloadsSecuritySubscriptions | |||
|
|||
|
|||
|
|||
> I took a look at the tracepath information you sent for these nodes,
> which showed a bunch of unresponsive nodes but no information that
> might be useful for assigning blame. It’d be cool to see these paths
> with scamper’s pmtud traceroute, which tries to find out the MTU for
> the hops that aren’t sending a PTB.
>
> with that list of IP addresses:
> scamper -c “trace -P udp-paris -M” -f <file>
though I used:
(for i in `cat f`; do echo “==================== $i”; tracepath6 -n $i; scamper -I “trace -P udp-paris -M $i”; done) >>f.out
This to show the difference between tracepath6 and scamper output, there are some to be seen, some quite scary (eg the 1455 change).
Could be that one just gets through the ICMP ratelimits in one run and not the other.
Those nodes are just blackholes it seems. Only the operators of that network will know what is going on.
I am always surprised to see networks filtering out packets, and especially wonder what they are trying to achieve with such a filter.
> http://www.caida.org/tools/
> http://www.caida.org/~mjl/
>
> Happy to help anyway I can (I wrote scamper)
I am quite aware. Great tool, but not very verbose unfortunately. Hence, typically it just does/outputs nothing.
Greets,
Jeroen
A RR needs to advertise the best path to each RR client, that’s its job.
If it should also send the best-external (which would be, by definition,
not the overall best path) to the clients, you need to use add-path as you
need to advertise more than one path. Have you enabled both? can you share
the config?
IIRC this is the same on XR, you also need to enable add-path on the RR..
> RA’s (router advertisements, aka, icmpv6 type 134)..
>
> Is the receipt of RA’s the only dynamic/automatic way for IPv6 clients to
> learn about their default gateway?
>
> Does DHCPv6 allow for default router option? What are other ways to get
> default router into a ipv6 cpe ?
Right now, RAs and statically setting the info are the only way to do it.
DHCPv6 does not have a default router option. Different people will have
different opinions on whether or not this is a fundamental flaw in the
design of DHCPv6.
It’s not a MAC address, it’s a client identifier. And IOS by default
chooses a text string as client identifier. In your case it’s:
“cisco-0050.56a8.4a2b-Gi0/0”
> Anything to configure at Cisco clients to have proper MAC in binding
> database ?
The above example is completely proper. I’m not aware of any method for
making IOS not use a client identifier, but you can change the
identifier it sends via e.g. “ip dhcp client client-id …” interface
command.
Keep in mind that running BGP and having the full BGP table can be 2 separate things. You generally want all your routing boxes to run BGP, as you’d usually have customer nets and ptp nets ( if you want them ) in it. For everything else, a default ( or multiple defaults, depending on your topology ) should suffice. If you want to be scalable, you’ll design your IGP so that it only carries your loopbacks ( incidentally, those are the only addresses you probably want to label if you’re using LDP ).
Lately, there have been a few designs that offer extreme scalability, based on rfc3107 ( bgp-lu ) , but I’ve yet to hear of anyone actually implementing them . You can find cisco’s flavor here ( http://www.cisco.com/c/en/us/
My thoughts and words are my own.
Kind Regards,
Spyros
—–Original Message—–
From: cisco-nsp [mailto:cisco-nsp-bounces@
Sent: Tuesday, September 16, 2014 9:10 AM
To: cisco-nsp@puck.nether.net
Cc: Wes Smith
Subject: Re: [c-nsp] I-BGP/IGP question
On Tuesday, September 16, 2014 06:55:40 AM Wes Smith wrote:
> I’ve often wondered how large ISPs handle some basic IGP design issues
> re routing between I-BGP nodes in the network. For example .. assume
> two BGP routers connected over a backbone running some kind of IGP
> I-BGP uses the local IGP to route to other I-BGP nodes within the
> ASThe I-BGP next-hop address is the Egress I-BGP node (normally) or
> the IBPG peer loopbackBest practice says to keep the IGP small, for
> example just the I-BGP loopbacks So a potential routing table entry in
> router
> BGP1 would be something like Rtr BGP1 can reach
> ‘8.8.8.8/32 via 10.10.10.10, where 10.10.10.10 is router BGP-2s
> loopback address and BGP-2 is the egress router So far so good. .. I
> understand all this part. But my puzzle is .. for this to work, the
> IGP would also need
> to have a route for 8.8.8.8. so it can route it to my
> other IBGP router at 10.10.10.10But my IGP doesn’t have a route for
> 8.8.8.8 as I don’t redistribute BGP into IGPSo catch-22 . I’ve
> resolved this internally using tunnels between my I-BGP routers and
> using
> next-hop-self. But I’m pretty small scale .. How do
> larger organisations do it? I’m guessing MPLS TE or other tunnels
> between the POPs .. but would like to hear from some folks that have
> done it.Thanks WS (apologies for any dups..)
First, use NEXT_HOP=self; it’s good practice.
Your iBGP speakers will have 8.8.8.8/32 via 10.10.10.10 as an entry, for example.
Your router will then do a look-up for how to get to 10.10.10.10. It will see that this is known via the IGP (IS- IS, OSPF, Static, e.t.c.), which will have an exit interface (TenGigabitEthernet0/2, for example) toward the next-hop (10.10.10.20, for example).
And so it goes until the packet gets to 10.10.10.10.
It really is that simple.
Mark.
This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Rolaware Hellas SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.
______________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/
archive at http://puck.nether.net/
|
16 sep.
|
|||
|
Van: Mark Tinka
Verzonden: 16-9-2014 09:10
Aan: Spyros Kakaroukas
CC: Wes Smith; cisco-nsp@puck.nether.net
Onderwerp: Re: [c-nsp] I-BGP/IGP question
> Exactly what Mark said. The only design you’d have an
> issue with that is if you had routers that do not run
> BGP. Even then, you could solve that with MPLS ( not
> necessarily TE, a good old bgp-free core design with LDP
> would be just fine ) , but that’s really not a use case
> anymore as pretty much everything can run BGP.
IPv6 is still carried in the core for now, obviously.
> Lately, there have been a few designs that offer extreme
> scalability, based on rfc3107 ( bgp-lu ) , but I’ve yet
> to hear of anyone actually implementing them . You can
> find cisco’s flavor here (
> http://www.cisco.com/c/en/us/
> label-switching-mpls/mpls/
> html ) or a relevant draft here (
> https://tools.ietf.org/html/
> s-07 )
RFC 3107 is certainly a consideration when scaling end-to-
end MPLS backbones, e.g., networks with Metro-E boxes
running IP/MPLS on things such as the ME3600X.
In these cases, BGP-LS could also be interesting.
Time will tell.
Mark.
Voorbeeld van bijlage ATT00001.txt weergeven
|
16 sep.
|
|||
|
next-hop-self + source-interface lo0 forces the next-hop of the BGP NLRI to be the loopback interface. This means that:
1. you can fully delegate the business of optimum next-hop lookup to your IGP instead of ibgp. This is a good deal faster.
2. if there is an intermediate interface flap, ibgp will take ages to route around it and in the interim, routing loops may occur.
3. the bgp best path algorithm uses the igp metric of the bgp next-hop as a tie-breaker, so you get slightly better control of route policy calculation.
iBGP is designed for heavyweight information carrying, not reacting quickly to network topology changes. Best use an igp and depend on recursive route lookup for that.
Nick
|
16 sep.
|
|||
|
> http://www.menog.org/
> .pdf
> cheesecake# scamper -I “trace -P udp -M 2a02:26f0:6a:18f::eed”
> traceroute from 2a03:8900:0:100::5 to 2a02:26f0:6a:18f::eed
> 1 2a03:8900:0:100::1 0.216 ms [mtu: 1500]
> 2 2a02:8900:0:200::209 0.216 ms [mtu: 1500]
> 3 2a01:258:8:3::1 0.634 ms [mtu: 1500]
> 4 2001:1900:5:2:2::2dd9 1.053 ms [mtu: 1500]
> 5 2001:1900:5:1::319 12.990 ms [mtu: 1500]
> 6 2001:1900:5:1::412 12.926 ms [mtu: 1500]
> 7 2001:1900:5:3::21e 11.290 ms [mtu: 1500]
> 8 2001:41a8:600::1e 26.975 ms [mtu: 1500]
> 9 2001:41a8:600:2::b6 27.529 ms [mtu: 1500]
> 10 *
> 11 2a02:26f0:6a::210:d9a3 25.227 ms [mtu: 1500]
> cheesecake#
This means no path mtu problems from as1197 to 2a02:26f0:6a:18f::eed.
Nick
On 22/09/14 22:42, chiel wrote:
> So not yet for a 6500 with sup720? I believe 15.1 is the latest on that.
Looks to be the case….
7600 with SUP720 have 15.2, 15.3 & 15.4 releases:
Is this router on the Internet, or on a private WAN?
Can you enabled NetFlow on the router and take a look at the contents of the NetFlow cache? No, the additional CPU is not a big deal, it’s single-digit.
Take a look at this preso:
<https://app.box.com/s/
sh proc c | e 0.00 would be helpful.
> Ultimately I want to know am I simply hitting a practical
> limit of the box already?
> I’m very scared to enable more WAN links on these routers
> as I am affraid it will max out the available resources.
It’s been a while since I ran any decent traffic through the
NPE-G2, but if memory serves, CPU utilization was not always
linear with traffic. But at some point, it levels out and
climbs slower (given that you’re not running any features
that could cause this).
That said, this was back in the days of SRC, and the NPE-
G2’s I have now are looking glasses, so no major drama
there.
We saw higher CPU utilization at low traffic levels compared
to the NPE-G1, but saw a slower climb as traffic climbed. In
the role you describe, we got to 950Mbps at ~93% CPU
utilization.